Re: Fw: AD-review comments on draft-ietf-ccamp-gmpls-egress-control

[Alex Zinin <[e-mail]>]

IETF Last Call requested. Thanks, Lou.

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

Monday, August 30, 2004, 1:30:13 PM, Lou Berger wrote:
> Draft has been updated and resubmitted.

> Alex,
>          Thanks again for the review.

> Lou


> At 06:12 PM 8/28/2004 -0400, Adrian Farrel wrote:

>>Hi,
>>
>>The AD (Alex) has reviewed this draft and just has a couple of editorial 
>>nits.
>>If the editor (Lou) would like to make the changes and re-submit, we can 
>>get the draft to
>>go forward.
>>
>>Lou, please don't forget to run the draft through the IDnits script before 
>>submitting it.
>>
>>Thanks,
>>Adrian
>>
>>----- Original Message -----
>>From: "Alex Zinin" <[e-mail]>
>>
>> > Ed: please use the new ID boilerplates.
>> >
>> > > Abstract
>> > >
>> > >    This note clarifies the procedures for the control of the label used
>> > >    on a output/downstream interface of the egress node of a Label
>> > >    Switched Path (LSP).  Such control is also known as "Egress Control".
>> > >    Support for Egress Control is implicit in Generalized Multi-Protocol
>> > >    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
>> > >    signaling mechanisms and procedures and should be viewed as an
>> > >    informative clarification of GMPLS Signaling - Resource ReserVation
>> > >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
>> >
>> > Given that the doc goes STD track, I suggest that the last sentence is
>> > changed to say "This note is a clarification update to the specification
>> > of GMPLS Signaling..."
>> >
>> > > Author's Note
>> > >
>> > >    This draft is targeted for publication as a BCP.
>> >
>> > This one should be removed for the same reason.






Envelope-to: [e-mail]
Delivery-date: Tue, 31 Aug 2004 20:41:41 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,  "'[e-mail]'" <[e-mail]>,  'John Drake' <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 13:40:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

More on the testing and the E-NNI:

-- the testing used the OIF Intra-Carrier E-NNI implementation agreement
(http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf) 
RSVP signaling, but this is closely aligned with G.7713.2, there
are no additional protocol elements incorporated beyond G.7713.2.  The
testing also involved, as you mention, the OIF UNI 1.0 rel2 agreement
(http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
the UNI.

-- there is a description of control domain in the E-NNI Introduction section,
reading
"A control domain is an architectural construct that provides for encapsulation and
information hiding, and the characteristics of the control domain are the same as
those of its constituent set of distributed architectural components."
It is similar to the description in G.8080 Amendment 1 for ASON.

-- thanks for the clarification on the GMPLS-OSPF reference, missed it the
first time around.  Is the gist of your suggestion that the link should be
advertised with 0 reservable capacity in the case identified in the liaison?

-- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable, it
might be a way forward on the reachability concern.  We could discuss this
further in the routing solutions design team.

Cheers,

Lyndon

-----Original Message-----
From: dimitri papadimitriou [mailto:[e-mail]]
Sent: Tuesday, August 31, 2004 11:08 AM
To: Ong, Lyndon; 'John Drake'
Cc: [e-mail]; Adrian Farrel; [e-mail]
Subject: Re: Communication from the OIF


hi lyndon, john, all,

> Looks like you two would be great candidates for writing
> the liaison reply!

ok - we (if john agrees) will collect input and suggest a first response 
to the list

> Some responses to Dimitri's questions:

thanks - see below for some additional input/question/comments:

> -- the architecture was intended to be consistent with ASON and the
> testing was focused on E-NNI and UNI interfaces, the signaling protocol
> at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)

to get a closure on this the demo included the OIF UNI IA (?) and the 
ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not tested 
?) so, if this assumption is correct there are two major implications no 
call functionality was part of the demo (seems to be confirmed by the 
below response) and all OIF E-NNI IA specifics that are not part of 
G.7713.2 were also not demo'ed - would you please confirm/clarify ?

> -- switched connections were set up across E-NNI boundaries
> 
> -- I'll check on the exact definition of domain, where would you find 
> the best definition in the IETF context?

just to clarify the question was referring to the OIF definition of 
"domain" in order to understand the scope of the "OIF E-NNI routing - 
link state inter-domain routing" demo item

now, a good pointer for a domain definition in the "IETF context" is 
probably the one provided in:

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt>

"[...] a domain is considered to be any collection of network elements 
within a common sphere of address management or path computational 
responsibility. Examples of such domains include IGP areas and 
Autonomous Systems. However, domains of computational responsibility may 
also exist as sub-domains of areas or ASs. Wholly or partially 
overlapping domains are not within the scope of this document."

> -- both set up and tear down of connections was tested
> 
> -- the issue mentioned with SUKLM was not a comment against the current
> IETF drafts, just a note that some implementors had not kept up with 
> the changes in the drafts from a year or two back to merge SONET and SDH

as mentioned, the v08.txt document is in the RFC Editor queue (to be 
clarified in the response)

> -- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
> but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
> you clarify the reference?

i meant "Section 2. Implications on Graceful Restart" of
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt>

> -- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
> method of advertising reachability to a non-OSPF LER, but the draft 
> appears to be designed for a router to advertise its own local addresses,
> can this be used to advertise reachable addresses as well?

as OIF devised assignment of "client addresses" from the network (edges) 
so, one can assume these local addresses can follow the same procedure 
defined in the above referenced document - this is just an application 
of this i-d (not even an extension) as the pool of "client addresses" is 
in fact owned by the network (edges)

> Cheers,
> 
> Lyndon
> 
> 
> 
> -----Original Message-----
> From: John Drake [mailto:[e-mail]]
> Sent: Tuesday, August 31, 2004 8:22 AM
> To: [e-mail]; Adrian Farrel
> Cc: [e-mail]
> Subject: RE: Communication from the OIF
> 
> 
> Dimitri,
> 
> Excellent note.  You saved me a lot of typing.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]
>>Sent: Monday, August 30, 2004 11:32 AM
>>To: Adrian Farrel
>>Cc: [e-mail]
>>Subject: Re: Communication from the OIF
>>
>>
>>hi adrian, all, see in-line
>>
>>
>>>We have received a communication from the OIF. This is pasted as
>>>ASCII text below.
>>>
>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>
>>>There are several direct questions and issues raised in the
>>>communication and we should respond. Volunteers to draft text are
>>>eagerly sort.
>>>
>>>Adrian
>>>
>>>==== August 11, 2004 Mr. Adrian Farrel, [e-mail], IETF,
>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [e-mail],
>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [e-mail], IETF,
>>>Routing Area Director Mr. Bill Fenner, [e-mail], IETF,
>>> Routing Area Director Re: Results from OIF World Interoperability
>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>
>>>Thank you for your recent communication of June 27, 2004. We
>>>appreciate the ongoing dialogue and information provided.
>>>
>>>As previously communicated, the OIF successfully held its World
>>>Interoperability Demo at Supercomm 2004 (see
>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>This demo included the ASON compliant OIF UNI and ENNI Implementation
>>>Agreements.
>>
>>if i well understand the above statement, is this implicitly meaning that
>>OIF developments are architecturally compliant with ASON (G.8080) but not
>>(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
>>its own implementation agreements ?
>>
>>
>>>Due to the number of implementations involved (15 vendors, 7
>>>carriers) we were able to learn much from the demo. The OIF would
>>>like to share some of these control plane results and solicit
>>>guidance from CCAMP on some issues. Successful interoperability tests
>>>included:
>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>   calls including those that traversed ENNIs.
>>
>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>interfaces ?
>>
>>
>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>   vice-versa)
>>>?? ENNI routing - link state inter-domain routing
>>
>>it would be of interest to have the OIF definition of "domain" in order to
>>understand the relationship of the above test with the current IETF CCAMP
>>efforts and related
>>
>>
>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>   connection. This used the common signal type of 6.
>>
>>as an aside question were both setup and teardown requests tested in the
>>above interoperability tests ?
>>
>>
>>>Some things we learned were:
>>>?? In addition to the Srefresh message,
>>>it was helpful to periodically send the full refresh message as it
>>>helped the topology display system track calls. (This is consistent
>>>with an option described in RFC 2961 section 5.5.)
>>>
>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>context for the SPC egress label because for the interdomain case,
>>>the name of the egress network element would not necessarily be
>>>known.
>>
>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
>>the address of one of its numbered TE links and a SESSION_OBJECT set by
>>the ingress node to the address of one of the egress' numbered TE links
>>such that the connection is only be made between the corr. interfaces,
>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>RFC 3473 (explicit label control) provides for the same functionality
>>
>>
>>>?? Interpretation of the encoding for SUKLM. There was some
>>>inconsistency in the interpretation of the S bit setting which we
>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>Implementers should be encouraged to adhere to
>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>
>>this document is in the RFC Editor and hangs on a cyclic reference to
>>the GMPLS architecture document
>>
>>
>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>unavailable. Since the network does not support crankback (yet),
>>>there is no way to recover from this situation. It is suggested that
>>>a link attribute be added to state whether the link capacity being
>>>advertised is available for new connection admission.
>>
>>why operation described in section 2 (Section 2. Implications on Graceful
>>Restart) of GMPLS-OSPF is not applied in this case ?
>>
>>
>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>capability proposed in which a client that has an SPC becomes UNI
>>>capable and the operator wants to create SC state for the client so
>>>that it can teardown the call (as opposed to the management system).
>>>Any thoughts on how this might be done would be appreciated.
>>
>>use of the splicing operation with the already established SPC (using the
>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>should
>>deliver the expected functionality
>>
>>
>>>?? There is confusion if a Router ID must be the same value as a
>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>32-bit number assigned to each router running the OSPF protocol." It
>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>address. It specifically states: "The address space of IP networks
>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>defines Router ID as: ". a stable IP address of an LSR that is always
>>>reachable if there is any connectivity to the LSR." It goes on to
>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
>>>not clear if the usage of Router ID here is referencing the OSPF
>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>requested. Maintaining the independence between OSPF's Router ID, and
>>>the IP addresses used on a LSR is a powerful and necessary
>>>capability as it allows for the renumbering of links without causing
>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>resulting flushing and regeneration of all locally originated LSAs
>>>describing attached broadcast networks and links.
>>
>>there are two statements in the above:
>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>   -> looking at the resp. definitions, the former is an address
>>   ("typically implemented as a "loopback address") and the latter is
>>   a 32 bit number that may make use of local IP address values
>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>   Router_Address/(IS-IS) TE Router_ID
>>
>>so in both cases (as determined by 1.) what precludes rule 2 to be applied
>>in OIF IAs ? i should point out that above mentioned footnote does only
>>points out that "a network may have an IP address which is identical (when
>>considered as a 32-bit number) to some router's Router ID." it does not
>>say
>>that the router_ID can not borrow its 32 bit number value from local IP
>>addressing space (section 5 of RFC 2328) - it is thus important to avoid
>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>Router_ID
>>to be both syntaxically and semantically an "IP address"
>>
>>it is also unclear why OIF renumbering IAs require change of any Router_ID
>>in addition to the renumbering of the local/remote interface_id (for
>>unnumbered link) ? if this is the case - why so ?
>>
>>
>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>results in an unnecessary behavior that causes significant churn in
>>>the LSDB, and potential disruption of TE-route calculation, when
>>>renumbering is done.
>>
>>see above
>>
>>
>>>. MPLS-TE does not allow for nodes that are not participating in OSPF
>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>as a path computation server, to perform route calculation on its
>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>However, since the LER is not participating in OSPF, it has no way to
>>>advertise where it appears in the network. Consequently, ingress
>>>LERs will not be able to calculate routes to this egress LSR. A
>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>needs to be developed.
>>
>>there is somehow an ambuiguity in this question, using the following
>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>reachability, but i don't see how the ingress LSR (client ?) could make
>>use of this information since ingress and egress LSR are simply nodes
>>not participating on the OSPF instance ?
>>
>>
>>>We also recommend the following item be considered by the ASON
>>>routing solutions design team:
>>>
>>>. The ASON routing architecture allows for the abstraction of
>>>information when hierarchical routing is utilized. This abstraction
>>>is handled by a transformation function that exists between the Child
>>>Area and the Parent Area. The amount of transformation of routing
>>>information performed can be described as a continuum with the
>>>following extremes: . Let all link and node information through with
>>>no changes . Abstract all link and node information provided by the
>>>Child Area into a single node. (This was successfully tested in the
>>>recent demo.)
>>
>>-> i'll pass the above information to the ASON RSDT
>>
>>
>>>Other approaches exist on this continuum, but may be complex to
>>>define. Consequently, we believe these approaches may be best left as
>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 31 Aug 2004 19:34:27 +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-egress-control-03.txt
Date: Tue, 31 Aug 2004 15:31:01 -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		: GMPLS Signaling Procedure For Egress Control
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-egress-control-03.txt
	Pages		: 6
	Date		: 2004-8-31
	
This note clarifies the procedures for the control of the label used
   on a output/downstream interface of the egress node of a Label
   Switched Path (LSP).  Such control is also known as "Egress Control".
   Support for Egress Control is implicit in Generalized Multi-Protocol
   Label Switching (GMPLS) Signaling.  This note is a clarification to
   the specification of GMPLS Signaling and does not modify GMPLS
   signaling mechanisms and procedures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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-egress-control-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-egress-control-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-egress-control-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-egress-control-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, 31 Aug 2004 19:22:45 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: [e-mail], [e-mail],  "Ong, Lyndon" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 12:19:58 -0700
MIME-Version: 1.0
Content-Type: text/plain

Snipped

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[e-mail]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; John Drake
> Cc: [e-mail]; Adrian Farrel; [e-mail]
> Subject: Re: Communication from the OIF
> 
> hi lyndon, john, all,
> 
> > Looks like you two would be great candidates for writing
> > the liaison reply!
> 
> ok - we (if john agrees) will collect input and suggest a first response
> to the list
> 
[John Drake] 

Fine with me




Envelope-to: [e-mail]
Delivery-date: Tue, 31 Aug 2004 18:09:08 +0000
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 2004 20:08:16 +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.1) Gecko/20040707
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>, 'John Drake' <[e-mail]>
CC: [e-mail],  Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Communication from the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi lyndon, john, all,

> Looks like you two would be great candidates for writing
> the liaison reply!

ok - we (if john agrees) will collect input and suggest a first response 
to the list

> Some responses to Dimitri's questions:

thanks - see below for some additional input/question/comments:

> -- the architecture was intended to be consistent with ASON and the
> testing was focused on E-NNI and UNI interfaces, the signaling protocol
> at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)

to get a closure on this the demo included the OIF UNI IA (?) and the 
ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not tested 
?) so, if this assumption is correct there are two major implications no 
call functionality was part of the demo (seems to be confirmed by the 
below response) and all OIF E-NNI IA specifics that are not part of 
G.7713.2 were also not demo'ed - would you please confirm/clarify ?

> -- switched connections were set up across E-NNI boundaries
> 
> -- I'll check on the exact definition of domain, where would you find 
> the best definition in the IETF context?

just to clarify the question was referring to the OIF definition of 
"domain" in order to understand the scope of the "OIF E-NNI routing - 
link state inter-domain routing" demo item

now, a good pointer for a domain definition in the "IETF context" is 
probably the one provided in:

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt>

"[...] a domain is considered to be any collection of network elements 
within a common sphere of address management or path computational 
responsibility. Examples of such domains include IGP areas and 
Autonomous Systems. However, domains of computational responsibility may 
also exist as sub-domains of areas or ASs. Wholly or partially 
overlapping domains are not within the scope of this document."

> -- both set up and tear down of connections was tested
> 
> -- the issue mentioned with SUKLM was not a comment against the current
> IETF drafts, just a note that some implementors had not kept up with 
> the changes in the drafts from a year or two back to merge SONET and SDH

as mentioned, the v08.txt document is in the RFC Editor queue (to be 
clarified in the response)

> -- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
> but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
> you clarify the reference?

i meant "Section 2. Implications on Graceful Restart" of
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt>

> -- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
> method of advertising reachability to a non-OSPF LER, but the draft 
> appears to be designed for a router to advertise its own local addresses,
> can this be used to advertise reachable addresses as well?

as OIF devised assignment of "client addresses" from the network (edges) 
so, one can assume these local addresses can follow the same procedure 
defined in the above referenced document - this is just an application 
of this i-d (not even an extension) as the pool of "client addresses" is 
in fact owned by the network (edges)

> Cheers,
> 
> Lyndon
> 
> 
> 
> -----Original Message-----
> From: John Drake [mailto:[e-mail]]
> Sent: Tuesday, August 31, 2004 8:22 AM
> To: [e-mail]; Adrian Farrel
> Cc: [e-mail]
> Subject: RE: Communication from the OIF
> 
> 
> Dimitri,
> 
> Excellent note.  You saved me a lot of typing.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]
>>Sent: Monday, August 30, 2004 11:32 AM
>>To: Adrian Farrel
>>Cc: [e-mail]
>>Subject: Re: Communication from the OIF
>>
>>
>>hi adrian, all, see in-line
>>
>>
>>>We have received a communication from the OIF. This is pasted as
>>>ASCII text below.
>>>
>>>You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>>>
>>>There are several direct questions and issues raised in the
>>>communication and we should respond. Volunteers to draft text are
>>>eagerly sort.
>>>
>>>Adrian
>>>
>>>==== August 11, 2004 Mr. Adrian Farrel, [e-mail], IETF,
>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [e-mail],
>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [e-mail], IETF,
>>>Routing Area Director Mr. Bill Fenner, [e-mail], IETF,
>>> Routing Area Director Re: Results from OIF World Interoperability
>>>Demo Dear Adrian, Kireeti, Alex and Bill,
>>>
>>>Thank you for your recent communication of June 27, 2004. We
>>>appreciate the ongoing dialogue and information provided.
>>>
>>>As previously communicated, the OIF successfully held its World
>>>Interoperability Demo at Supercomm 2004 (see
>>>http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
>>>http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
>>>This demo included the ASON compliant OIF UNI and ENNI Implementation
>>>Agreements.
>>
>>if i well understand the above statement, is this implicitly meaning that
>>OIF developments are architecturally compliant with ASON (G.8080) but not
>>(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
>>its own implementation agreements ?
>>
>>
>>>Due to the number of implementations involved (15 vendors, 7
>>>carriers) we were able to learn much from the demo. The OIF would
>>>like to share some of these control plane results and solicit
>>>guidance from CCAMP on some issues. Successful interoperability tests
>>>included:
>>>?? Switched Connections (SCs)- UNI clients calling other UNI clients
>>>?? Soft Permanent Connections (SPCs) - network management driven
>>>   calls including those that traversed ENNIs.
>>
>>were SCs requests also tested across/traversing OIF E-NNI IA based
>>interfaces ?
>>
>>
>>>?? SC to SPC calls - a UNI client with a call to an SPC client (and
>>>   vice-versa)
>>>?? ENNI routing - link state inter-domain routing
>>
>>it would be of interest to have the OIF definition of "domain" in order to
>>understand the relationship of the above test with the current IETF CCAMP
>>efforts and related
>>
>>
>>>?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>>>   connection. This used the common signal type of 6.
>>
>>as an aside question were both setup and teardown requests tested in the
>>above interoperability tests ?
>>
>>
>>>Some things we learned were:
>>>?? In addition to the Srefresh message,
>>>it was helpful to periodically send the full refresh message as it
>>>helped the topology display system track calls. (This is consistent
>>>with an option described in RFC 2961 section 5.5.)
>>>
>>>?? For SPCs, we determined that it was helpful to use a TNA as the
>>>context for the SPC egress label because for the interdomain case,
>>>the name of the egress network element would not necessarily be
>>>known.
>>
>>use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
>>the address of one of its numbered TE links and a SESSION_OBJECT set by
>>the ingress node to the address of one of the egress' numbered TE links
>>such that the connection is only be made between the corr. interfaces,
>>in combination with procedure described in section 5.1.1 and 5.1.2 of
>>RFC 3473 (explicit label control) provides for the same functionality
>>
>>
>>>?? Interpretation of the encoding for SUKLM. There was some
>>>inconsistency in the interpretation of the S bit setting which we
>>>think arose from use of earlier text on SONET/SDH encoding types.
>>>Implementers should be encouraged to adhere to
>>>draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
>>
>>this document is in the RFC Editor and hangs on a cyclic reference to
>>the GMPLS architecture document
>>
>>
>>>?? Loss of a signaling adjacency effectively makes a data-plane link
>>>unavailable. Since the network does not support crankback (yet),
>>>there is no way to recover from this situation. It is suggested that
>>>a link attribute be added to state whether the link capacity being
>>>advertised is available for new connection admission.
>>
>>why operation described in section 2 (Section 2. Implications on Graceful
>>Restart) of GMPLS-OSPF is not applied in this case ?
>>
>>
>>>Issues that we seek guidance from CCAMP are: ?? There was a new
>>>capability proposed in which a client that has an SPC becomes UNI
>>>capable and the operator wants to create SC state for the client so
>>>that it can teardown the call (as opposed to the management system).
>>>Any thoughts on how this might be done would be appreciated.
>>
>>use of the splicing operation with the already established SPC (using the
>>method described in section 6 of RFC 3471 and section 5 of RFC 3473)
>>should
>>deliver the expected functionality
>>
>>
>>>?? There is confusion if a Router ID must be the same value as a
>>>reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
>>>32-bit number assigned to each router running the OSPF protocol." It
>>>is further clarified in footnote 9 that a Router ID is not an IP
>>>address. It specifically states: "The address space of IP networks
>>>and the address space of OSPF Router IDs may overlap." RFC 3477
>>>defines Router ID as: ". a stable IP address of an LSR that is always
>>>reachable if there is any connectivity to the LSR." It goes on to
>>>state: "If one is using the OSPF or ISIS as the IGP in support of
>>>traffic engineering, then it is RECOMMENDED for the Router ID to be
>>>set to the "Router Address" as defined in [OSPF-TE], or "Traffic
>>>Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
>>>not clear if the usage of Router ID here is referencing the OSPF
>>>Router ID or the Router ID as defined by RFC 3477. Clarification is
>>>requested. Maintaining the independence between OSPF's Router ID, and
>>>the IP addresses used on a LSR is a powerful and necessary
>>>capability as it allows for the renumbering of links without causing
>>>the revocation of the OSPF Router ID being used by an LSR and the
>>>resulting flushing and regeneration of all locally originated LSAs
>>>describing attached broadcast networks and links.
>>
>>there are two statements in the above:
>>1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>>   -> looking at the resp. definitions, the former is an address
>>   ("typically implemented as a "loopback address") and the latter is
>>   a 32 bit number that may make use of local IP address values
>>2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>>   Router_Address/(IS-IS) TE Router_ID
>>
>>so in both cases (as determined by 1.) what precludes rule 2 to be applied
>>in OIF IAs ? i should point out that above mentioned footnote does only
>>points out that "a network may have an IP address which is identical (when
>>considered as a 32-bit number) to some router's Router ID." it does not
>>say
>>that the router_ID can not borrow its 32 bit number value from local IP
>>addressing space (section 5 of RFC 2328) - it is thus important to avoid
>>(in any case) the inferrence that RFC 3477 mandates that the OSPF
>>Router_ID
>>to be both syntaxically and semantically an "IP address"
>>
>>it is also unclear why OIF renumbering IAs require change of any Router_ID
>>in addition to the renumbering of the local/remote interface_id (for
>>unnumbered link) ? if this is the case - why so ?
>>
>>
>>>Requiring the Router ID to be a reachable IP address on the LSR
>>>results in an unnecessary behavior that causes significant churn in
>>>the LSDB, and potential disruption of TE-route calculation, when
>>>renumbering is done.
>>
>>see above
>>
>>
>>>. MPLS-TE does not allow for nodes that are not participating in OSPF
>>>to be advertised. When an MPLS-TE LER relies on another node, such
>>>as a path computation server, to perform route calculation on its
>>>behalf, it is unnecessary for the LER to participate in OSPF.
>>>However, since the LER is not participating in OSPF, it has no way to
>>>advertise where it appears in the network. Consequently, ingress
>>>LERs will not be able to calculate routes to this egress LSR. A
>>>mechanism to advertise reachability of non-OSPF participating LERs
>>>needs to be developed.
>>
>>there is somehow an ambuiguity in this question, using the following
>><draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
>>reachability, but i don't see how the ingress LSR (client ?) could make
>>use of this information since ingress and egress LSR are simply nodes
>>not participating on the OSPF instance ?
>>
>>
>>>We also recommend the following item be considered by the ASON
>>>routing solutions design team:
>>>
>>>. The ASON routing architecture allows for the abstraction of
>>>information when hierarchical routing is utilized. This abstraction
>>>is handled by a transformation function that exists between the Child
>>>Area and the Parent Area. The amount of transformation of routing
>>>information performed can be described as a continuum with the
>>>following extremes: . Let all link and node information through with
>>>no changes . Abstract all link and node information provided by the
>>>Child Area into a single node. (This was successfully tested in the
>>>recent demo.)
>>
>>-> i'll pass the above information to the ASON RSDT
>>
>>
>>>Other approaches exist on this continuum, but may be complex to
>>>define. Consequently, we believe these approaches may be best left as
>>>vendor specific approaches. Sincerely yours, Steve Joiner OIF,
>>>Technical Committee Chair cc: Jim Jones, John McDonough
>>
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 31 Aug 2004 17:02:56 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'John Drake' <[e-mail]>, [e-mail],  Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 10:01:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Guys,

Looks like you two would be great candidates for writing
the liaison reply!

Some responses to Dimitri's questions:

-- the architecture was intended to be consistent with ASON and the
testing was focused on E-NNI and UNI interfaces, the signaling protocol
at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)

-- switched connections were set up across E-NNI boundaries

-- I'll check on the exact definition of domain, where would you find 
the best definition in the IETF context?

-- both set up and tear down of connections was tested

-- the issue mentioned with SUKLM was not a comment against the current
IETF drafts, just a note that some implementors had not kept up with 
the changes in the drafts from a year or two back to merge SONET and SDH

-- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
you clarify the reference?

-- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
method of advertising reachability to a non-OSPF LER, but the draft 
appears to be designed for a router to advertise its own local addresses,
can this be used to advertise reachable addresses as well?

Cheers,

Lyndon



-----Original Message-----
From: John Drake [mailto:[e-mail]]
Sent: Tuesday, August 31, 2004 8:22 AM
To: [e-mail]; Adrian Farrel
Cc: [e-mail]
Subject: RE: Communication from the OIF


Dimitri,

Excellent note.  You saved me a lot of typing.

John

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, August 30, 2004 11:32 AM
> To: Adrian Farrel
> Cc: [e-mail]
> Subject: Re: Communication from the OIF
> 
> 
> hi adrian, all, see in-line
> 
> > We have received a communication from the OIF. This is pasted as
> > ASCII text below.
> >
> > You can see the PDF version at http://www.olddog.co.uk/incoming.htm
> >
> > There are several direct questions and issues raised in the
> > communication and we should respond. Volunteers to draft text are
> > eagerly sort.
> >
> > Adrian
> >
> > ==== August 11, 2004 Mr. Adrian Farrel, [e-mail], IETF,
> > CCAMP Working Group Chair Mr. Kireeti Kompella, [e-mail],
> > IETF, CCAMP Working Group Chair Mr. Alex Zinin, [e-mail], IETF,
> > Routing Area Director Mr. Bill Fenner, [e-mail], IETF,
> >  Routing Area Director Re: Results from OIF World Interoperability
> > Demo Dear Adrian, Kireeti, Alex and Bill,
> >
> > Thank you for your recent communication of June 27, 2004. We
> > appreciate the ongoing dialogue and information provided.
> >
> > As previously communicated, the OIF successfully held its World
> > Interoperability Demo at Supercomm 2004 (see
> > http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
> > http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
> > This demo included the ASON compliant OIF UNI and ENNI Implementation
> > Agreements.
> 
> if i well understand the above statement, is this implicitly meaning that
> OIF developments are architecturally compliant with ASON (G.8080) but not
> (necessarily) compliant with the G.7713.2 specification ? as OIF maintains
> its own implementation agreements ?
> 
> > Due to the number of implementations involved (15 vendors, 7
> > carriers) we were able to learn much from the demo. The OIF would
> > like to share some of these control plane results and solicit
> > guidance from CCAMP on some issues. Successful interoperability tests
> > included:
> > ?? Switched Connections (SCs)- UNI clients calling other UNI clients
> > ?? Soft Permanent Connections (SPCs) - network management driven
> >    calls including those that traversed ENNIs.
> 
> were SCs requests also tested across/traversing OIF E-NNI IA based
> interfaces ?
> 
> > ?? SC to SPC calls - a UNI client with a call to an SPC client (and
> >    vice-versa)
> > ?? ENNI routing - link state inter-domain routing
> 
> it would be of interest to have the OIF definition of "domain" in order to
> understand the relationship of the above test with the current IETF CCAMP
> efforts and related
> 
> > ?? Call using OC-3c and VC-4 links for an STS-3c equivalent
> >    connection. This used the common signal type of 6.
> 
> as an aside question were both setup and teardown requests tested in the
> above interoperability tests ?
> 
> > Some things we learned were:
> > ?? In addition to the Srefresh message,
> > it was helpful to periodically send the full refresh message as it
> > helped the topology display system track calls. (This is consistent
> > with an option described in RFC 2961 section 5.5.)
> >
> > ?? For SPCs, we determined that it was helpful to use a TNA as the
> > context for the SPC egress label because for the interdomain case,
> > the name of the egress network element would not necessarily be
> > known.
> 
> use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
> the address of one of its numbered TE links and a SESSION_OBJECT set by
> the ingress node to the address of one of the egress' numbered TE links
> such that the connection is only be made between the corr. interfaces,
> in combination with procedure described in section 5.1.1 and 5.1.2 of
> RFC 3473 (explicit label control) provides for the same functionality
> 
> > ?? Interpretation of the encoding for SUKLM. There was some
> > inconsistency in the interpretation of the S bit setting which we
> > think arose from use of earlier text on SONET/SDH encoding types.
> > Implementers should be encouraged to adhere to
> > draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
> 
> this document is in the RFC Editor and hangs on a cyclic reference to
> the GMPLS architecture document
> 
> > ?? Loss of a signaling adjacency effectively makes a data-plane link
> > unavailable. Since the network does not support crankback (yet),
> > there is no way to recover from this situation. It is suggested that
> > a link attribute be added to state whether the link capacity being
> > advertised is available for new connection admission.
> 
> why operation described in section 2 (Section 2. Implications on Graceful
> Restart) of GMPLS-OSPF is not applied in this case ?
> 
> > Issues that we seek guidance from CCAMP are: ?? There was a new
> > capability proposed in which a client that has an SPC becomes UNI
> > capable and the operator wants to create SC state for the client so
> > that it can teardown the call (as opposed to the management system).
> > Any thoughts on how this might be done would be appreciated.
> 
> use of the splicing operation with the already established SPC (using the
> method described in section 6 of RFC 3471 and section 5 of RFC 3473)
> should
> deliver the expected functionality
> 
> > ?? There is confusion if a Router ID must be the same value as a
> > reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
> > 32-bit number assigned to each router running the OSPF protocol." It
> > is further clarified in footnote 9 that a Router ID is not an IP
> > address. It specifically states: "The address space of IP networks
> > and the address space of OSPF Router IDs may overlap." RFC 3477
> > defines Router ID as: ". a stable IP address of an LSR that is always
> > reachable if there is any connectivity to the LSR." It goes on to
> > state: "If one is using the OSPF or ISIS as the IGP in support of
> > traffic engineering, then it is RECOMMENDED for the Router ID to be
> > set to the "Router Address" as defined in [OSPF-TE], or "Traffic
> > Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
> > not clear if the usage of Router ID here is referencing the OSPF
> > Router ID or the Router ID as defined by RFC 3477. Clarification is
> > requested. Maintaining the independence between OSPF's Router ID, and
> > the IP addresses used on a LSR is a powerful and necessary
> > capability as it allows for the renumbering of links without causing
> > the revocation of the OSPF Router ID being used by an LSR and the
> > resulting flushing and regeneration of all locally originated LSAs
> > describing attached broadcast networks and links.
> 
> there are two statements in the above:
> 1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>    -> looking at the resp. definitions, the former is an address
>    ("typically implemented as a "loopback address") and the latter is
>    a 32 bit number that may make use of local IP address values
> 2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>    Router_Address/(IS-IS) TE Router_ID
> 
> so in both cases (as determined by 1.) what precludes rule 2 to be applied
> in OIF IAs ? i should point out that above mentioned footnote does only
> points out that "a network may have an IP address which is identical (when
> considered as a 32-bit number) to some router's Router ID." it does not
> say
> that the router_ID can not borrow its 32 bit number value from local IP
> addressing space (section 5 of RFC 2328) - it is thus important to avoid
> (in any case) the inferrence that RFC 3477 mandates that the OSPF
> Router_ID
> to be both syntaxically and semantically an "IP address"
> 
> it is also unclear why OIF renumbering IAs require change of any Router_ID
> in addition to the renumbering of the local/remote interface_id (for
> unnumbered link) ? if this is the case - why so ?
> 
> > Requiring the Router ID to be a reachable IP address on the LSR
> > results in an unnecessary behavior that causes significant churn in
> > the LSDB, and potential disruption of TE-route calculation, when
> > renumbering is done.
> 
> see above
> 
> > . MPLS-TE does not allow for nodes that are not participating in OSPF
> > to be advertised. When an MPLS-TE LER relies on another node, such
> > as a path computation server, to perform route calculation on its
> > behalf, it is unnecessary for the LER to participate in OSPF.
> > However, since the LER is not participating in OSPF, it has no way to
> > advertise where it appears in the network. Consequently, ingress
> > LERs will not be able to calculate routes to this egress LSR. A
> > mechanism to advertise reachability of non-OSPF participating LERs
> > needs to be developed.
> 
> there is somehow an ambuiguity in this question, using the following
> <draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
> reachability, but i don't see how the ingress LSR (client ?) could make
> use of this information since ingress and egress LSR are simply nodes
> not participating on the OSPF instance ?
> 
> > We also recommend the following item be considered by the ASON
> > routing solutions design team:
> >
> > . The ASON routing architecture allows for the abstraction of
> > information when hierarchical routing is utilized. This abstraction
> > is handled by a transformation function that exists between the Child
> > Area and the Parent Area. The amount of transformation of routing
> > information performed can be described as a continuum with the
> > following extremes: . Let all link and node information through with
> > no changes . Abstract all link and node information provided by the
> > Child Area into a single node. (This was successfully tested in the
> > recent demo.)
> 
> -> i'll pass the above information to the ASON RSDT
> 
> > Other approaches exist on this continuum, but may be complex to
> > define. Consequently, we believe these approaches may be best left as
> > vendor specific approaches. Sincerely yours, Steve Joiner OIF,
> > Technical Committee Chair cc: Jim Jones, John McDonough
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 31 Aug 2004 15:24:15 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: [e-mail], Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 08:21:48 -0700
MIME-Version: 1.0
Content-Type: text/plain

Dimitri,

Excellent note.  You saved me a lot of typing.

John

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, August 30, 2004 11:32 AM
> To: Adrian Farrel
> Cc: [e-mail]
> Subject: Re: Communication from the OIF
> 
> 
> hi adrian, all, see in-line
> 
> > We have received a communication from the OIF. This is pasted as
> > ASCII text below.
> >
> > You can see the PDF version at http://www.olddog.co.uk/incoming.htm
> >
> > There are several direct questions and issues raised in the
> > communication and we should respond. Volunteers to draft text are
> > eagerly sort.
> >
> > Adrian
> >
> > ==== August 11, 2004 Mr. Adrian Farrel, [e-mail], IETF,
> > CCAMP Working Group Chair Mr. Kireeti Kompella, [e-mail],
> > IETF, CCAMP Working Group Chair Mr. Alex Zinin, [e-mail], IETF,
> > Routing Area Director Mr. Bill Fenner, [e-mail], IETF,
> >  Routing Area Director Re: Results from OIF World Interoperability
> > Demo Dear Adrian, Kireeti, Alex and Bill,
> >
> > Thank you for your recent communication of June 27, 2004. We
> > appreciate the ongoing dialogue and information provided.
> >
> > As previously communicated, the OIF successfully held its World
> > Interoperability Demo at Supercomm 2004 (see
> > http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
> > http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
> > This demo included the ASON compliant OIF UNI and ENNI Implementation
> > Agreements.
> 
> if i well understand the above statement, is this implicitly meaning that
> OIF developments are architecturally compliant with ASON (G.8080) but not
> (necessarily) compliant with the G.7713.2 specification ? as OIF maintains
> its own implementation agreements ?
> 
> > Due to the number of implementations involved (15 vendors, 7
> > carriers) we were able to learn much from the demo. The OIF would
> > like to share some of these control plane results and solicit
> > guidance from CCAMP on some issues. Successful interoperability tests
> > included:
> > ?? Switched Connections (SCs)- UNI clients calling other UNI clients
> > ?? Soft Permanent Connections (SPCs) - network management driven
> >    calls including those that traversed ENNIs.
> 
> were SCs requests also tested across/traversing OIF E-NNI IA based
> interfaces ?
> 
> > ?? SC to SPC calls - a UNI client with a call to an SPC client (and
> >    vice-versa)
> > ?? ENNI routing - link state inter-domain routing
> 
> it would be of interest to have the OIF definition of "domain" in order to
> understand the relationship of the above test with the current IETF CCAMP
> efforts and related
> 
> > ?? Call using OC-3c and VC-4 links for an STS-3c equivalent
> >    connection. This used the common signal type of 6.
> 
> as an aside question were both setup and teardown requests tested in the
> above interoperability tests ?
> 
> > Some things we learned were:
> > ?? In addition to the Srefresh message,
> > it was helpful to periodically send the full refresh message as it
> > helped the topology display system track calls. (This is consistent
> > with an option described in RFC 2961 section 5.5.)
> >
> > ?? For SPCs, we determined that it was helpful to use a TNA as the
> > context for the SPC egress label because for the interdomain case,
> > the name of the egress network element would not necessarily be
> > known.
> 
> use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
> the address of one of its numbered TE links and a SESSION_OBJECT set by
> the ingress node to the address of one of the egress' numbered TE links
> such that the connection is only be made between the corr. interfaces,
> in combination with procedure described in section 5.1.1 and 5.1.2 of
> RFC 3473 (explicit label control) provides for the same functionality
> 
> > ?? Interpretation of the encoding for SUKLM. There was some
> > inconsistency in the interpretation of the S bit setting which we
> > think arose from use of earlier text on SONET/SDH encoding types.
> > Implementers should be encouraged to adhere to
> > draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
> 
> this document is in the RFC Editor and hangs on a cyclic reference to
> the GMPLS architecture document
> 
> > ?? Loss of a signaling adjacency effectively makes a data-plane link
> > unavailable. Since the network does not support crankback (yet),
> > there is no way to recover from this situation. It is suggested that
> > a link attribute be added to state whether the link capacity being
> > advertised is available for new connection admission.
> 
> why operation described in section 2 (Section 2. Implications on Graceful
> Restart) of GMPLS-OSPF is not applied in this case ?
> 
> > Issues that we seek guidance from CCAMP are: ?? There was a new
> > capability proposed in which a client that has an SPC becomes UNI
> > capable and the operator wants to create SC state for the client so
> > that it can teardown the call (as opposed to the management system).
> > Any thoughts on how this might be done would be appreciated.
> 
> use of the splicing operation with the already established SPC (using the
> method described in section 6 of RFC 3471 and section 5 of RFC 3473)
> should
> deliver the expected functionality
> 
> > ?? There is confusion if a Router ID must be the same value as a
> > reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
> > 32-bit number assigned to each router running the OSPF protocol." It
> > is further clarified in footnote 9 that a Router ID is not an IP
> > address. It specifically states: "The address space of IP networks
> > and the address space of OSPF Router IDs may overlap." RFC 3477
> > defines Router ID as: ". a stable IP address of an LSR that is always
> > reachable if there is any connectivity to the LSR." It goes on to
> > state: "If one is using the OSPF or ISIS as the IGP in support of
> > traffic engineering, then it is RECOMMENDED for the Router ID to be
> > set to the "Router Address" as defined in [OSPF-TE], or "Traffic
> > Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
> > not clear if the usage of Router ID here is referencing the OSPF
> > Router ID or the Router ID as defined by RFC 3477. Clarification is
> > requested. Maintaining the independence between OSPF's Router ID, and
> > the IP addresses used on a LSR is a powerful and necessary
> > capability as it allows for the renumbering of links without causing
> > the revocation of the OSPF Router ID being used by an LSR and the
> > resulting flushing and regeneration of all locally originated LSAs
> > describing attached broadcast networks and links.
> 
> there are two statements in the above:
> 1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
>    -> looking at the resp. definitions, the former is an address
>    ("typically implemented as a "loopback address") and the latter is
>    a 32 bit number that may make use of local IP address values
> 2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
>    Router_Address/(IS-IS) TE Router_ID
> 
> so in both cases (as determined by 1.) what precludes rule 2 to be applied
> in OIF IAs ? i should point out that above mentioned footnote does only
> points out that "a network may have an IP address which is identical (when
> considered as a 32-bit number) to some router's Router ID." it does not
> say
> that the router_ID can not borrow its 32 bit number value from local IP
> addressing space (section 5 of RFC 2328) - it is thus important to avoid
> (in any case) the inferrence that RFC 3477 mandates that the OSPF
> Router_ID
> to be both syntaxically and semantically an "IP address"
> 
> it is also unclear why OIF renumbering IAs require change of any Router_ID
> in addition to the renumbering of the local/remote interface_id (for
> unnumbered link) ? if this is the case - why so ?
> 
> > Requiring the Router ID to be a reachable IP address on the LSR
> > results in an unnecessary behavior that causes significant churn in
> > the LSDB, and potential disruption of TE-route calculation, when
> > renumbering is done.
> 
> see above
> 
> > . MPLS-TE does not allow for nodes that are not participating in OSPF
> > to be advertised. When an MPLS-TE LER relies on another node, such
> > as a path computation server, to perform route calculation on its
> > behalf, it is unnecessary for the LER to participate in OSPF.
> > However, since the LER is not participating in OSPF, it has no way to
> > advertise where it appears in the network. Consequently, ingress
> > LERs will not be able to calculate routes to this egress LSR. A
> > mechanism to advertise reachability of non-OSPF participating LERs
> > needs to be developed.
> 
> there is somehow an ambuiguity in this question, using the following
> <draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
> reachability, but i don't see how the ingress LSR (client ?) could make
> use of this information since ingress and egress LSR are simply nodes
> not participating on the OSPF instance ?
> 
> > We also recommend the following item be considered by the ASON
> > routing solutions design team:
> >
> > . The ASON routing architecture allows for the abstraction of
> > information when hierarchical routing is utilized. This abstraction
> > is handled by a transformation function that exists between the Child
> > Area and the Parent Area. The amount of transformation of routing
> > information performed can be described as a continuum with the
> > following extremes: . Let all link and node information through with
> > no changes . Abstract all link and node information provided by the
> > Child Area into a single node. (This was successfully tested in the
> > recent demo.)
> 
> -> i'll pass the above information to the ASON RSDT
> 
> > Other approaches exist on this continuum, but may be complex to
> > define. Consequently, we believe these approaches may be best left as
> > vendor specific approaches. Sincerely yours, Steve Joiner OIF,
> > Technical Committee Chair cc: Jim Jones, John McDonough
> 




Envelope-to: [e-mail]
Delivery-date: Mon, 30 Aug 2004 20:32:09 +0000
Message-Id: <6.1.2.0.2.20040830162930.04104c38@mo-ex1>
Date: Mon, 30 Aug 2004 16:30:13 -0400
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Fw: AD-review comments on draft-ietf-ccamp-gmpls-egress-control
Cc: <[e-mail]>, "Alex Zinin" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Draft has been updated and resubmitted.

Alex,
         Thanks again for the review.

Lou


At 06:12 PM 8/28/2004 -0400, Adrian Farrel wrote:

>Hi,
>
>The AD (Alex) has reviewed this draft and just has a couple of editorial 
>nits.
>If the editor (Lou) would like to make the changes and re-submit, we can 
>get the draft to
>go forward.
>
>Lou, please don't forget to run the draft through the IDnits script before 
>submitting it.
>
>Thanks,
>Adrian
>
>----- Original Message -----
>From: "Alex Zinin" <[e-mail]>
>
> > Ed: please use the new ID boilerplates.
> >
> > > Abstract
> > >
> > >    This note clarifies the procedures for the control of the label used
> > >    on a output/downstream interface of the egress node of a Label
> > >    Switched Path (LSP).  Such control is also known as "Egress Control".
> > >    Support for Egress Control is implicit in Generalized Multi-Protocol
> > >    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
> > >    signaling mechanisms and procedures and should be viewed as an
> > >    informative clarification of GMPLS Signaling - Resource ReserVation
> > >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
> >
> > Given that the doc goes STD track, I suggest that the last sentence is
> > changed to say "This note is a clarification update to the specification
> > of GMPLS Signaling..."
> >
> > > Author's Note
> > >
> > >    This draft is targeted for publication as a BCP.
> >
> > This one should be removed for the same reason.




Envelope-to: [e-mail]
Delivery-date: Mon, 30 Aug 2004 18:32:36 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
From: [e-mail]
Subject: Re: Communication from the OIF
MIME-Version: 1.0
Date: Mon, 30 Aug 2004 20:31:36 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

hi adrian, all, see in-line

> We have received a communication from the OIF. This is pasted as
> ASCII text below.
>
> You can see the PDF version at http://www.olddog.co.uk/incoming.htm
>
> There are several direct questions and issues raised in the
> communication and we should respond. Volunteers to draft text are
> eagerly sort.
>
> Adrian
>
> ==== August 11, 2004 Mr. Adrian Farrel, [e-mail], IETF,
> CCAMP Working Group Chair Mr. Kireeti Kompella, [e-mail],
> IETF, CCAMP Working Group Chair Mr. Alex Zinin, [e-mail], IETF,
> Routing Area Director Mr. Bill Fenner, [e-mail], IETF,
>  Routing Area Director Re: Results from OIF World Interoperability
> Demo Dear Adrian, Kireeti, Alex and Bill,
>
> Thank you for your recent communication of June 27, 2004. We
> appreciate the ongoing dialogue and information provided.
>
> As previously communicated, the OIF successfully held its World
> Interoperability Demo at Supercomm 2004 (see
> http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
> http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf).
> This demo included the ASON compliant OIF UNI and ENNI Implementation
> Agreements.

if i well understand the above statement, is this implicitly meaning that
OIF developments are architecturally compliant with ASON (G.8080) but not
(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
its own implementation agreements ?

> Due to the number of implementations involved (15 vendors, 7
> carriers) we were able to learn much from the demo. The OIF would
> like to share some of these control plane results and solicit
> guidance from CCAMP on some issues. Successful interoperability tests
> included:
> ?? Switched Connections (SCs)- UNI clients calling other UNI clients
> ?? Soft Permanent Connections (SPCs) - network management driven
>    calls including those that traversed ENNIs.

were SCs requests also tested across/traversing OIF E-NNI IA based
interfaces ?

> ?? SC to SPC calls - a UNI client with a call to an SPC client (and
>    vice-versa)
> ?? ENNI routing - link state inter-domain routing

it would be of interest to have the OIF definition of "domain" in order to
understand the relationship of the above test with the current IETF CCAMP
efforts and related

> ?? Call using OC-3c and VC-4 links for an STS-3c equivalent
>    connection. This used the common signal type of 6.

as an aside question were both setup and teardown requests tested in the
above interoperability tests ?

> Some things we learned were:
> ?? In addition to the Srefresh message,
> it was helpful to periodically send the full refresh message as it
> helped the topology display system track calls. (This is consistent
> with an option described in RFC 2961 section 5.5.)
>
> ?? For SPCs, we determined that it was helpful to use a TNA as the
> context for the SPC egress label because for the interdomain case,
> the name of the egress network element would not necessarily be
> known.

use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
the address of one of its numbered TE links and a SESSION_OBJECT set by
the ingress node to the address of one of the egress' numbered TE links
such that the connection is only be made between the corr. interfaces,
in combination with procedure described in section 5.1.1 and 5.1.2 of
RFC 3473 (explicit label control) provides for the same functionality

> ?? Interpretation of the encoding for SUKLM. There was some
> inconsistency in the interpretation of the S bit setting which we
> think arose from use of earlier text on SONET/SDH encoding types.
> Implementers should be encouraged to adhere to
> draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.

this document is in the RFC Editor and hangs on a cyclic reference to
the GMPLS architecture document

> ?? Loss of a signaling adjacency effectively makes a data-plane link
> unavailable. Since the network does not support crankback (yet),
> there is no way to recover from this situation. It is suggested that
> a link attribute be added to state whether the link capacity being
> advertised is available for new connection admission.

why operation described in section 2 (Section 2. Implications on Graceful
Restart) of GMPLS-OSPF is not applied in this case ?

> Issues that we seek guidance from CCAMP are: ?? There was a new
> capability proposed in which a client that has an SPC becomes UNI
> capable and the operator wants to create SC state for the client so
> that it can teardown the call (as opposed to the management system).
> Any thoughts on how this might be done would be appreciated.

use of the splicing operation with the already established SPC (using the
method described in section 6 of RFC 3471 and section 5 of RFC 3473) should
deliver the expected functionality

> ?? There is confusion if a Router ID must be the same value as a
> reachable IPv4 address on an LSR. RFC 2328 defines Router ID as: "A
> 32-bit number assigned to each router running the OSPF protocol." It
> is further clarified in footnote 9 that a Router ID is not an IP
> address. It specifically states: "The address space of IP networks
> and the address space of OSPF Router IDs may overlap." RFC 3477
> defines Router ID as: ". a stable IP address of an LSR that is always
> reachable if there is any connectivity to the LSR." It goes on to
> state: "If one is using the OSPF or ISIS as the IGP in support of
> traffic engineering, then it is RECOMMENDED for the Router ID to be
> set to the "Router Address" as defined in [OSPF-TE], or "Traffic
> Engineering Router ID" as defined in [ISIS-TE]." Unfortunately, it is
> not clear if the usage of Router ID here is referencing the OSPF
> Router ID or the Router ID as defined by RFC 3477. Clarification is
> requested. Maintaining the independence between OSPF's Router ID, and
> the IP addresses used on a LSR is a powerful and necessary
> capability as it allows for the renumbering of links without causing
> the revocation of the OSPF Router ID being used by an LSR and the
> resulting flushing and regeneration of all locally originated LSAs
> describing attached broadcast networks and links.

there are two statements in the above:
1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
   -> looking at the resp. definitions, the former is an address
   ("typically implemented as a "loopback address") and the latter is
   a 32 bit number that may make use of local IP address values
2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
   Router_Address/(IS-IS) TE Router_ID

so in both cases (as determined by 1.) what precludes rule 2 to be applied
in OIF IAs ? i should point out that above mentioned footnote does only
points out that "a network may have an IP address which is identical (when
considered as a 32-bit number) to some router's Router ID." it does not say
that the router_ID can not borrow its 32 bit number value from local IP
addressing space (section 5 of RFC 2328) - it is thus important to avoid
(in any case) the inferrence that RFC 3477 mandates that the OSPF Router_ID
to be both syntaxically and semantically an "IP address"

it is also unclear why OIF renumbering IAs require change of any Router_ID
in addition to the renumbering of the local/remote interface_id (for
unnumbered link) ? if this is the case - why so ?

> Requiring the Router ID to be a reachable IP address on the LSR
> results in an unnecessary behavior that causes significant churn in
> the LSDB, and potential disruption of TE-route calculation, when
> renumbering is done.

see above

> . MPLS-TE does not allow for nodes that are not participating in OSPF
> to be advertised. When an MPLS-TE LER relies on another node, such
> as a path computation server, to perform route calculation on its
> behalf, it is unnecessary for the LER to participate in OSPF.
> However, since the LER is not participating in OSPF, it has no way to
> advertise where it appears in the network. Consequently, ingress
> LERs will not be able to calculate routes to this egress LSR. A
> mechanism to advertise reachability of non-OSPF participating LERs
> needs to be developed.

there is somehow an ambuiguity in this question, using the following
<draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
reachability, but i don't see how the ingress LSR (client ?) could make
use of this information since ingress and egress LSR are simply nodes
not participating on the OSPF instance ?

> We also recommend the following item be considered by the ASON
> routing solutions design team:
>
> . The ASON routing architecture allows for the abstraction of
> information when hierarchical routing is utilized. This abstraction
> is handled by a transformation function that exists between the Child
> Area and the Parent Area. The amount of transformation of routing
> information performed can be described as a continuum with the
> following extremes: . Let all link and node information through with
> no changes . Abstract all link and node information provided by the
> Child Area into a single node. (This was successfully tested in the
> recent demo.)

-> i'll pass the above information to the ASON RSDT

> Other approaches exist on this continuum, but may be complex to
> define. Consequently, we believe these approaches may be best left as
> vendor specific approaches. Sincerely yours, Steve Joiner OIF,
> Technical Committee Chair cc: Jim Jones, John McDonough





Envelope-to: [e-mail]
Delivery-date: Mon, 30 Aug 2004 18:12:18 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>, [e-mail]
Subject: RE: Communication from the OIF
Date: Mon, 30 Aug 2004 11:09:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Adrian, Folks,

Just wanted to note that the OIF is very interested in reestablishing
relationships with the IETF and CCAMP.  This topic came up at the last
OIF meeting and a number of the participants expressed support and
urged that this be done soon.  There is already a regular slot in
the OIF agenda for reporting on new developments in the IETF that 
may be of interest.  I have also asked the OIF Secretariat to look
into mechanisms that would allow OIF draft documents to be accessible
to IETF members, if a liaison is sent asking for their review.

This particular liaison was sent following interoperability testing
done at OIF member labs prior to and leading up to the 2004
Supercomm show.  OIF would be very interested in comments on the
testing results and hope that the results will be helpful to IETF.

Cheers,

Lyndon Ong
(currently IETF liaison representative in the OIF)

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Saturday, August 28, 2004 4:52 AM
To: [e-mail]
Subject: Communication from the OIF


All,

We have received a communication from the OIF. This is pasted as ASCII text below.

You can see the PDF version at http://www.olddog.co.uk/incoming.htm

There are several direct questions and issues raised in the communication and we should
respond. Volunteers to draft text are eagerly sort.

Adrian

====
August 11, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group Chair
Mr. Alex Zinin, [e-mail], IETF, Routing Area Director
Mr. Bill Fenner, [e-mail], IETF, Routing Area Director
Re: Results from OIF World Interoperability Demo
Dear Adrian, Kireeti, Alex and Bill,
Thank you for your recent communication of June 27, 2004. We appreciate the ongoing
dialogue and
information provided.
As previously communicated, the OIF successfully held its World Interoperability Demo at
Supercomm
2004 (see http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf). This demo included the
ASON compliant OIF UNI and ENNI Implementation Agreements.
Due to the number of implementations involved (15 vendors, 7 carriers) we were able to
learn much
from the demo. The OIF would like to share some of these control plane results and solicit
guidance
from CCAMP on some issues. Successful interoperability tests included:
?? Switched Connections (SCs)- UNI clients calling other UNI clients
?? Soft Permanent Connections (SPCs) - network management driven calls including those
that
traversed ENNIs.
?? SC to SPC calls - a UNI client with a call to an SPC client (and vice-versa)
?? ENNI routing - link state inter-domain routing
?? Call using OC-3c and VC-4 links for an STS-3c equivalent connection. This used the
common
signal type of 6.
Some things we learned were:
?? In addition to the Srefresh message, it was helpful to periodically send the full
refresh message
as it helped the topology display system track calls. (This is consistent with an option
described
in RFC 2961 section 5.5.)
?? For SPCs, we determined that it was helpful to use a TNA as the context for the SPC
egress label
because for the interdomain case, the name of the egress network element would not
necessarily
be known.
?? Interpretation of the encoding for SUKLM. There was some inconsistency in the
interpretation
of the S bit setting which we think arose from use of earlier text on SONET/SDH encoding
types.
Implementers should be encouraged to adhere to draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
?? Loss of a signaling adjacency effectively makes a data-plane link unavailable. Since
the network
does not support crankback (yet), there is no way to recover from this situation. It is
suggested
that a link attribute be added to state whether the link capacity being advertised is
available for
new connection admission.
Issues that we seek guidance from CCAMP are:
?? There was a new capability proposed in which a client that has an SPC becomes UNI
capable
and the operator wants to create SC state for the client so that it can teardown the call
(as
opposed to the management system). Any thoughts on how this might be done would be
appreciated.
?? There is confusion if a Router ID must be the same value as a reachable IPv4 address on
an LSR.
RFC 2328 defines Router ID as:
"A 32-bit number assigned to each router running the OSPF protocol."
It is further clarified in footnote 9 that a Router ID is not an IP address. It
specifically states:
"The address space of IP networks and the address space of OSPF Router IDs may
overlap."
RFC 3477 defines Router ID as:
". a stable IP address of an LSR that is always reachable if there is any connectivity to
the LSR."
It goes on to state:
"If one is using the OSPF or ISIS as the IGP in support of traffic engineering, then it is
RECOMMENDED for the Router ID to be set to the "Router Address" as defined in
[OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]."
Unfortunately, it is not clear if the usage of Router ID here is referencing the OSPF
Router ID or
the Router ID as defined by RFC 3477. Clarification is requested.
Maintaining the independence between OSPF's Router ID, and the IP addresses used on a LSR
is
a powerful and necessary capability as it allows for the renumbering of links without
causing the
revocation of the OSPF Router ID being used by an LSR and the resulting flushing and
regeneration of all locally originated LSAs describing attached broadcast networks and
links.
Requiring the Router ID to be a reachable IP address on the LSR results in an unnecessary
behavior that causes significant churn in the LSDB, and potential disruption of TE-route
calculation, when renumbering is done.
. MPLS-TE does not allow for nodes that are not participating in OSPF to be advertised.
When an MPLS-TE LER relies on another node, such as a path computation server, to perform
route calculation on its behalf, it is unnecessary for the LER to participate in OSPF.
However,
since the LER is not participating in OSPF, it has no way to advertise where it appears in
the
network. Consequently, ingress LERs will not be able to calculate routes to this egress
LSR. A
mechanism to advertise reachability of non-OSPF participating LERs needs to be developed.
We also recommend the following item be considered by the ASON routing solutions design
team:
. The ASON routing architecture allows for the abstraction of information when
hierarchical
routing is utilized. This abstraction is handled by a transformation function that exists
between
the Child Area and the Parent Area. The amount of transformation of routing information
performed can be described as a continuum with the following extremes:
. Let all link and node information through with no changes
. Abstract all link and node information provided by the Child Area into a single node.
(This was successfully tested in the recent demo.)
Other approaches exist on this continuum, but may be complex to define. Consequently, we
believe these approaches may be best left as vendor specific approaches.
Sincerely yours,
Steve Joiner
OIF, Technical Committee Chair
cc: Jim Jones, John McDonough




Envelope-to: [e-mail]
Delivery-date: Sat, 28 Aug 2004 22:25:50 +0000
Message-ID: <004301c48d4d$894671f0$72849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-egress-control
Date: Sat, 28 Aug 2004 23:12:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The AD (Alex) has reviewed this draft and just has a couple of editorial nits.
If the editor (Lou) would like to make the changes and re-submit, we can get the draft to
go forward.

Lou, please don't forget to run the draft through the IDnits script before submitting it.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[e-mail]>

> Ed: please use the new ID boilerplates.
>
> > Abstract
> >
> >    This note clarifies the procedures for the control of the label used
> >    on a output/downstream interface of the egress node of a Label
> >    Switched Path (LSP).  Such control is also known as "Egress Control".
> >    Support for Egress Control is implicit in Generalized Multi-Protocol
> >    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
> >    signaling mechanisms and procedures and should be viewed as an
> >    informative clarification of GMPLS Signaling - Resource ReserVation
> >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
>
> Given that the doc goes STD track, I suggest that the last sentence is
> changed to say "This note is a clarification update to the specification
> of GMPLS Signaling..."
>
> > Author's Note
> >
> >    This draft is targeted for publication as a BCP.
>
> This one should be removed for the same reason.




Envelope-to: [e-mail]
Delivery-date: Sat, 28 Aug 2004 12:15:46 +0000
Message-ID: <24fd01c48cf8$2dbc7500$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Communication from the OIF
Date: Sat, 28 Aug 2004 12:51:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

We have received a communication from the OIF. This is pasted as ASCII text below.

You can see the PDF version at http://www.olddog.co.uk/incoming.htm

There are several direct questions and issues raised in the communication and we should
respond. Volunteers to draft text are eagerly sort.

Adrian

====
August 11, 2004
Mr. Adrian Farrel, [e-mail], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [e-mail], IETF, CCAMP Working Group Chair
Mr. Alex Zinin, [e-mail], IETF, Routing Area Director
Mr. Bill Fenner, [e-mail], IETF, Routing Area Director
Re: Results from OIF World Interoperability Demo
Dear Adrian, Kireeti, Alex and Bill,
Thank you for your recent communication of June 27, 2004. We appreciate the ongoing
dialogue and
information provided.
As previously communicated, the OIF successfully held its World Interoperability Demo at
Supercomm
2004 (see http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf). This demo included the
ASON compliant OIF UNI and ENNI Implementation Agreements.
Due to the number of implementations involved (15 vendors, 7 carriers) we were able to
learn much
from the demo. The OIF would like to share some of these control plane results and solicit
guidance
from CCAMP on some issues. Successful interoperability tests included:
?? Switched Connections (SCs)- UNI clients calling other UNI clients
?? Soft Permanent Connections (SPCs) - network management driven calls including those
that
traversed ENNIs.
?? SC to SPC calls - a UNI client with a call to an SPC client (and vice-versa)
?? ENNI routing - link state inter-domain routing
?? Call using OC-3c and VC-4 links for an STS-3c equivalent connection. This used the
common
signal type of 6.
Some things we learned were:
?? In addition to the Srefresh message, it was helpful to periodically send the full
refresh message
as it helped the topology display system track calls. (This is consistent with an option
described
in RFC 2961 section 5.5.)
?? For SPCs, we determined that it was helpful to use a TNA as the context for the SPC
egress label
because for the interdomain case, the name of the egress network element would not
necessarily
be known.
?? Interpretation of the encoding for SUKLM. There was some inconsistency in the
interpretation
of the S bit setting which we think arose from use of earlier text on SONET/SDH encoding
types.
Implementers should be encouraged to adhere to draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
?? Loss of a signaling adjacency effectively makes a data-plane link unavailable. Since
the network
does not support crankback (yet), there is no way to recover from this situation. It is
suggested
that a link attribute be added to state whether the link capacity being advertised is
available for
new connection admission.
Issues that we seek guidance from CCAMP are:
?? There was a new capability proposed in which a client that has an SPC becomes UNI
capable
and the operator wants to create SC state for the client so that it can teardown the call
(as
opposed to the management system). Any thoughts on how this might be done would be
appreciated.
?? There is confusion if a Router ID must be the same value as a reachable IPv4 address on
an LSR.
RFC 2328 defines Router ID as:
"A 32-bit number assigned to each router running the OSPF protocol."
It is further clarified in footnote 9 that a Router ID is not an IP address. It
specifically states:
"The address space of IP networks and the address space of OSPF Router IDs may
overlap."
RFC 3477 defines Router ID as:
". a stable IP address of an LSR that is always reachable if there is any connectivity to
the LSR."
It goes on to state:
"If one is using the OSPF or ISIS as the IGP in support of traffic engineering, then it is
RECOMMENDED for the Router ID to be set to the "Router Address" as defined in
[OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]."
Unfortunately, it is not clear if the usage of Router ID here is referencing the OSPF
Router ID or
the Router ID as defined by RFC 3477. Clarification is requested.
Maintaining the independence between OSPF's Router ID, and the IP addresses used on a LSR
is
a powerful and necessary capability as it allows for the renumbering of links without
causing the
revocation of the OSPF Router ID being used by an LSR and the resulting flushing and
regeneration of all locally originated LSAs describing attached broadcast networks and
links.
Requiring the Router ID to be a reachable IP address on the LSR results in an unnecessary
behavior that causes significant churn in the LSDB, and potential disruption of TE-route
calculation, when renumbering is done.
. MPLS-TE does not allow for nodes that are not participating in OSPF to be advertised.
When an MPLS-TE LER relies on another node, such as a path computation server, to perform
route calculation on its behalf, it is unnecessary for the LER to participate in OSPF.
However,
since the LER is not participating in OSPF, it has no way to advertise where it appears in
the
network. Consequently, ingress LERs will not be able to calculate routes to this egress
LSR. A
mechanism to advertise reachability of non-OSPF participating LERs needs to be developed.
We also recommend the following item be considered by the ASON routing solutions design
team:
. The ASON routing architecture allows for the abstraction of information when
hierarchical
routing is utilized. This abstraction is handled by a transformation function that exists
between
the Child Area and the Parent Area. The amount of transformation of routing information
performed can be described as a continuum with the following extremes:
. Let all link and node information through with no changes
. Abstract all link and node information provided by the Child Area into a single node.
(This was successfully tested in the recent demo.)
Other approaches exist on this continuum, but may be complex to define. Consequently, we
believe these approaches may be best left as vendor specific approaches.
Sincerely yours,
Steve Joiner
OIF, Technical Committee Chair
cc: Jim Jones, John McDonough




Envelope-to: [e-mail]
Delivery-date: Fri, 27 Aug 2004 14:42:35 +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-framework-00.txt
Date: Fri, 27 Aug 2004 10:39:13 -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 Framework for Inter-Domain MPLS Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-00.txt
	Pages		: 15
	Date		: 2004-8-20
	
   This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Label Switched Paths (LSPs) in multi-domain networks.

   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include IGP areas and Autonomous Systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-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-framework-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-framework-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-framework-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-framework-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: Wed, 25 Aug 2004 20:16:41 +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-tunproto-01.txt
Date: Wed, 25 Aug 2004 16:14:26 -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		: Generic Tunnel Tracing Protocol (GTTP) Specification
	Author(s)	: R. Bonica, et al.
	Filename	: draft-ietf-ccamp-tunproto-01.txt
	Pages		: 36
	Date		: 2004-8-25
	
This document describes the Generic Tunnel Tracing Protocol (GTTP).
   GTTP supports enhanced route-tracing applications.  Network operators
   use enhanced route-tracing applications to trace the path between any
   two points in an IP network including tunnels that support the traced
   path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-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-ietf-ccamp-tunproto-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-ietf-ccamp-tunproto-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.

--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-tunproto-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-tunproto-01.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, 24 Aug 2004 18:53:46 +0000
Date: Tue, 24 Aug 2004 14:43:16 -0400
From: Ronald Bonica <[e-mail]>
Subject: RE: feedback on GTTP: draft-ietf-ccamp-tunproto-00
To: 'Richard Rabbat' <[e-mail]>, [e-mail]
Message-id: <00d001c48a0a$3833ee50$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Yj458sZx4F3BQJ7FmbttVw)"

This is a multi-part message in MIME format.

--Boundary_(ID_Yj458sZx4F3BQJ7FmbttVw)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

Richard,
=20
Thanks for these comments. I have addressed them and sent an updated =
version
of the draft to the draft editor.
=20
                                                               Ron
=20

-----Original Message-----
From: Richard Rabbat [mailto:[e-mail]]=20
Sent: Monday, August 23, 2004 5:51 PM
To: 'Ronald Bonica'; [e-mail]
Cc: 'Richard Rabbat'
Subject: feedback on GTTP: draft-ietf-ccamp-tunproto-00


Hi Ron,
I just finished reading the draft and I have some feedback. Some of it
editorial + a few questions. Here goes. I hope this helps move this =
forward.
Richard.


--Boundary_(ID_Yj458sZx4F3BQJ7FmbttVw)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D919054218-24082004>Richard,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D919054218-24082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D919054218-24082004>Thanks=20
for these comments. I have addressed them and sent an updated version of =
the=20
draft to the draft editor.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D919054218-24082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D919054218-24082004>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Ron</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D919054218-24082004></SPAN></FONT>&nbsp;</DIV>
<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> =
Richard Rabbat=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, August 23, =
2004 5:51=20
  PM<BR><B>To:</B> 'Ronald Bonica'; [e-mail]<BR><B>Cc:</B> =
'Richard=20
  Rabbat'<BR><B>Subject:</B> feedback on GTTP:=20
  draft-ietf-ccamp-tunproto-00<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>Hi=20
  Ron,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>I just=20
  finished reading the draft and I have some feedback. Some of it =
editorial + a=20
  few questions. Here goes. I hope this helps move this=20
  forward.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New"=20
  size=3D2>Richard.</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_Yj458sZx4F3BQJ7FmbttVw)--



Envelope-to: [e-mail]
Delivery-date: Mon, 23 Aug 2004 21:54:28 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Ronald Bonica'" <[e-mail]>, <[e-mail]>
Cc: "'Richard Rabbat'" <[e-mail]>
Subject: feedback on GTTP: draft-ietf-ccamp-tunproto-00
Date: Mon, 23 Aug 2004 14:51:09 -0700
Message-ID: <002701c4895b$4cad46b0$3b3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C48920.A04E6EB0"

This is a multi-part message in MIME format.

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

Hi Ron,
I just finished reading the draft and I have some feedback. Some of it
editorial + a few questions. Here goes. I hope this helps move this =
forward.
Richard.
--
P.2.
-   MPLS LSP as well as they can trace through an IP-in-IP tunnel.
+   MPLS LSP as well as trace through an IP-in-IP tunnel.
=20
P.3.
=20
-   This section describes the generic route-tracing problem and =
provides

+   Section 1 describes the generic route-tracing problem and provides

=20

-   tunnels that support the trace path.

+   tunnels that support the traced path.

=20

P. 4.

replace:

=20

              --

             |D0|

              --

              |  -  H1  -                  H2                   -  H3  -

         (IP)  =
-|D|----|D|-------------------------------------|D|----|D|

                |1|    |2| H2:1  -        H2:2         -  H2:3 |3|    =
|4|

         (IP)   | |    | |------|D|-------------------|D|------| |    | =
|

                 -      -       |5| H2:2:1  -  H2:2:2 |6|       -      -

         (MPLS)                 | |--------|D|--------| |

                                 -         |7|         -

                                            -

With:

             +--+

             |D0|

             +--+

              | +-+ H1 +-+                 H2                  +-+ H3 =
+-+

         (IP) =
+-|D|----|D|-------------------------------------|D|----|D|

                |1|    |2| H2:1 +-+       H2:2        +-+ H2:3 |3|    =
|4|

         (IP)   +-+    | |------|D|-------------------|D|------| |    =
+-+

                       +-+      |5| H2:2:1 +-+ H2:2:2 |6|      +-+   =20

         (MPLS)                 | |--------|D|--------| |

                                +-+        |7|        +-+

                                           +-+

=20

-   route-tracing application must trace the route between the D1 and =
D4.

+   route-tracing application must trace the route between the devices =
D1
and D4.

=20

-   H1, H2 and H3. An IP-in-IP tunnel supports H2. The IP-in-IP tunnel

+   H1, H2 and H3. No tunnel supports H1 or H3. An IP-in-IP tunnel =
supports
H2. The IP-in-IP tunnel

=20

-   application provides these values and uses them to match traceProbes

-   with traceResponses.

=20

However, the timestamps are not used for matching, so suggestion to =
change:

+   application provides these values and uses the timestamps to match
traceProbes

+   with traceResponses.

=20

P. 5.

-   The Context Object identifies a VPN context. See Section Section 1.5

+   The Context Object identifies a VPN context. See Section 1.5

=20

P. 6.

-   for Context Object details.

+   for details on Context Object processing and Section 2.2.16 for =
format
details.

=20

-   The Source, Head-end and Context Objects are described above.

But the Context Object is not described above.

+   The Source, Head-end are described above.

=20

-      contained by an datagram whose TTL expired at the responding

+      contained by a datagram whose TTL expired at the responding

=20

You say:

>   The traceResponse message MUST include an Arrival Object if it

>   describes any interface other than the origination point of a traced

>   path or tunnel.

Is an Arrival Object included or not otherwise? (MAY, MUST NOT, etc.)

=20

P. 7.

=20

-   If traced path does not terminate on the responding device and the

+   If a traced path does not terminate on the responding device and the

=20

-   traceResponse message MUST contain a Next-hp Object. Otherwise, the

+   traceResponse message MUST contain a Next-hop Object. Otherwise, the

=20

-   identical Context Object. See Section Section 1.5 for details.

+   identical Context Object. See Section 1.5 for details.

=20

P. 8.

1.4.1.

1. There is no description of timeout procedures.=20

2. What are the timestamps originally? All 0's?

=20

-

   Object. If D1 does not grant access, it sends D0 a traceResponse

   indicating that access has been denied. If D1 grants access...

=20

Is this gttp_access_denied of page 18?

=20

P. 9.

Are there any concerns with the number of ICMP Time Expired messages?

=20

You say:

>   that access has been denied. (D1 would relay this message to D0.)...

=20

Is this relaying done using just forwarding?

=20

Do we need to decrement hop count anywhere? I don't see that.

=20

P. 10.

You say:

>  D0 repeats the process described above in order to discover the

>  balance of the top-level path.

What do you mean by "balance"?

=20

P. 13

-   Source Object many not uniquely identify the route-tracing

+   Source Object may not uniquely identify the route-tracing

=20

1.6 and 1.7

It seems that to detect transient changes is harder than the typical
traceroute application since transient changes may affect some tunnels =
but
not others in the hierarchy. Is that correct? Is there a best practice =
about
this issue?

=20

P. 15

-2.2 MessageFormats

+2.2 Message Formats

=20

P. 18

>      6 - gttp_malformed_object

Do we need a gttp_no_response or do we deal with it at the application
layer?

=20

P. 19-31:

Those are not messages, but the objects. I suggest to put 2.2.3 to =
2.2.13 in
separate section 2.3.1 to 2.3.11 under:

=20

2.3 Object Formats

=20

   The following subsections detail GTTP object formats

=20

2.3.1 The Source Object

...

This also has the side effect of aligning the paragraph number with the =
type
field.

=20

P. 19

-   route-tracing application is awaiting a traceResponse.

+   route-tracing application is listening for a traceResponse.

=20

P. 20

-   device received the traceProbe. It represents the number =
milliseconds

+   device received the traceProbe. It represents the number of =
milliseconds

=20

P. 22

-   The IP Header and Tunnel Objects are described in dedicated sections

+   The IP Header and Tunnel Objects are described in sections 2.2.10 =
and
2.2.12

=20

P. 24

>   and contain a valid IPv4 address.

This is the first time in the whole document that GTTP is said to only =
apply
for IPv4. Am I correct? Should it be mentioned earlier in the abstract =
or
introduction? Other IP addresses are not mentioned as IPv4 and need to =
be
explicitly mentioned.

=20

General question:

Introduction is a copy of the abstract. I suggest changing the abstract =
to
motivate and state what the draft proposes only.=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20


------=_NextPart_000_0028_01C48920.A04E6EB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>Hi=20
Ron,</FONT></SPAN></DIV>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>I just=20
finished reading the draft and I have some feedback. Some of it =
editorial + a=20
few questions. Here goes. I hope this helps move this=20
forward.</FONT></SPAN></DIV>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2>Richard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2>P.2.</FONT></SPAN></DIV>
<DIV><SPAN class=3D857164420-23082004><FONT face=3D"Courier New"><FONT=20
size=3D2>-&nbsp;&nbsp; MPLS LSP as well as they can trace through an =
IP-in-IP=20
tunnel.<?xml:namespace prefix =3D o ns =3D =
"urn:schemas-microsoft-com:office:office"=20
/><o:p></o:p></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D857164420-23082004>+&nbsp;&nbsp; MPLS LSP as well as trace =
through an=20
IP-in-IP tunnel.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D857164420-23082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D857164420-23082004>P.3.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D857164420-23082004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>-</SPAN>&nbsp;<SPAN =
class=3D857164420-23082004>&nbsp;=20
</SPAN></SPAN>This section describes the generic route-tracing problem =
and=20
provides</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>+</SPAN>&nbsp;<SPAN =
class=3D857164420-23082004>&nbsp;=20
</SPAN></SPAN><SPAN class=3D857164420-23082004>S</SPAN>ection&nbsp;<SPAN =

class=3D857164420-23082004>1 </SPAN>describes the generic route-tracing =
problem=20
and provides</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</P><o:p>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN =
class=3D857164420-23082004>-=20
</SPAN>&nbsp; </SPAN>tunnels that support the trace=20
path.<o:p></o:p></FONT></FONT></P></o:p><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3DArial>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>+</SPAN>&nbsp;<SPAN =
class=3D857164420-23082004>=20
</SPAN>&nbsp;</SPAN>tunnels that support the trace<SPAN=20
class=3D857164420-23082004>d</SPAN> path.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
4.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2>replace:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
</SPAN>--<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
</SPAN>|D0|<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
</SPAN>--<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
</SPAN>|<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>H1<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>-<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>H2<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>H3<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>-<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(IP)<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
</SPAN>-|D|----|D|-------------------------------------|D|----|D|<o:p></o=
:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>|1|<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =
</SPAN>|2|=20
H2:1<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>H2:2<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>H2:3 |3|<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>|4|<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(IP)<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>| =
|<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|=20
|------|D|-------------------|D|------| |<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|=20
|<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

</SPAN>-<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>|5| H2:2:1<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>H2:2:2 |6|<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(MPLS)<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>| |--------|D|--------| |<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>|7|<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>-<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>-<o:p></o:p></F=
ONT></FONT></P><SPAN=20
class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-spacerun: yes"><FONT face=3D"Courier New"=20
size=3D2>With:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>--+<o:p></o:p></FONT></FONT><=
/P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
</SPAN>|D0|<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;+</SPAN>--+</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
|&nbsp;+-+&nbsp;H1=20
+-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-+&=
nbsp;H3=20
+-+</FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(IP)<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;+</SPAN>-|D|----|D|-------------------------------------|D|---=
-|D|<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>|1|<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =
</SPAN>|2|=20
H2:1<SPAN style=3D"mso-spacerun: yes">&nbsp;+</SPAN>-+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>H2:2<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<SPAN=20
style=3D"mso-spacerun: yes"> </SPAN>H2:3 |3|<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =
</SPAN>|4|</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(IP)<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
+-+</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|=20
|------|D|-------------------|D|------| |<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;=20
+-+</SPAN><o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|5| =
H2:2:1<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;+</SPAN>-+<SPAN style=3D"mso-spacerun: =
yes">=20
</SPAN>H2:2:2 |6|<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>(MPLS)<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>| |--------|D|--------| |<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>|7|<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<o:p></o:p=
></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+</SPAN>-+<o:p></o:p></FONT>=
</FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"><FONT =
size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>route-tracing =
application must=20
trace the route between the D1 and =
D4.<o:p></o:p></FONT></FONT></P></SPAN></o:p>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>route-tracing =
application must=20
trace the route between the devices D1 and D4.</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>H1, H2 and H3. An =
IP-in-IP tunnel=20
supports H2. The IP-in-IP tunnel</FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>H1, H2 and H3. No tunnel =
supports=20
H1 or H3. An IP-in-IP tunnel supports H2. The IP-in-IP=20
tunnel</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2><FONT face=3D"Courier =
New">-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>application provides =
these values=20
and uses them to match traceProbes<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>-</SPAN>&nbsp;&nbsp; </SPAN>with=20
traceResponses.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>However, =
the timestamps=20
are not used for matching, so suggestion to=20
change:</FONT></SPAN></o:p></P><o:p><SPAN class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>+</SPAN>&nbsp;&nbsp; </SPAN>application =
provides these=20
values and uses the<SPAN class=3D857164420-23082004> =
timestamps</SPAN>&nbsp;to=20
match traceProbes<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>+</SPAN>&nbsp;&nbsp; </SPAN>with=20
traceResponses.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
5.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT size=3D2><FONT face=3D"Courier =
New">-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The Context Object =
identifies a=20
VPN context. See Section Section 1.5<o:p></o:p></FONT></FONT></P></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The Context Object =
identifies a=20
VPN context. See Section 1.5</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P.=20
6.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>for Context Object=20
details.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2><FONT face=3D"Courier =
New">+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>for details on Context =
Object=20
processing and Section 2.2.16 for format=20
details.<o:p></o:p></FONT></FONT></P><o:p></o:p></SPAN></o:p>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2><FONT face=3D"Courier =
New">-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The Source, Head-end and =
Context=20
Objects are described above.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>But the Context Object is not =
described=20
above.</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004></SPAN><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D857164420-23082004>+<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>The Source, Head-end are described above.</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>contained by an=20
datagram whose TTL expired at the responding</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"><FONT =
size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>contained by a=20
datagram whose TTL expired at the=20
responding<o:p></o:p></FONT></FONT></P><o:p></o:p></SPAN></FONT>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>You =
say:</SPAN></FONT></P><SPAN=20
class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp;&nbsp; </SPAN>The =
traceResponse=20
message MUST include an Arrival Object if =
it<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp;&nbsp; </SPAN>describes any =
interface=20
other than the origination point of a =
traced<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp;&nbsp; </SPAN>path or=20
tunnel.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"></SPAN><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>Is an =
Arrival Object=20
included or not otherwise? (MAY, MUST NOT, etc.)</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
7.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P><SPAN class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>-</SPAN>&nbsp;&nbsp; </SPAN>If traced path =
does not=20
terminate on the responding device and the</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>+</SPAN>&nbsp;&nbsp; </SPAN>If&nbsp;<SPAN=20
class=3D857164420-23082004>a </SPAN>traced path does not terminate on =
the=20
responding device and the</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Courier New"=20
size=3D2></FONT></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>traceResponse message =
MUST contain=20
a Next-hp Object. Otherwise, the</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>traceResponse message =
MUST contain=20
a Next-hop Object. Otherwise, the</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>identical Context =
Object. See=20
Section Section 1.5 for details.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>identical Context =
Object. See=20
Section 1.5 for details.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P.=20
8.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2>1.4.1.</FONT></SPAN></o:p></P><FONT face=3D"Courier =
New"><o:p><SPAN=20
class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2>1. There is no description of =
timeout=20
procedures. </FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2>2. What are the timestamps =
originally? All=20
0's?</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3DArial><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>-</FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Object. =
If D1 does=20
not grant access, it sends D0 a =
traceResponse<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>indicating that=20
access has been denied. If D1 grants access<SPAN=20
class=3D857164420-23082004>...</SPAN></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>Is this gttp_access_denied of =
page=20
18?</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>P. 9.</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><SPAN class=3D857164420-23082004>Are there any concerns with =
the number of=20
ICMP Time Expired messages?</SPAN></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><o:p><SPAN =
class=3D857164420-23082004></SPAN></o:p></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2><o:p><SPAN class=3D857164420-23082004>You=20
say:</SPAN></o:p></FONT></P><FONT><o:p><SPAN class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp;&nbsp; </SPAN>that access =
has been=20
denied. (D1 would relay this message to D0.)<SPAN=20
class=3D857164420-23082004>...</SPAN></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>Is this =
relaying done=20
using just forwarding?</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>Do we =
need to decrement=20
hop count anywhere? I don't see that.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN></o:p>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P.=20
10.</FONT></SPAN></o:p></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>You=20
say:</FONT></SPAN></o:p></P><o:p><SPAN class=3D857164420-23082004>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp; </SPAN>D<SPAN=20
class=3D857164420-23082004>0</SPAN> repeats the process described above =
in order=20
to discover the<o:p></o:p></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN style=3D"mso-spacerun: yes"><SPAN=20
class=3D857164420-23082004>&gt;</SPAN>&nbsp; </SPAN>balance of the =
top-level=20
path.</FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>What do =
you mean by=20
"balance"?</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
13</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Source Object many not =
uniquely=20
identify the route-tracing</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Source Object may not =
uniquely=20
identify the route-tracing</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>1.6 and=20
1.7</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>It seems =
that to detect=20
transient changes is harder than the typical traceroute application =
since=20
transient changes may affect some tunnels but not others in the =
hierarchy. Is=20
that correct? Is there a best practice about this =
issue?</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
15</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-2.2=20
MessageFormats</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+2.2 =
Message=20
Formats</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
18</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>&gt;<SPAN =

style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>6 -=20
gttp_malformed_object</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>Do we =
need a=20
gttp_no_response or do we deal with it at the application=20
layer?</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P.=20
19-31:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>Those are =
not messages,=20
but the objects. I suggest to put 2.2.3 to 2.2.13 in separate section =
2.3.1 to=20
2.3.11 under:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>2.3 =
Object=20
Formats</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp; The=20
following subsections detail GTTP object formats</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN=20
class=3D857164420-23082004>&nbsp;</P></SPAN></FONT></FONT>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>2.3.1 The =
Source=20
Object</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>...</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>This also =
has the side=20
effect of aligning the paragraph number with the type =
field.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
19</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>route-tracing =
application is=20
awaiting a traceResponse.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>route-tracing =
application is=20
listening for a traceResponse.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Courier New"><FONT=20
size=3D2><SPAN class=3D857164420-23082004>P.</SPAN><SPAN=20
class=3D857164420-23082004>&nbsp;20</SPAN></FONT></FONT></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>device received the =
traceProbe. It=20
represents the number milliseconds</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>device received the =
traceProbe. It=20
represents the number of milliseconds</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
22</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>-<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The IP Header and Tunnel =
Objects=20
are described in dedicated sections</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>+<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The IP Header and Tunnel =
Objects=20
are described in sections 2.2.10 and 2.2.12</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>P. =
24</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>&gt;<SPAN =

style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>and contain a valid IPv4 =

address.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>This is =
the first time=20
in the whole document that GTTP is said to only apply for IPv4. Am I =
correct?=20
Should it be mentioned earlier in the abstract or introduction? Other IP =

addresses are not mentioned as IPv4 and need to be explicitly=20
mentioned.</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2>General=20
question:</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2>Introduction is a copy=20
of the abstract. I suggest changing the abstract to motivate and state =
what the=20
draft proposes only. </FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" =
size=3D2></FONT></SPAN><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial></FONT>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in =
0pt">&nbsp;</FONT></SPAN></P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial></FONT>&nbsp;</P><o:p></o:p></FONT></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial><o:p></o:p></FONT>&nbsp;</P><o:p></o:p></FONT></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial><o:p></o:p></FONT>&nbsp;</P><o:p></o:p></FONT></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial><o:p></o:p></FONT>&nbsp;</P><o:p></o:p></FONT></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</P>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT face=3D"Courier New" size=3D2><FONT=20
face=3DArial><o:p></o:p></FONT>&nbsp;</P><o:p></o:p></FONT></SPAN>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D857164420-23082004><FONT size=3D2></FONT></SPAN><FONT =
size=3D2></FONT><FONT=20
size=3D2></FONT><FONT=20
size=3D2></FONT></SPAN></o:p></SPAN></o:p></FONT></SPAN></o:p></FONT></SP=
AN></o:p></FONT></SPAN></SPAN></o:p></FONT></SPAN></o:p></SPAN></o:p></SP=
AN></FONT><FONT><SPAN=20
class=3D857164420-23082004>&nbsp;</P></SPAN></FONT></FONT></SPAN></o:p></=
SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_0028_01C48920.A04E6EB0--




Envelope-to: [e-mail]
Delivery-date: Sat, 21 Aug 2004 00:38:06 +0000
Message-ID: <[e-mail]>
Date: Fri, 20 Aug 2004 16:34:33 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: A note on LMP/G.7714 (long)
To: ccamp IETF <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

With the working group draft on transport-lmp that
details the functionality of
LMP and G.7714 (and .1) side by side it seems like its
about time to try putting
these two together in some way.  The reasoning for
this that its been six years
since a number of vendors (okay at least a couple)
implemented pre-standard
GMPLS/G.ASON functionality and neither LMP nor
G.7714.1 currently provide all 
the basic functionality that these early
implementations (which are currently 
running in many carrier networks) provide for
SONET/SDH.
Namely,
(1) Automatic discovery of link endpoints with no
manual provision
(2) Bi-directional connectivity verification (checking
for mis-wired fiber
pairs)
(3) Integration with routing protocols.

These early implementations were limited to a single
layer (as opposed to
G.7714.1 that applies to all SDH/OTN layers) and
utilized an IGP hello protocol
running over either the line (Multiplex Section) or
section (Regenerator
Section) DCC.  Note that the hello protocol running
over the DCC would also
provide the bi-directional connectivity verification.
Since the hello protocol
was already integrated with the routing protocol no
extra integration was
required.  Hence a nice neighbor discovery,
verification, and topology/resource
discovery functionality was delivered in relatively
short time by vendors that
took this approach.
Besides working at only one layer this approach didn't
deal well with cases
where there was a requirement for true data/control
plane separation, i.e., the
DCC wasn't usable for some reason. In addition such an
approach doesn't take
into account link bundling which can be important in
many but not all cases.

Here's a simple single layer use case where I try to
utilize both G.7714.1 and
LMP/LMP-Sonet-Test.
As a simplifiying assumption I'm assuming all
unnumbered links and IPv4
addresses for the various entities.
I'll assume that the Discovery Agent of G.7714.1 and
LMP entity on the same
system use the same IP address.
Let's assume SONET line terminating equipment (ADM or
Xconnects).
(1) Use G.7714.1 messages over the SONET line DCC
(either LAPD or PPP format),
with the DCN DA Address format.
(2) From the DCN DA address (equal to the LMP entity
IP addresses) we can bring
up an LMP control channel.
(3) As sugggested in Appendix III of G.7714.1 I could
use the TraceMonitor
(along with the TraceMonitorAck) message to convey
back received information to
the sender for bi-directional connectivity
verification. TraceMonitor messages
from draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
(4) With preconfigured rules such as "bundle all" or
"bundle none") one side or
the other can initiate the link summary procedures of
LMP to determine the
bundling.  I'm assuming that bundling can be
re-negotiated at a later time if
desired, e.g., some one from a management systems
decides to change the
bundling.
Effort required: 1 procedure from G.7714.1, 3 from
LMP: Control channel config,
TraceMonitor (for bi-directional connectivity), and
Summary for bundling.

Here's a simple two layer use case.  Suppose the two
switches above are
interconnected by 20 OC-192 signals via a WDM system
that looks like section
terminating equipment (STE).  Suppose that the WDM
takes 10 of the OC-192 and 
multiplexes them onto 1 fiber pair for transport and
takes the other 10 and
places them on another diversely routed fiber pair.
How can discovery and LMP
help us bundle the OC-192 links correctly at the line
layer?  Line layer 
discovery won't tell us any more than we learned in
the previous example.
Here's how:
(1B) In addition to discovery at the line layer lets
do discovery at the section
layer. Recall that the switches also operate at the
section layer as well as the
line layer.  In this case the switches will be
discoverying the WDM systems and
not each other.  Using the DCN DA Address format
G.7714.1 with either the J0 or
section DCC we can learn the address of the LMP
entity.
(2B) Bring up a LMP control channel between the switch
and the LMP system. Make
sure to assign it (a different CC ID could be helpful
if not strictly
necessary).
(3B) Perform bidirectional connectivity verification
like above (this time
between switches and WDM equipment).
(4B) Since the WDM system knows which OC-192 signals
are multiplexed onto which
fiber pairs. It can set the bundling correctly, i.e.,
bundle at most into two
TE links but not one.
(5B) With the information obtained on link bundling
from the WDM system the
switches can renegotiate their bundles into the
appropriate TE links.

Note that in this situation the WDM system
(particularly if its a fixed
mux/demux) doesn't need to run a routing protocol just
G.7714.1 at a particular
layer and a small subset of LMP.  At this point we're
talking about nice added
value functionality over previous proprietary
implementations.  Some might
suggest that in step (4B) that the WDM system should
just assign appropriate
SRLG ID's to the (LMP) "data links" that are carried
over the two diversely
routed fiber pairs.  There currently isn't a mechanism
for this so I used what
was available and let the lowest layer start with the
bundling rules.

I'm sure the LMP and G.7714 experts will let us know
if the above can work. If
so it might be handy to put in the LMP-transport
document (suitably cleaned up).

Greg B.

Greg Bernstein
Grotto Networking




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush



Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:27:55 +0000
Message-ID: <0a2301c4869f$f8dfe000$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>, "yuichi Ikejiri" <[e-mail]>
Subject: draft-vasseur-ccamp-loose-path-reopt-02.txt to WG status
Date: Fri, 20 Aug 2004 10:30:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The consensus seems to be that this draft should be adopted by the WG.

Authors, please republish as draft-ietf-ccamp-loose-path-reopt-00.txt with no changes
(except, please make sure that you have the I-D boilerplate correct).

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:27:38 +0000
Message-ID: <0a2401c4869f$f9f76a80$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Jonathan Lang" <[e-mail]>
Subject: draft-aboulmagd-ccamp-transport-lmp-02.txt to WG status
Date: Fri, 20 Aug 2004 10:30:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The consensus seems to be that this draft should be adopted by the WG.

Authors, please republish as draft-ietf-ccamp-transport-lmp-00.txt with no changes
(except, please make sure that you have the I-D boilerplate correct).

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:27:26 +0000
Message-ID: <0a2501c4869f$fadb3ad0$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: New CCAMP WG drafts
Date: Fri, 20 Aug 2004 10:33:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Please accept the following four new CCAMP WG drafts that will be submitted over the next
few weeks.

draft-ietf-ccamp-loose-path-reopt-00.txt
draft-ietf-ccamp-transport-lmp-00.txt
draft-ietf-ccamp-rsvp-restart-ext-00.txt
draft-ietf-ccamp-inter-domain-framework-00.txt

Thanks,

Adrian Farrel (CCAMP co-chair)




Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:27:14 +0000
Message-ID: <0a2101c4869f$f6c47a10$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "'Jean Philippe Vasseur'" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>
Subject: draft-farrel-ccamp-inter-domain-framework-01.txt
Date: Fri, 20 Aug 2004 10:30:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The consensus seems to be that this draft should be adopted by the WG.

As I am the editor, please complain vociferous on the list and to Kireeti if you do not
believe this to be the case.

I will republish as draft-ietf-ccamp-inter-domain-framework-00.txt

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:27:00 +0000
Message-ID: <0a2001c4869f$f1b612e0$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Tove Madsen" <[e-mail]>
Subject: Re: Draft minutes from San Diego
Date: Fri, 20 Aug 2004 10:20:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I didn't hear any comments.
Tove, did you get any private comments?

Otherwise I'll submit the minutes at close of business today.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Tove Madsen" <[e-mail]>
Sent: Thursday, August 12, 2004 6:31 PM
Subject: Craft minutes from San Diego


> From Tove.
>
> Please send comments on list or direct to her.
>
> Thanks,
> Adrian
>
> Hi ccamp,
>
> Here are the minutes from our meeting in SD. Please review, feedback and
> changes are appreciated until next Thursday, thanks!
>
>  Special thanks to typers Deborah B, Susan H and Giles H!
>
> /  Tove Madsen
>
> --------------070301030408020006090705
> Content-Type: text/plain;
>  name="ccamp minutes rev02.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="ccamp minutes rev02.txt"
>
> CCAMP
> -----
>
> Agenda bashing - Adrian
> -----------------------
>
> no new RFCs since Seoul.  Waiting for Aug 9th to push a bunch of stuff through.  G.709
> with Alex (AD).  Will publish 15 RFCs once done.
>
> Bunch of drafts not being covered today:
>
> JP's router capability stuff.  Need some discussion on list.
>
> JP's loose path reoptimisation.  Is this something we want?  interdomain but with
> intradomain usage. <10 hands showing have read it.  Will go to list to check we're happy
> before taking into WG.
>
> Alarm info.  Said on list a while ago that considered it done and considering WG last
> call.  anyone objecting to last call?  No.
>
> Crankback and route exclusing waiting for multi-domain.  Both have implementations.
>
> Tom and Adrian will sit down this week to work on MIBs.  Lack of interest so far. Anyone
> MIB-interested willing to help?
>
> Tunnel trace - no interest shown at all.
>
> Link bundling - perhaps needs a clarification draft to show what was intended.
>
> MPLS/GMPLS migration/interworking is something we ought to care about (will be networks
> that need to talk and perhaps gradual migration).  Needs review and comment from WG.
>
> Useful new draft on misconnection analysis.  Authors planning new rev so now's a good
time
> to comment on-list.
>
> Survey for mesh restoration.  Fair bit of input, would be useful to get feedback from
SPs
> who'd be answering the survey and from implementors (who'll want to know what to
> implement).  Feedback on list or to authors would be good.
>
> Q (Vishal). Diverse path routing draft?
>
> A (Kireeti).  Have a set of slides on inter-area strategy.
>
> Milestones - Kireeti
> --------------------
>
> Going well but got the year wrong!
>
> There will be one more revision of protection/restoration.
>
> Minor edtis needed on ASON.
>
> Will talk later on strategy for inter-whatever.
>
> GTTP is stuck.  People who were driving have driven away.  Need to poll authors and WG
to
> see if there's any interest.  if not will take off the charter.
>
> Minor edits for ASON routing reqs.
>
> Need to talk about charter.  Adrian went over much of work that needs to be done.
>
> Promised us again that MIBs will be done.  Can't progress standards work without MIBs.
> Need to close off ASON stuff, multi-region and protection/restoration.  Various misc.
docs
> that are WG docs so we need to decide whether to complete or drop.
>
> Need to realise how much work we have on our plate before we add more work.
>
> Clarification required on label allocation for different switching types.  Also on how
to
> take the switching/encoding type into consideration when doing CSPF.  Might need to
modify
> old docs, do new ones, or do "clarifications" doc.
>
> New work items
> --------------
>
> MPLS/GMPLS interworking/migration.  e.g. two ways to signal a PSC label (MPLS or GMPLS).
> Need to work it out and have migration path.  Putting on charter will help.
>
> Inter-domain signalling/routing. Already working on it.  Nice to have a work item
> explicitly saying it.
>
> Big one is L1VPN.  SG13 have said they're working on it.  Want the same relationship
with
> SG13 as we're trying to forge with SG15.  They do reqs, we do protocol work.  But who is
> "we" - just someone in IETF.  One option is a new WG.  Other option is to do in CCAMP.
If
> we do in CCAMP it will take the following (note two issues - is this a good summary of
> work to be done, is this what we want to do in which case take to ADs who hopefully will
> say no):
>
> Once we get framework/applicability done then:
>
> Do protocol work.  Will have to liase within IETF (e.g. with L3VPN WG as have VPN
> discovery and CE-PE ID exchange docs).  Also with ITU-T.  Of course if we have routing
> extensions then OSPF/ISIS will get involved.
>
> If we go down this path then we need a design team.
>
> So plan is :
>
> 1) take to list to see if have consensus in CCAMP for charter extension.
>
> seemed enough hands to take to list.
>
>
> ASON
> ----
>
> Have 3 drafts.  2 gone through AD review.  Last one on Alex's "to read" list.  Just
before
> this meeting couple of people pointed out that there's a disconnect with key ITU spec.
So
> DT needs to sit with these people and figure out what disconnect is and how significant
it
> is.  Will attempt to start discussion this week (face to face).
>
>
> Dimitri - RSVP-TE for ASON
> --------------------------
>
> refreshed since last IETF.
>
> 2 discussion points:
>
> Is the definition of link capability usable in wider scope?
>
> Can we define the notify message usage in detail?
>
> Doc has been shown to be stable.  Needs editorial review ASAP.
>
> Aim was to be ready for last call post San Diego.
>
>
> Dimitri - ASON Routing DT
> -------------------------
>
> Aim is to evaluate routing protocols against ASON routing requirements.
>
> Need to elaborate the applicability scenarios.  DT looking at two scenarios. If anyone
has
> a good scenario that needs to be addressed they can pass it to the DT.
>
> Result of evaluation will be integral part of draft.
>
> First cut at Adrian's website.
>
> ToC of reqs.
>
> Needs scenarios and needs user community to feed scenarios in.
>
> First CCAMP WG doc needed by end of this month so will have to push hard.
>
> Will be liased with SG15/OIF to get inputs before doing protocol work.  Need to focus on
> the evaluation work.
>
> Q (Zafar).  One comment regarding template.  Would recommend not having reqs section as
> already have a requirements doc.   If repeated it can become confusing.
>
> Dimitri - want at least to have pointers to the requirements. That way people have in
mind
> the scope of the architecture.  Structure of doc may change.
>
>
> Don Fedyk - Transport review of LMP.
> -----------------------------------
>
> Aim is to facilitate ITU/IETF communication.  Issue with discovery is involves databases
> used to control optical networks.
>
> LMP discovery is there to find a TE link.
>
> Documents ITU discovery terminology.
>
> Idea here is to document "secret decoder ring".
>
> changes:
>
> 1) Clarified G.7714
>
> 2) TE link definition.
>
> 3) General clarification.
>
> Think is useful for IETF people to understand where ITU-T discovery procedures are and
> vice-versa.  Hence requesting is WG doc.
>
> Q (Vishal) - any attempt to work on discovery procedures or does this just clarify
> definitions?
>
> A (Don) - just informational.  Stories on either side aren't complete yet.  So will live
> until those are solidified. Not aiming to define here.
>
> Q. (Vishal) - Think it is a good doc.  Is there any work to unify the procedures or do
> procedures here to mirror ITU work?
>
> A. (Kireeti) - first thing is identifying the secret decoder ring.  Show diffs between
ITU
> and IETF.  Second is to start series of liasons to SG15 (or whatever) to figure out if
we
> fix it, they fix it, or work together. So get better picture of how to proceed. But
right
> now need to understand each other.
>
> Adrain - have heard comment about it being good and useful from many people recently.
> fits in charter.  would like to see it as a WG doc.  show of hands!
>
> handful of hands. (Adrian thinks reasonable).  Nobody saying should not be WG doc.  Take
> to list.
>
>
> Wesam Alanqar - ITU-T SG 15
> ---------------------------
>
> Various links to liason info.
>
> Picture of optical control plane (ITU-T SG-15 Q14/Q15)
>
> ITU-T wants to thank CCAMP - especially ASON reqs DT for capturing reqs for link-state
> routing.  Q14 wants to extend this.  Analysing OSPF/IS-IS/PNNI for use in ASON.
> Encouraging work with different standards bodies to look at implications for routing
> protocols.  Have template for this.
>
> Q14 thinks a cross-body DT may be useful to look at use of IETF routing protocols.
> Similar to the ASON routing reqs. DT.  Various things to look at.
>
> Recent docs finished in ITU-T:
>
> G.7715.1 on Link state reqs for ASON
> G.7713 call connection mgmt.
>
> Meeting Nov 1-5 in Berlin.  IETF welcome to come.  Contact Kam Lan for more info by
24/9.
> Contributions by 25/10.
>
> Q. (Zafar).  Last IETF had discussions on OIF also.
> Do chairs want to comment?
>
> Kireeti - what do you want to talk about?
>
> Q. (Zafar) What's the feel of liason with OIF?  Is it progressing?
>
> Kireeti - No formal liason relationship with OIF.  Been communicating.  OIF has asked
for
> formal liason.  Figuring out what needs to be done on each side.  Most interesting is to
> synchronise routing work.  ITU relationship is good - ITU does reqs, IETF does protocol
> work and liase back.  Would like to do same with OIF either formally or not.  Form of
> relationship still to be figured out - but again want OIF to give us reqs, we do
protocol,
> they say if is good.  avoids redoing work.
>
> Q. (Monique) - OIF meeting last week.  Trend towards OIF/ITU alignment as well as
> OIF/IETF.  will be contribuition to that effect.
>
> Adrian - we'll try to nail down the lacuna in comprehension for requirements after
> meeting.
>
>
> Protection drafts - Adrian
> --------------------------
>
> 3 drafts.  Been through WG last call and marked up.  With chairs (Kireeti) to check
> markups are fine before pushing forward.
>
>
> Dimitri - RSVP-TE extns for e2e GMPLS-based recovery
> ----------------------------------------------------
>
> v01 submitted in may.
>
> have addressed issues raised on list:
>
> 1) mis-ordering during secondary LSP full instantiation (8.3)
> 2) preempt resource of lower pri LSPs when protecting LSP activated (10).
>
> Updates since v00 addressing concerns/expectation.
>
> Need to check sec 13 (external commands).
>
> Check Implementations status out there, external commands still open.
>
> Once that issue closed then we can go to last call.
>
> Also had editorial review already.
>
> Adrian - so not quite ready for last call?
>
> Dimitri - we should see whether impl. of section 13 is also there then respin with or
> without that section.
>
> Q (Zafar) - Later on will work on inter-as recovery.  would be good if this doc
addresses
> intra-region.  is that (or will it be) stated in the doc?
>
> Kireeti - base spec doesn't say so won't start now keep separate.
>
> Q (Zafar) - Issue on reoptimisation of bidirectional LSP.
>
> Adrian - not sure this draft is relevant to that.  Worth having discussion, but distinct
> from this.
>
>
> Lou Berger - Extensions to GMPLS RSVP graceful restart
> ------------------------------------------------------
>
> Arun's draft.  Lou's reordered a couple of slides.
>
> Merged draft (following consensus from Seoul). (draft-aruns and draft-rahman).
>
> Major change is addition of support for improved scalability.  In Aruns original draft
> every piece of state had to be sent.  Now can use summary refresh to decide which pieces
> to resignal.  Way this is done is that node adj. to restarting node can send back path
> message from restarting node so restarting node can recover the state it originally
> advertised.  Big step forward from (RFC)3473.  In 3473 no way for ingress to recover
> state.  As compared to prev. version only sends state that is needed. Use summary
refresh
> for this.  Have added recovery path summary refresh so restarting node can just look at
> stuff it hasn't kept across restart.  If adj nodes support this extn (can discover that)
> then can use these procedures.
>
> To do:
>
> 1) Need to agree message type
>
> 2) discussion amongst authors about adj node startarts.  If two adj nodes restart then
how
> does 2nd one know the 1st is in restart condition.  Impacts sending of path msg and
> recovery labels.  This is a broader problem than just this draft.  Applies to 3473
> independent of these extns.  So issue is both what to do and where to do it.
>
> Next steps:
>
> Authors think ready for WG doc.  Chairs?
>
> Kireeti - how many people have read this.  Scattering.
>
> How many thinks it should be WG doc - most of them
>
> How many opposed - zero.
>
> some support - take to list.
>
> Kireeti - one comment on adj node restart.  Most other protocols don't care about this.
> Idea is that if lots of nodes restart at once then your network is screwed anyhow.  With
> OSPF nodes abandon restart if that occurs.  BGP, OSPF, IS-IS and prob LDP do this.
>
> Lou - not all that difficult to do. One prob is where put recovery stuff in path msg.
> Other issue is timer adjustments if you see your neighbour restarting.  Could argue is
in
> 3473 already - may just need clarification. But good comment.
>
> Adrian - chairs in violent disagreement over Kireeti's last comment.  Highlight is that
> restart is complex as well as important.  There are people out there who do a lot with
it.
>
>
> Zafar Ali - Node ID based RSVP Hello
> ------------------------------------
>
> Incorporated feedback from mailing list and Seoul discussions.
>
> Remaining work is minimal.
>
> Draft is short/straightforward.
>
> >=5 implementations.
>
> Some inter-op testing done.
>
> want to do WG last call.
>
> Adrian - who's has not read the draft who is responsible for MPLS/GMPLS impl.  Lou.
>
> Adrian - have met all criteria to go forward.  Authors happy, draft stable, comments
dried
> up.  So will debate last call on list.
>
>
> Kireeti - Multi zone
> --------------------
>
> 2 drafts for this.  Issue is what is a zone - IGP area, AS, tech domain, protect domain.
>
> Also want to have one way to do this - esp as both drafts were RSVP-TE based.
>
> Single common doc now.  Many iterations/rewrites.  Now one mechanism with diff options.
>
> have functional docs:
>
> 1) Framework (not on slide)
> 2) signalling
> 3) path computation
> 4) (not a doc) BOF on PCE to look at other ways of doing this (run by Adrian and JP).
>
> Need more docs:
>
> 1) Applicability - what options to use for a given req.
> 2) Stitching.  Similar but different to nested LSP.  Does it become a separate doc.
> Certainly need doc on it.
>
> Debate on protection/restoration and diverse routing inter-domain.  Aim is to get base
> spec out.  Once stable work on diverse path setup across domains.
>
> Vishal - have had discussion on list.  Basic req in reqs doc is diverse path routing.
> Could do solution for single path routing that might not work at all for diverse paths.
> Suggestion is to break up items and push diverse path routing etc. into "advanced
> applications". Needs to be taken into consideration for signalling/routing.  Need to
look
> at problem together and not separate.
>
> Kireeti - what we've done (successful so far).  Did base spec for signalling and had
> separate DT to do protection/restoration.  Base spec for routing, and added on stuff
> afterwards.  If you can give us a concrete example of where this won't work then we'll
> look at it.
>
> Vishal - not just me.  SPs want to link it together.
>
> Kireeti - fine.  That's one opinion.
>
> Vishal - not resolved yet.
>
> JP - this has been taken into consideration.  scenarios 1 and 2 for path computation
> consider this, so already part of base spec.  Not true to say it has been excluded.
>
> Vishal - but not being discussed.  Draft says it is advanced application.  This
shouldn't
> be.
>
> JP - not being excluded.
>
> Kireeti - not taking off the agenda.  Will do it but want to get base spec out.  Want to
> leave room in spec for other applications (not just diverse path routing). But doesn't
> mean we have to spec that out now.  If JP's done the work to ensure it's possible then
> Kireeti's happy.
>
> Vishal - I raised Qs on list which weren't answered.  Especially regarding scalability.
Is
> not even clear how single path works.
>
> Arthi - what do you mean by "let's get base spec out"?  Currently docs aren't even WG
> docs.  I think Vishal is saying at least we need to move forward to some extent with
base
> docs.  They're just individual contributions right now.
>
> Kireeti - that's what I'm saying.  Not vishal
>
> Adrian - nobody's saying we'll take unprotected to RFC before we even look at protected
> stuff.  We're rather saying we want to understand unprotected before we understand
> protected since latter is built on former.
>
> Vishal - issue is diverse paths.  Doesn't work if you build on single path approaches.
> Diverse paths is a key issue - so consider at the beginning, don't retrofit.
>
> JP - that was the case.
>
> Zafar - to answer Vishal there are enough cases to show that base stuff works and is
> extendible for future.  Crankback is an example.  Lots of stuff needs to be done later,
> and need stake in ground for base work with enough hooks.  Nothing is excluded today.
>
> Dimitri - can we make it clear that as docs are extended they take G of GMPLS into
> account.
>
> Lou - question re stitching?
>
> Kireeti - details have to be done.  That's not a question.  Question is is this new
draft
> or existing drafts.
>
> Vishal - are we going to poll the WG?
>
> Kireeti - can I finish my slides first?
>
> Kireeti again:
>
> how to progress:
>
> Have an idea of what docs we need.
>
> Reqs came from TEWG.
>
> In light of proposed solutions should revisit the TEWG reqs. and check reqs are
> reasonable.
>
> Sep docs for sep. functions (signalling/path computation/poss. rechability).
>
> Progres each doc separately - but may send for RFC as a block.
>
> Once have base spec done will look at re-optimisation and diverse paths.  Want to do
base
> spec first.  If in our evaluation that isn't a major retrofit then will progress base
spec
> while working on rest in parallel.  If turns out is a major retrofit then will halt
> progress and retrofit first.
>
> Vishal - my point still stands.
>
> Kireeti - we've heard it several times.
>
> Vishal - so what are you going to do?
>
> Kireeti - nothing.
>
> Vishal - but WG hasn't been polled.
>
> Adrian - WG chairs exist to judge consensus.  We believe we have judged it and the right
> way to do this technically.  You're welcome to disagree and build an opinion against it.
>
> Vishal - want to get work done not build opinions.
>
> Adrian - so do we.
>
> Vishal - so what will we do about diverse paths?
>
> Adrian - keep draft alive as a private draft.  Then have basis when WG ready to take on.
> That's good.
>
> Kireeti - you might be missing that the difference in what you're saying and what we're
> saying is just sequencing.  We want to do a then b. you want to do in parallel.  If we
> find that base doc needs major retrofit then we'll halt it.
> We need to have a tech reason for doing this, and don't have a base doc yet.
>
> Vishal - so can keep individual docs going?
>
> Kireeti - yes, renew it every 5 months and 29 days.
>
>
> Adrian (with chair hat removed)
> -------------------------------
>
> Had couple of proposals for inter-region/inter-AS TE a while back.
>
> Ended up with a useful, but long, draft.
>
> Have split into diff parts.  JP and Arthi will talk about soln. specific texts.
>
> This draft is just framework to point to what you could do.
>
> Key is defn of a domain:
>
> seems necessary to extend this beyond just IGP areas and ASes to protection domains and
> zones of limited TE visibility.  So domain is a loose concept.
>
> Aim is not to recommend solution but to break problem down to show different ways of
> signalling, path computation and routing.
>
> Describes some "easy" advanced features and applicable to MPLS/GMPLS.
>
> Not attempting to look at harder issues (e.g. diversity, OAM, P2MP).
>
> Not making judgements as to why you'd pick one method rather than another (or
documenting
> those methods/solns).
>
> TEWG produced two reqs docs. had quite a bashing and rework.  Question is whether we're
> happy to freeze the docs as RFCs or keep alive as do solution work in case we find
> ambiguities/contradictions and need to fix them.  Adrian prefers to say they're done but
> keep them alive in case need to fix.
>
> Issue on GMPLS reqs (TEWG reqs were MPLS only).
>
> Issue of bringing complex functions in.  Option might be to start work on partner draft
> for framework for more complex functions.
>
> Authors are asking if we need a WG framework, if this is the right WG framework and if
> this is the time to make it WG doc.
>
> Dimitri - if we combine TEWG reqs with GMPLS reqs does that mean we have separate reqs.
> Or do we just extend TEWG reqs. for GMPLS.  Or do we merge MPLS/GMPLS drafts?
>
> Adrian (speaking as an author) - think we need to understand if GMPLS reqs are
different.
> If they're not in existing reqs drafts and are not contradictory then don't care much
> where we do them (but 3rd draft might be good for GMPLS extns to requirements - allowing
> people to do MPLS alone).  PSC will probably be done with pointer to MPLS.
>
> Richard Rabbat - interdomain OAM you're saying have reqs for LSP ping or poss. GTTP.
> Would GTTP solve problems?  Want to see if we can increase importance of GTTP in WG.
>
> Adrian - people have commented that one issue with MPLS was that OAM was left until
later
> as a req.  We need to start to look at multi-area OAM reqs.  May take us down GTTP path.
> Not clear that because we have req that anyone will want to work on GTTP.
>
> Richard Rabbat - agree but may need to keep alive.
>
> John Sadler - thanks for draft, helps identify gap on ASON.  Additional req for ASON is
> identified.  Not sure where to capture as has ramifications to signalling.
>
> Adrian - expect over time to have overlap in ASON DT and this work.
>
> Q.(?) - discussion on converging inter-area and intra-area.  WG has decided not to.  I
> support sep draft for GMPLS.  Makes docs much more scalable/readable.  2nd q - you said
> that the diversity/reoptimisation isn't part of base spec.  But should include as is
> already being talked about in converged signalling draft.
>
> Lou - for each MPLS solutionn doc (JP's)?
>
> Arthi - read more carefully.  Not all reqs are solved.  But want a single solution doc
for
> MPLS and GMPLS.
>
> Anon - liason to ITU would be good.
>
> Kireeti - how many have read?  Good number. How many like it? good number.  Only vishal
> thinks is not ready?
>
> step 1 is take to mailing list but note consensus in room.
>
> will do for other docs once presented.
>
>
> Arthi inter-domain MPLS TE RSVP-TE extns
> ----------------------------------------
>
> As requested by WG at IETF59 split doc into 3.  This is one of the solution docs
> (signalling).  JP's draft does path computation.   Will have applicability doc ready for
> IETF61.
>
> Idea was to only look at signalling aspects for interdomain TE LSP setup.  Looks at
> contiguous, nested and stitched LSPs.
>
> Domain def. is aligned with framework (i.e. very flexible).
>
> Intention was GMPLS/MPLS applicability (packet and non-packet).  May be some gaps.
>
> Cover other aspects - ERO processing, FRR, re-optimisaton (just talks about signalling
> issues wrt re-optimisation).
>
> 3 signalling methods (contig, nested, stitched).  Needs two bits to ask for contiguous
LSP
> or stitched LSP.  Latter is set by head end LSR of segment (not e2e LSP).  Has a
> corresponding bit in RRO attributes.
>
> stitching:
>
> enables packet LSP to get right label exchange between egress and penultimate nodes.
>
> don't want to have label exchange over LSP segment hop.
>
> allows ingress to be notified that egress has done the right thing.
>
> similarity to hierarchy - uses non-adj signalling and all signalling extns.  Can use
> segment as FA-LSP (but is a special case as can only carry one LSP).
>
> differences are one-to-one nature.  Lack of label exchange over segment.  no b/w
> reservation on segment.  Either have b/w or you don't - so is exact match.
>
> Need to clarify similarity/diffs in doc.
>
> 1st question is how head end can control downstream choice of signalling method.  Some
> discussion on mailing list (incl CCAMP).  Discussed in context of inter-area reqs.  No
> conclusion on thread - are we OK with that?  If not OK then what do we do?
>
> 2nd question is GMPLS.  Need to clarify this better.  Do we need any more signalling for
> it?
>
> 3rd question is whether we need a stitching draft.  Doc talks about stitching but might
> need clearer applicability.  should that be in this doc or in a sep draft.
>
> Next steps:
>
> No major changes expected as basic issues finalised so would appreciate more feedback.
>
> Since ready (bar a few clarifications) want to know if chairs/WG think is ready for WG
> doc.
>
> Vishal - good to have some clarification of stitching in this doc.  Later we can see if
> need a diff doc.  Same for GMPLS - put more stuff in for now.
>
> Adrian - thanks Vishal, you've just made the same 2 comments the chairs wanted to make.
>
> Alia -  need more detail on stitching.  perhaps in a sep section.  For instance nowhere
> does it say how you correlate intra-domain LSP to inter-domain LSP.
>
> Adrian - will ask authors to tidy up GMPLS, break stitching out into sep section. Bring
> back for consideration as a WG doc.
>
>
> JP - path computation methods
> -----------------------------
>
> Proposes two methods for packet/non-packet LSPs.
>
> Aim is to fulfil both inter-area and inter-AS reqs from TEWG.
>
> overview of two scenarios:
>
> 1) per-domain path computation - do path on per-area basis.  Head end to first ABR, 1st
> ABR to next, last ABR to egress.  Could be areas, could be ASes.  Can discover next-hop
> dynamically, using heuristics, policy etc.  Or can specify loose hops at head end or
> abstract strict hops (list of ASes etc.)
>
> 2) End to end shortest path computation using PCE.  Head-end sends request to PCE.
> Recursively construct shortest path where tree is rooted at tail end.  Welcome to come
to
> PCE BOF.  Draft talks about how to signal from head end to PCE.
>
> Note that both scenarios can work together.  So can have policy to control set of ASes
but
> use PCE intra-AS (for example).
>
> Want to restate that we don't require flooring across domains.  No impact on
scalability.
>
> Have proposed optimisation to flood inter-AS TE info.  Reduces probability of call setup
> failure (increases as load increases and as you have more ASBRs) so can reduce call
setup
> time.  ALso reduces number of ERO expansions and gives more optimal path selection.
Note
> no IGP impact.
>
> Need to elaborate more on applicability - will do this in separate draft.
>
> Again want to point out that inter-AS and inter-area are very similar (only difference
is
> inter-ASBR link in the first case).
>
> Nothing too specific on FRR except for inter-ASBR link and ABR/ASBR failures.
>
> separate draft for re-optimisation of contiguous TE LSPs based on scenario 1.  Proposing
> soln for scenario 2.
>
> For stitched/nested this is a local reoptimisation intra-domain.
>
> Will discuss more tomorrow about how to signal from head end to PCE.  3 ideas already on
> IGP-TE capability (in CCAMP, ISIS, OSPF).
>
> SPs will come up with ID for next IETF on BCP for security/confidentiality.
>
> next steps:
>
> New ID on applicability.
>
> Progress signalling and path computation IDs (and make WG docs).
>
> Q (Vishal). Not so sure that need to standardise optimisation algorithm.  Specifically
as
> long as can exchange parms between ASBRs that should be enough.  Need to discuss more on
> Thursday.
>
> JP - will discuss more on Thursday. What we want to agree is method for sending
requests.
> On PCE itself can use CSPF and various optimisation criteria.  No need to standardise.
>
> G (Vishal) - does inter-area optimisation apply to 1 and 2?
>
> JP - if you don't flood TE info between ASBRs then only have visibility to boundary
node.
> So applies to both.
>
> Dimitri - there is a PCE BOF.  What is impact on PCE BOF on CCAMP?  If doesn't get
> progressed as BOF then should we still progress.  Can we progress this independently of
> PCE BOF outcome?
>
> Adrian - yes.
>
> Q (ECI Telecom) - regarding applicability statement, will there be recommendation on
impl.
> issues (e.g centralised/distributed PCE).  Or will this stay open?  Often standards say
> which of options is most endorsed.
>
> JP - like RR for BGP can be put on a router that also does forwarding, or not.  so we're
> just describing fn of PCE - depends on your network design as to where you put it.
>
> Kireeti - so are you asking if applicability spec will recommend centralised or
> distributed.  Ideally in applicability spec will just say "here are options, and here
are
> scenarios that work for each of them".  Won't have global recommendation.
>
> Richard - your ASCII figures are hard to follow.  Can you please clean them up or do
PDF?
>
> JP - we'll fix it.
>
> Adrian - need to suspend decision on moving this forward until after PCE BoF.
>
>
> Tomohiro Otani - TE parms to be exchanged
> -----------------------------------------
>
> Summary:
>
> fits charter item on signalling/routing mechanisms for paths spanning multiple
> areas/ASes/providers.
>
> clarifies need for dynamic/static info exchange and reqs. for TE parms.
>
> SP proposal.  KDDI and NTT already interconnect at L1, L2, L3.  Need to set up paths
while
> hiding internal topology.
>
> Assumption is 2 GMPLS ASes.  AS1 knows its topology and AS2's border
routers/reachability.
>
> Once create LSP from ingress to egress.  If AS 1 only knows AS 2 reachability then how
> does it get shortest path in AS 2.  AS 2 may send back path err if constraint can't be
> met.  So may need non-shortest path in AS1 to then get to border router which meets
> constraint in AS2.
>
> Of course have whole bunch of constraints (switching capability, encoding type,
bandwidth,
> SRLG etc.)
>
> GMPLS border nodes announce end-pt reachability with the constraints met to those
> end-points.
>
> To get resilient LSPs may need globally significant SRLGs.
>
> Next steps:
>
> 1) Add GMPLS EGP reqs.  (so need BGP experts).  And will look at extra load here
> (suggested by Adrian).  May need light mechanism for dynamic exchange of info between
> ASBRs.
>
> 2) Go for WG doc (need to do 1 first).
>
> 3) Will look at any BGP extentions
>
> 4) Will look at how to get SRLGs that are globally consistent (bit assignments).
>
> Adrian - is this really limited to GMPLS?  Or can it apply to MPLS TE?
>
> Tomohiro - limited to GMPLS, but could expand to MPLS.
>
> Adrian - bit of a contradition between reqs. here and in TEWG docs.  In as much as
> discussion here on distribution of TE info inter-domain we are going to have to resolve
> the contradiction.  Adrain thinks is good.  JP doesn't.
>
> Zafar - next steps slide.  would like to tie this to GMPLS reqs before doing solution.
>
> Tomohiro - yes would like to do GMPLS reqs first.
>
> Arthi - I think we need to start discussion about whether BGP would req this for MPLS as
> well as GMPLS.
>
> JP - It's not that I think this isn't good.  Am just trying to reflect what the TE reqs
> draft says.  Aim is not to leak summarised TE info inter-domain.
>
> JP - the draft seems to flood quite a lot of unsummarised info.  Big req of SPs is to
> preserve confidentiality.  How do we sort that out?
>
> Tomohiro - we don't want to flood all info to other ASes.  So we need summarisation in
> each AS.
>
> JP - do you think can both summarise to preserve confidentiality and have enough info to
> be useful?
>
> Kireeti - as I understand it this isn't summarisation.  It's more passing switching caps
> so don't attempt what isn't possible.  Is quite useful for L1VPN. Could be used from CE
to
> CE in L1VPN.  Answers first q on leaking constraints.  RTs etc. can be used in VPN.  So
> can be used inter-AS and in L1VPN.
>
> Susan Hares - thought I heard mention of ORFs.
>
> Kireeti - no, just RTs - for L1VPN.
>
> Susan - so we haven't settled on RTs, ORFs etc.?
>
> Arthi - can we say that this is basically an optimisation to per-domain path computation
> to reduce crankback?
>
> Kireeti - yes.
>
> JP - that's exactly back to my question.  To reduce crankback you have to summarise info
> from other AS, but then you break confidentiality and scalability.
>
> Adrian - so potential tradeoffs and we need to work on them.
>
> Anon - there could be networks that want to transfer all the data across ASes (e.g.
> research networks - where 2 ASes don't mind sharing info and security is achieved in
diff
> fashion).  Providing network summary isn't sufficient.  Need to provide more info to get
> optimal path across ASes.
>
> Adrian - come to PCE BoF and we'll debate this.
>
> Vishal - are we going to work on reqs. for GMPLS TE? Is anyone doing it?
>
> Kireeti - yes, but nobody is doing it yet.
>
>
> Dimitri - GMPLS for L2LSPs
> --------------------------
>
> Changes since last version:
>
> Explain motivation for L2SC LSPs (RFC3473)
>
> Generalised to any L2 (ATM/FR/ETh etc.)
>
> New L2 TSPEC FLOWSPEC etc.
>
> L2 label spaces and encoding all details are in the doc.
>
> General feeling that's worth spending cycles on this.
>
> Think it's a good basis for the work.
>
> How is consensus wrt WG doc?
>
> Kireeti - GMPLS charter covers this implicitly, but want to make it explicit and then
take
> this to WG doc.
>
>
> L1VPNs
> ------
>
> Progressing "under care of CCAMP".  Submitted applicability.  Idea is to show how we use
> GMPLS and deltas from "normal" GMPLS.
>
> Few issues in framework.
>
> In summary existing drafts cover most of applicability.  Identified 7 items that may
need
> more work.
>
> Next steps - covered some of this at start of meeting.  But need to discuss on L1VPN
list
> and CCAMP list. Want to make L1VPN part of CCAMP.  100 subs on L1VPN list and expecting
> protocol work to be minor.  Good links to ITU-T etc.  Want feedback.
>
> Hamid - good work has been done on L1VPN for applic/framework/auto-discovery/use of
GMPLS.
>
> Anon - want to observe that am looking forward to huge market for lambda services and
more
> and seems like a good idea to do in a different WG.  Can we do that without huge admin
> overhead.   More issues will come up once this gets publicised.
>
>
> Lou - segment recovery
> ----------------------
>
> biggest change from last meeting is that draft became WG.  Also bunch of minor fixes
(some
> coming from list discussions).
>
> 2 comments not integrated:
>
> 1) more words needed on RESV processing of notify request object.  Good text for path so
> need equivalent for RESV.
>
> 2) internal discussion on FRR interaction.  Need more words there.
>
> One other comment - know of 2 implementations; various stages of maturity.  Would love
to
> hear of others.
>
> Zafar - 2 things I'd like to see:
> 1) info on local recovery
> 2) applicability for FRR.  Pros vs technique described here.
>
> Lou - if you can enumerate reqs and contribute text that'd be great.  As for applic
> statements they are in sep docs, so perhaps we need companion draft.
>
> Richard - adrian sent email re misconnections being living list against which protection
> mechanisms are tested.  Have you checked against that?
>
> Lou - no.  Might be dimitri and others have.
>
> Dimitri - is ongoing.  In next release will have conclusion.
>
>
> Zafar - graceful shutdown in MPLS-TE networks
> ---------------------------------------------
>
> reqs - this is problem that NSPs try to solve today using ad-hoc mechanisms.  Problem is
> resources in nodes/TE links.  Want to upgrade node.  So how do we divert traffic to
other
> places in network so that we can do the maintenance.  Currently SPs play with IGP
metrics
> etc.  Problem is that can be inconsistent.  Also not applicable to inter-area or
inter-AS.
> This ID puts togeher framework for existing mechanisms to do graceful shutdown of TE
link
> or node.
>
> Draft is straightforward. Talks about IGP and RSVP-TE mechanisms.  Issue is IGP isn't
> applicable to inter-area or inter-AS.  RSVP-TE only sends info to nodes along path.
>
> changes are minor and rely on existing framework.
>
> RSVP-TE mechanism
>
> IGP based mechanism.
>
> Have had feedback and will publish next rev by end of aug.
>
> can we be WG doc?
>
> Arthi - not entirely fair that this is based on existing docs.  Loose hop reoptimisation
> not defined elsewhere.  Might be better to add here than to add elsewhere and then claim
> we are using other mechanisms.  Also there are existing mechanisms which are used today
> for graceful turn-off of links at least in GMPLS networks.
>
> Zafar - all fair comments.    Can take comments re other draft offline.
>
> Adrian - let's discuss offline once have a respin and take it from there.
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 20 Aug 2004 10:26:42 +0000
Message-ID: <0a2201c4869f$f80cffa0$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Lou Berger" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Reshad Rahman" <[e-mail]>, "'Anca Zamfir'" <[e-mail]>, <[e-mail]>
Subject: draft-aruns-ccamp-rsvp-restart-ext-01.txt to WG status
Date: Fri, 20 Aug 2004 10:30:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The consensus seems to be that this draft should be adopted by the WG.

Authors, please republish as draft-ietf-ccamp-rsvp-restart-ext-00.txt with no changes
(except, please make sure that you have the I-D boilerplate correct).

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 19 Aug 2004 17:53:39 +0000
Message-ID: <[e-mail]>
From: Jon Berger <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: IPv6 GMPLS Traffic Engineering in IS-IS
Date: Thu, 19 Aug 2004 18:51:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

CCAMP WG,

The following draft describes how IS-IS can carry TE information for an IPv6
network.  It includes GMPLS TE.

http://www.ietf.org/internet-drafts/draft-harrison-isis-ipv6-te-00.txt

In summary the draft
 - describes how routers exchange global IPv6 address information used to
identify links
 - adds new IPv6 TE Router ID and SRLG TLVs
 - describes how to exchange link identifying information.

If you have any comments on this draft, please make them on the IS-IS WG
mailing list:
	[e-mail]
(http://www.ietf.org/html.charters/isis-charter.html for subscription
instructions).

Jon

Jon Berger
Network Protocols Group
Data Connection Ltd
Tel:	  [phone]	
Fax:	  [phone]
Email:  mailto:[e-mail]
Web:    http://www.dataconnection.com






Envelope-to: [e-mail]
Delivery-date: Sat, 14 Aug 2004 09:35:44 +0000
Message-ID: <013401c481e1$b463f190$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: A message to draft editors
Date: Fri, 13 Aug 2004 21:50:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Before you submit drafts it would be really good if you could check them for nits.

I know this is frightful fag, but it makes them easier to review and read, so it is in
your interests. The nits will have to be removed in the long run anyway, so why not do it
now?

Have a look at the ID-nits page, http://ietf.org/ID-Checklist.html and consider running
the awk script at http://ietf.levkowetz.com/tools/idnits/

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 20:36:57 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Don Fedyk'" <[e-mail]>, <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Thu, 12 Aug 2004 13:35:33 -0700
Message-ID: <001f01c480ab$eaa102c0$403ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks. This sounds good. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Don Fedyk
> Sent: Wednesday, August 11, 2004 8:53 PM
> To: Richard Rabbat; [e-mail]
> Cc: 'Adrian Farrel'; [e-mail]; 'Kireeti Kompella'; 
> 'Tove Madsen'
> Subject: RE: Soliciting comments on moving drafts to WG status
> 
> 
> Hi Richard
> 
> Inline
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Richard Rabbat
> > Subject: RE: Soliciting comments on moving drafts to WG status
> > 
> > 
> > Hi Dimitri, inline...
> > 
> > > 
> > > hi richard, all, - see in-line
> > > 
> <snip> 
> > > >> 2. A Transport Network View of LMP
> > > > Not sure. Adrian mentioned that this would possibly
> > identify items
> > > > of work for ITU and IETF. What is the thinking of the
> > authors about
> > > > the draft after the protocol modifications are finished?
> > > >
> > > > If the expected outcome is an alignment of the IETF and ITU
> > > views on LMP, then the draft would have served its purpose
> > and would
> > > not
> > need
> > > publication as Informational.
> > > 
> > > your question is sensible, the reason is that in order to 
> exchange 
> > > views we need first to agree 1) that we want to work on 
> it then 2) 
> > > that we are in agreement about these views (you will also 
> find part 
> > > of the response to your in section 6.4) and finally 3) 
> that we are 
> > > in agreement on how to progress the work
> > > 
> > I support making it a WG draft, at least to be able to
> > initiate liaisons with SG15. 
> > I'm wondering though what the authors would like the final 
> > outcome to be. If all issues are resolved, then in my opinion 
> > this draft should be made to expire eventually. Otherwise, 
> > documenting the areas of divergence as Informational would be 
> > more than appropriate.
> 
> Generally I agree. The draft has evolved from being a 
> description of ITU discovery to a parrallel description of 
> LMP and ITU discovery terms. So the final outcome is 
> evolving. I have to discuss with other authors for next steps 
> and this is why I would defer your final view question.  
> 
> Regards,
> Don 
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 20:26:05 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Thu, 12 Aug 2004 13:24:47 -0700
Message-ID: <001b01c480aa$69e04e80$403ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri,
Some snipping, the rest inline.

> From: dimitri papadimitriou [mailto:[e-mail]] 
...
>
> hi richard, see in-line
> 
> >>>> 1. Loose Path Re-optimization
...
> > 
> > Agree on these points. Would the authors address these 
> issues in the 
> > next revision?
> 
> imho, these changes should be committed in the next revision and this 
> independently of its promotion as WG I-d
> 
Agree. Yes to the document.

> > And while you're at it, can you fix the double quotes throughout?
> 
> this has been recorded in the meeting minutes and hope it will be 
> addressed in the next revision
> 
Actually, the recorded minutes are about another Vasseur draft; I want to
make sure the authors are aware about problems in this as well.

> >>>> 2. A Transport Network View of LMP
> >>> 
> > I support making it a WG draft, at least to be able to initiate
> > liaisons with SG15. I'm wondering though what the authors would like
> > the final outcome to be.
> 
> as part of the outcome, if there are commonalities in terms 
> of discovery 
> functionality, then an interoperable/compatible LMP mechanism may be 
> considered within the scope of the process
> 
> > If all issues are resolved, then in my opinion this draft should be 
> > made to expire eventually. Otherwise, documenting the areas of 
> > divergence as Informational would be more than appropriate.
> 
> nice way to conclude the discussion point because if there are no 
> commonalities in terms of functionality and scope, we would 
> have (with 
> this i-d) closely documented why we didn't do so (but yes, i 
> agree with 
> you in both cases this document is meant promoted in the long 
> term for 
> the record)
> 
Great. From my p.o.v., I'd say let's move forward on this as well with the
clarifications you gave. 




Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 20:03:10 +0000
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 2004 22:02:22 +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.1) Gecko/20040707
MIME-Version: 1.0
To: Richard Rabbat <[e-mail]>
CC: [e-mail],  'Adrian Farrel' <[e-mail]>, [e-mail], 'Kireeti Kompella' <[e-mail]>,  'Tove Madsen' <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi richard, see in-line

>>>> 1. Loose Path Re-optimization 
>>>> draft-vasseur-ccamp-loose-path-reopt-02.txt This draft is 
>>>> stable and has an implementation. The work is predominantly 
>>>> pertinent to inter-domain signaling, but could also be used 
>>>> within a domain. The meeting in San Diego reported relatively 
>>>> few as having read the draft, but no objection to it becoming a
>>>> WG draft.
>>> 
>>> Yes. Though I would like the authors to mention GMPLS and drop 
>>> the focus on MPLS since they say in the abstract that this 
>>> applies to "packet and non-packet TE LSPs".
>> 
>> agree, i don't know if this has already being pointed out but the 
>> statement could even become somehow confusing to the audience, so 
>> it requires to explicitly state [RFC 3209] and [RFC 3473] for 
>> packet LSPs (as GMPLS support by definition PSC LSPs)
>> 
>> now concerning non-PSC LSPs, there is also a point to be addressed
>> that in order to achieve non-disruptive re-optimization using MBB
>> one would require double counting as a parallel non-PSC LSP would
>> be required (traffic is then send over both LSP before tearing the
>> old one)
> 
> Agree on these points. Would the authors address these issues in the
> next revision?

imho, these changes should be committed in the next revision and this 
independently of its promotion as WG I-d

> And while you're at it, can you fix the double quotes throughout?

this has been recorded in the meeting minutes and hope it will be 
addressed in the next revision

>>>> 2. A Transport Network View of LMP
>>> 
>>> Not sure. Adrian mentioned that this would possibly identify 
>>> items of work for ITU and IETF. What is the thinking of the 
>>> authors about the draft after the protocol modifications are 
>>> finished?
>>> 
>>> If the expected outcome is an alignment of the IETF and ITU views
>>> on LMP, then the draft would have served its purpose and would
>>> not need publication as Informational.
>> 
>> your question is sensible, the reason is that in order to exchange
>> views we need first to agree 1) that we want to work on it then 2)
>> that we are in agreement about these views (you will also find
>> part of the response to your in section 6.4) and finally 3) that we
>> are in agreement on how to progress the work
> 
> I support making it a WG draft, at least to be able to initiate 
> liaisons with SG15. I'm wondering though what the authors would like
> the final outcome to be.

as part of the outcome, if there are commonalities in terms of discovery 
functionality, then an interoperable/compatible LMP mechanism may be 
considered within the scope of the process

> If all issues are resolved, then in my opinion this draft should be
> made to expire eventually. Otherwise, documenting the areas of
> divergence as Informational would be more than appropriate.

nice way to conclude the discussion point because if there are no 
commonalities in terms of functionality and scope, we would have (with 
this i-d) closely documented why we didn't do so (but yes, i agree with 
you in both cases this document is meant promoted in the long term for 
the record)




Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 17:34:26 +0000
Message-ID: <000a01c48092$384e90b0$11849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Tove Madsen" <[e-mail]>
Subject: Craft minutes from San Diego
Date: Thu, 12 Aug 2004 18:31:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>From Tove.

Please send comments on list or direct to her.

Thanks,
Adrian

Hi ccamp,

Here are the minutes from our meeting in SD. Please review, feedback and
changes are appreciated until next Thursday, thanks!

 Special thanks to typers Deborah B, Susan H and Giles H!

/  Tove Madsen

--------------070301030408020006090705
Content-Type: text/plain;
 name="ccamp minutes rev02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ccamp minutes rev02.txt"

CCAMP
-----

Agenda bashing - Adrian
-----------------------

no new RFCs since Seoul.  Waiting for Aug 9th to push a bunch of stuff through.  G.709
with Alex (AD).  Will publish 15 RFCs once done.

Bunch of drafts not being covered today:

JP's router capability stuff.  Need some discussion on list.

JP's loose path reoptimisation.  Is this something we want?  interdomain but with
intradomain usage. <10 hands showing have read it.  Will go to list to check we're happy
before taking into WG.

Alarm info.  Said on list a while ago that considered it done and considering WG last
call.  anyone objecting to last call?  No.

Crankback and route exclusing waiting for multi-domain.  Both have implementations.

Tom and Adrian will sit down this week to work on MIBs.  Lack of interest so far. Anyone
MIB-interested willing to help?

Tunnel trace - no interest shown at all.

Link bundling - perhaps needs a clarification draft to show what was intended.

MPLS/GMPLS migration/interworking is something we ought to care about (will be networks
that need to talk and perhaps gradual migration).  Needs review and comment from WG.

Useful new draft on misconnection analysis.  Authors planning new rev so now's a good time
to comment on-list.

Survey for mesh restoration.  Fair bit of input, would be useful to get feedback from SPs
who'd be answering the survey and from implementors (who'll want to know what to
implement).  Feedback on list or to authors would be good.

Q (Vishal). Diverse path routing draft?

A (Kireeti).  Have a set of slides on inter-area strategy.

Milestones - Kireeti
--------------------

Going well but got the year wrong!

There will be one more revision of protection/restoration.

Minor edtis needed on ASON.

Will talk later on strategy for inter-whatever.

GTTP is stuck.  People who were driving have driven away.  Need to poll authors and WG to
see if there's any interest.  if not will take off the charter.

Minor edits for ASON routing reqs.

Need to talk about charter.  Adrian went over much of work that needs to be done.

Promised us again that MIBs will be done.  Can't progress standards work without MIBs.
Need to close off ASON stuff, multi-region and protection/restoration.  Various misc. docs
that are WG docs so we need to decide whether to complete or drop.

Need to realise how much work we have on our plate before we add more work.

Clarification required on label allocation for different switching types.  Also on how to
take the switching/encoding type into consideration when doing CSPF.  Might need to modify
old docs, do new ones, or do "clarifications" doc.

New work items
--------------

MPLS/GMPLS interworking/migration.  e.g. two ways to signal a PSC label (MPLS or GMPLS).
Need to work it out and have migration path.  Putting on charter will help.

Inter-domain signalling/routing. Already working on it.  Nice to have a work item
explicitly saying it.

Big one is L1VPN.  SG13 have said they're working on it.  Want the same relationship with
SG13 as we're trying to forge with SG15.  They do reqs, we do protocol work.  But who is
"we" - just someone in IETF.  One option is a new WG.  Other option is to do in CCAMP.  If
we do in CCAMP it will take the following (note two issues - is this a good summary of
work to be done, is this what we want to do in which case take to ADs who hopefully will
say no):

Once we get framework/applicability done then:

Do protocol work.  Will have to liase within IETF (e.g. with L3VPN WG as have VPN
discovery and CE-PE ID exchange docs).  Also with ITU-T.  Of course if we have routing
extensions then OSPF/ISIS will get involved.

If we go down this path then we need a design team.

So plan is :

1) take to list to see if have consensus in CCAMP for charter extension.

seemed enough hands to take to list.


ASON
----

Have 3 drafts.  2 gone through AD review.  Last one on Alex's "to read" list.  Just before
this meeting couple of people pointed out that there's a disconnect with key ITU spec.  So
DT needs to sit with these people and figure out what disconnect is and how significant it
is.  Will attempt to start discussion this week (face to face).


Dimitri - RSVP-TE for ASON
--------------------------

refreshed since last IETF.

2 discussion points:

Is the definition of link capability usable in wider scope?

Can we define the notify message usage in detail?

Doc has been shown to be stable.  Needs editorial review ASAP.

Aim was to be ready for last call post San Diego.


Dimitri - ASON Routing DT
-------------------------

Aim is to evaluate routing protocols against ASON routing requirements.

Need to elaborate the applicability scenarios.  DT looking at two scenarios. If anyone has
a good scenario that needs to be addressed they can pass it to the DT.

Result of evaluation will be integral part of draft.

First cut at Adrian's website.

ToC of reqs.

Needs scenarios and needs user community to feed scenarios in.

First CCAMP WG doc needed by end of this month so will have to push hard.

Will be liased with SG15/OIF to get inputs before doing protocol work.  Need to focus on
the evaluation work.

Q (Zafar).  One comment regarding template.  Would recommend not having reqs section as
already have a requirements doc.   If repeated it can become confusing.

Dimitri - want at least to have pointers to the requirements. That way people have in mind
the scope of the architecture.  Structure of doc may change.


Don Fedyk - Transport review of LMP.
-----------------------------------

Aim is to facilitate ITU/IETF communication.  Issue with discovery is involves databases
used to control optical networks.

LMP discovery is there to find a TE link.

Documents ITU discovery terminology.

Idea here is to document "secret decoder ring".

changes:

1) Clarified G.7714

2) TE link definition.

3) General clarification.

Think is useful for IETF people to understand where ITU-T discovery procedures are and
vice-versa.  Hence requesting is WG doc.

Q (Vishal) - any attempt to work on discovery procedures or does this just clarify
definitions?

A (Don) - just informational.  Stories on either side aren't complete yet.  So will live
until those are solidified. Not aiming to define here.

Q. (Vishal) - Think it is a good doc.  Is there any work to unify the procedures or do
procedures here to mirror ITU work?

A. (Kireeti) - first thing is identifying the secret decoder ring.  Show diffs between ITU
and IETF.  Second is to start series of liasons to SG15 (or whatever) to figure out if we
fix it, they fix it, or work together. So get better picture of how to proceed. But right
now need to understand each other.

Adrain - have heard comment about it being good and useful from many people recently.
fits in charter.  would like to see it as a WG doc.  show of hands!

handful of hands. (Adrian thinks reasonable).  Nobody saying should not be WG doc.  Take
to list.


Wesam Alanqar - ITU-T SG 15
---------------------------

Various links to liason info.

Picture of optical control plane (ITU-T SG-15 Q14/Q15)

ITU-T wants to thank CCAMP - especially ASON reqs DT for capturing reqs for link-state
routing.  Q14 wants to extend this.  Analysing OSPF/IS-IS/PNNI for use in ASON.
Encouraging work with different standards bodies to look at implications for routing
protocols.  Have template for this.

Q14 thinks a cross-body DT may be useful to look at use of IETF routing protocols.
Similar to the ASON routing reqs. DT.  Various things to look at.

Recent docs finished in ITU-T:

G.7715.1 on Link state reqs for ASON
G.7713 call connection mgmt.

Meeting Nov 1-5 in Berlin.  IETF welcome to come.  Contact Kam Lan for more info by 24/9.
Contributions by 25/10.

Q. (Zafar).  Last IETF had discussions on OIF also.
Do chairs want to comment?

Kireeti - what do you want to talk about?

Q. (Zafar) What's the feel of liason with OIF?  Is it progressing?

Kireeti - No formal liason relationship with OIF.  Been communicating.  OIF has asked for
formal liason.  Figuring out what needs to be done on each side.  Most interesting is to
synchronise routing work.  ITU relationship is good - ITU does reqs, IETF does protocol
work and liase back.  Would like to do same with OIF either formally or not.  Form of
relationship still to be figured out - but again want OIF to give us reqs, we do protocol,
they say if is good.  avoids redoing work.

Q. (Monique) - OIF meeting last week.  Trend towards OIF/ITU alignment as well as
OIF/IETF.  will be contribuition to that effect.

Adrian - we'll try to nail down the lacuna in comprehension for requirements after
meeting.


Protection drafts - Adrian
--------------------------

3 drafts.  Been through WG last call and marked up.  With chairs (Kireeti) to check
markups are fine before pushing forward.


Dimitri - RSVP-TE extns for e2e GMPLS-based recovery
----------------------------------------------------

v01 submitted in may.

have addressed issues raised on list:

1) mis-ordering during secondary LSP full instantiation (8.3)
2) preempt resource of lower pri LSPs when protecting LSP activated (10).

Updates since v00 addressing concerns/expectation.

Need to check sec 13 (external commands).

Check Implementations status out there, external commands still open.

Once that issue closed then we can go to last call.

Also had editorial review already.

Adrian - so not quite ready for last call?

Dimitri - we should see whether impl. of section 13 is also there then respin with or
without that section.

Q (Zafar) - Later on will work on inter-as recovery.  would be good if this doc addresses
intra-region.  is that (or will it be) stated in the doc?

Kireeti - base spec doesn't say so won't start now keep separate.

Q (Zafar) - Issue on reoptimisation of bidirectional LSP.

Adrian - not sure this draft is relevant to that.  Worth having discussion, but distinct
from this.


Lou Berger - Extensions to GMPLS RSVP graceful restart
------------------------------------------------------

Arun's draft.  Lou's reordered a couple of slides.

Merged draft (following consensus from Seoul). (draft-aruns and draft-rahman).

Major change is addition of support for improved scalability.  In Aruns original draft
every piece of state had to be sent.  Now can use summary refresh to decide which pieces
to resignal.  Way this is done is that node adj. to restarting node can send back path
message from restarting node so restarting node can recover the state it originally
advertised.  Big step forward from (RFC)3473.  In 3473 no way for ingress to recover
state.  As compared to prev. version only sends state that is needed. Use summary refresh
for this.  Have added recovery path summary refresh so restarting node can just look at
stuff it hasn't kept across restart.  If adj nodes support this extn (can discover that)
then can use these procedures.

To do:

1) Need to agree message type

2) discussion amongst authors about adj node startarts.  If two adj nodes restart then how
does 2nd one know the 1st is in restart condition.  Impacts sending of path msg and
recovery labels.  This is a broader problem than just this draft.  Applies to 3473
independent of these extns.  So issue is both what to do and where to do it.

Next steps:

Authors think ready for WG doc.  Chairs?

Kireeti - how many people have read this.  Scattering.

How many thinks it should be WG doc - most of them

How many opposed - zero.

some support - take to list.

Kireeti - one comment on adj node restart.  Most other protocols don't care about this.
Idea is that if lots of nodes restart at once then your network is screwed anyhow.  With
OSPF nodes abandon restart if that occurs.  BGP, OSPF, IS-IS and prob LDP do this.

Lou - not all that difficult to do. One prob is where put recovery stuff in path msg.
Other issue is timer adjustments if you see your neighbour restarting.  Could argue is in
3473 already - may just need clarification. But good comment.

Adrian - chairs in violent disagreement over Kireeti's last comment.  Highlight is that
restart is complex as well as important.  There are people out there who do a lot with it.


Zafar Ali - Node ID based RSVP Hello
------------------------------------

Incorporated feedback from mailing list and Seoul discussions.

Remaining work is minimal.

Draft is short/straightforward.

>=5 implementations.

Some inter-op testing done.

want to do WG last call.

Adrian - who's has not read the draft who is responsible for MPLS/GMPLS impl.  Lou.

Adrian - have met all criteria to go forward.  Authors happy, draft stable, comments dried
up.  So will debate last call on list.


Kireeti - Multi zone
--------------------

2 drafts for this.  Issue is what is a zone - IGP area, AS, tech domain, protect domain.

Also want to have one way to do this - esp as both drafts were RSVP-TE based.

Single common doc now.  Many iterations/rewrites.  Now one mechanism with diff options.

have functional docs:

1) Framework (not on slide)
2) signalling
3) path computation
4) (not a doc) BOF on PCE to look at other ways of doing this (run by Adrian and JP).

Need more docs:

1) Applicability - what options to use for a given req.
2) Stitching.  Similar but different to nested LSP.  Does it become a separate doc.
Certainly need doc on it.

Debate on protection/restoration and diverse routing inter-domain.  Aim is to get base
spec out.  Once stable work on diverse path setup across domains.

Vishal - have had discussion on list.  Basic req in reqs doc is diverse path routing.
Could do solution for single path routing that might not work at all for diverse paths.
Suggestion is to break up items and push diverse path routing etc. into "advanced
applications". Needs to be taken into consideration for signalling/routing.  Need to look
at problem together and not separate.

Kireeti - what we've done (successful so far).  Did base spec for signalling and had
separate DT to do protection/restoration.  Base spec for routing, and added on stuff
afterwards.  If you can give us a concrete example of where this won't work then we'll
look at it.

Vishal - not just me.  SPs want to link it together.

Kireeti - fine.  That's one opinion.

Vishal - not resolved yet.

JP - this has been taken into consideration.  scenarios 1 and 2 for path computation
consider this, so already part of base spec.  Not true to say it has been excluded.

Vishal - but not being discussed.  Draft says it is advanced application.  This shouldn't
be.

JP - not being excluded.

Kireeti - not taking off the agenda.  Will do it but want to get base spec out.  Want to
leave room in spec for other applications (not just diverse path routing). But doesn't
mean we have to spec that out now.  If JP's done the work to ensure it's possible then
Kireeti's happy.

Vishal - I raised Qs on list which weren't answered.  Especially regarding scalability. Is
not even clear how single path works.

Arthi - what do you mean by "let's get base spec out"?  Currently docs aren't even WG
docs.  I think Vishal is saying at least we need to move forward to some extent with base
docs.  They're just individual contributions right now.

Kireeti - that's what I'm saying.  Not vishal

Adrian - nobody's saying we'll take unprotected to RFC before we even look at protected
stuff.  We're rather saying we want to understand unprotected before we understand
protected since latter is built on former.

Vishal - issue is diverse paths.  Doesn't work if you build on single path approaches.
Diverse paths is a key issue - so consider at the beginning, don't retrofit.

JP - that was the case.

Zafar - to answer Vishal there are enough cases to show that base stuff works and is
extendible for future.  Crankback is an example.  Lots of stuff needs to be done later,
and need stake in ground for base work with enough hooks.  Nothing is excluded today.

Dimitri - can we make it clear that as docs are extended they take G of GMPLS into
account.

Lou - question re stitching?

Kireeti - details have to be done.  That's not a question.  Question is is this new draft
or existing drafts.

Vishal - are we going to poll the WG?

Kireeti - can I finish my slides first?

Kireeti again:

how to progress:

Have an idea of what docs we need.

Reqs came from TEWG.

In light of proposed solutions should revisit the TEWG reqs. and check reqs are
reasonable.

Sep docs for sep. functions (signalling/path computation/poss. rechability).

Progres each doc separately - but may send for RFC as a block.

Once have base spec done will look at re-optimisation and diverse paths.  Want to do base
spec first.  If in our evaluation that isn't a major retrofit then will progress base spec
while working on rest in parallel.  If turns out is a major retrofit then will halt
progress and retrofit first.

Vishal - my point still stands.

Kireeti - we've heard it several times.

Vishal - so what are you going to do?

Kireeti - nothing.

Vishal - but WG hasn't been polled.

Adrian - WG chairs exist to judge consensus.  We believe we have judged it and the right
way to do this technically.  You're welcome to disagree and build an opinion against it.

Vishal - want to get work done not build opinions.

Adrian - so do we.

Vishal - so what will we do about diverse paths?

Adrian - keep draft alive as a private draft.  Then have basis when WG ready to take on.
That's good.

Kireeti - you might be missing that the difference in what you're saying and what we're
saying is just sequencing.  We want to do a then b. you want to do in parallel.  If we
find that base doc needs major retrofit then we'll halt it.
We need to have a tech reason for doing this, and don't have a base doc yet.

Vishal - so can keep individual docs going?

Kireeti - yes, renew it every 5 months and 29 days.


Adrian (with chair hat removed)
-------------------------------

Had couple of proposals for inter-region/inter-AS TE a while back.

Ended up with a useful, but long, draft.

Have split into diff parts.  JP and Arthi will talk about soln. specific texts.

This draft is just framework to point to what you could do.

Key is defn of a domain:

seems necessary to extend this beyond just IGP areas and ASes to protection domains and
zones of limited TE visibility.  So domain is a loose concept.

Aim is not to recommend solution but to break problem down to show different ways of
signalling, path computation and routing.

Describes some "easy" advanced features and applicable to MPLS/GMPLS.

Not attempting to look at harder issues (e.g. diversity, OAM, P2MP).

Not making judgements as to why you'd pick one method rather than another (or documenting
those methods/solns).

TEWG produced two reqs docs. had quite a bashing and rework.  Question is whether we're
happy to freeze the docs as RFCs or keep alive as do solution work in case we find
ambiguities/contradictions and need to fix them.  Adrian prefers to say they're done but
keep them alive in case need to fix.

Issue on GMPLS reqs (TEWG reqs were MPLS only).

Issue of bringing complex functions in.  Option might be to start work on partner draft
for framework for more complex functions.

Authors are asking if we need a WG framework, if this is the right WG framework and if
this is the time to make it WG doc.

Dimitri - if we combine TEWG reqs with GMPLS reqs does that mean we have separate reqs.
Or do we just extend TEWG reqs. for GMPLS.  Or do we merge MPLS/GMPLS drafts?

Adrian (speaking as an author) - think we need to understand if GMPLS reqs are different.
If they're not in existing reqs drafts and are not contradictory then don't care much
where we do them (but 3rd draft might be good for GMPLS extns to requirements - allowing
people to do MPLS alone).  PSC will probably be done with pointer to MPLS.

Richard Rabbat - interdomain OAM you're saying have reqs for LSP ping or poss. GTTP.
Would GTTP solve problems?  Want to see if we can increase importance of GTTP in WG.

Adrian - people have commented that one issue with MPLS was that OAM was left until later
as a req.  We need to start to look at multi-area OAM reqs.  May take us down GTTP path.
Not clear that because we have req that anyone will want to work on GTTP.

Richard Rabbat - agree but may need to keep alive.

John Sadler - thanks for draft, helps identify gap on ASON.  Additional req for ASON is
identified.  Not sure where to capture as has ramifications to signalling.

Adrian - expect over time to have overlap in ASON DT and this work.

Q.(?) - discussion on converging inter-area and intra-area.  WG has decided not to.  I
support sep draft for GMPLS.  Makes docs much more scalable/readable.  2nd q - you said
that the diversity/reoptimisation isn't part of base spec.  But should include as is
already being talked about in converged signalling draft.

Lou - for each MPLS solutionn doc (JP's)?

Arthi - read more carefully.  Not all reqs are solved.  But want a single solution doc for
MPLS and GMPLS.

Anon - liason to ITU would be good.

Kireeti - how many have read?  Good number. How many like it? good number.  Only vishal
thinks is not ready?

step 1 is take to mailing list but note consensus in room.

will do for other docs once presented.


Arthi inter-domain MPLS TE RSVP-TE extns
----------------------------------------

As requested by WG at IETF59 split doc into 3.  This is one of the solution docs
(signalling).  JP's draft does path computation.   Will have applicability doc ready for
IETF61.

Idea was to only look at signalling aspects for interdomain TE LSP setup.  Looks at
contiguous, nested and stitched LSPs.

Domain def. is aligned with framework (i.e. very flexible).

Intention was GMPLS/MPLS applicability (packet and non-packet).  May be some gaps.

Cover other aspects - ERO processing, FRR, re-optimisaton (just talks about signalling
issues wrt re-optimisation).

3 signalling methods (contig, nested, stitched).  Needs two bits to ask for contiguous LSP
or stitched LSP.  Latter is set by head end LSR of segment (not e2e LSP).  Has a
corresponding bit in RRO attributes.

stitching:

enables packet LSP to get right label exchange between egress and penultimate nodes.

don't want to have label exchange over LSP segment hop.

allows ingress to be notified that egress has done the right thing.

similarity to hierarchy - uses non-adj signalling and all signalling extns.  Can use
segment as FA-LSP (but is a special case as can only carry one LSP).

differences are one-to-one nature.  Lack of label exchange over segment.  no b/w
reservation on segment.  Either have b/w or you don't - so is exact match.

Need to clarify similarity/diffs in doc.

1st question is how head end can control downstream choice of signalling method.  Some
discussion on mailing list (incl CCAMP).  Discussed in context of inter-area reqs.  No
conclusion on thread - are we OK with that?  If not OK then what do we do?

2nd question is GMPLS.  Need to clarify this better.  Do we need any more signalling for
it?

3rd question is whether we need a stitching draft.  Doc talks about stitching but might
need clearer applicability.  should that be in this doc or in a sep draft.

Next steps:

No major changes expected as basic issues finalised so would appreciate more feedback.

Since ready (bar a few clarifications) want to know if chairs/WG think is ready for WG
doc.

Vishal - good to have some clarification of stitching in this doc.  Later we can see if
need a diff doc.  Same for GMPLS - put more stuff in for now.

Adrian - thanks Vishal, you've just made the same 2 comments the chairs wanted to make.

Alia -  need more detail on stitching.  perhaps in a sep section.  For instance nowhere
does it say how you correlate intra-domain LSP to inter-domain LSP.

Adrian - will ask authors to tidy up GMPLS, break stitching out into sep section. Bring
back for consideration as a WG doc.


JP - path computation methods
-----------------------------

Proposes two methods for packet/non-packet LSPs.

Aim is to fulfil both inter-area and inter-AS reqs from TEWG.

overview of two scenarios:

1) per-domain path computation - do path on per-area basis.  Head end to first ABR, 1st
ABR to next, last ABR to egress.  Could be areas, could be ASes.  Can discover next-hop
dynamically, using heuristics, policy etc.  Or can specify loose hops at head end or
abstract strict hops (list of ASes etc.)

2) End to end shortest path computation using PCE.  Head-end sends request to PCE.
Recursively construct shortest path where tree is rooted at tail end.  Welcome to come to
PCE BOF.  Draft talks about how to signal from head end to PCE.

Note that both scenarios can work together.  So can have policy to control set of ASes but
use PCE intra-AS (for example).

Want to restate that we don't require flooring across domains.  No impact on scalability.

Have proposed optimisation to flood inter-AS TE info.  Reduces probability of call setup
failure (increases as load increases and as you have more ASBRs) so can reduce call setup
time.  ALso reduces number of ERO expansions and gives more optimal path selection.  Note
no IGP impact.

Need to elaborate more on applicability - will do this in separate draft.

Again want to point out that inter-AS and inter-area are very similar (only difference is
inter-ASBR link in the first case).

Nothing too specific on FRR except for inter-ASBR link and ABR/ASBR failures.

separate draft for re-optimisation of contiguous TE LSPs based on scenario 1.  Proposing
soln for scenario 2.

For stitched/nested this is a local reoptimisation intra-domain.

Will discuss more tomorrow about how to signal from head end to PCE.  3 ideas already on
IGP-TE capability (in CCAMP, ISIS, OSPF).

SPs will come up with ID for next IETF on BCP for security/confidentiality.

next steps:

New ID on applicability.

Progress signalling and path computation IDs (and make WG docs).

Q (Vishal). Not so sure that need to standardise optimisation algorithm.  Specifically as
long as can exchange parms between ASBRs that should be enough.  Need to discuss more on
Thursday.

JP - will discuss more on Thursday. What we want to agree is method for sending requests.
On PCE itself can use CSPF and various optimisation criteria.  No need to standardise.

G (Vishal) - does inter-area optimisation apply to 1 and 2?

JP - if you don't flood TE info between ASBRs then only have visibility to boundary node.
So applies to both.

Dimitri - there is a PCE BOF.  What is impact on PCE BOF on CCAMP?  If doesn't get
progressed as BOF then should we still progress.  Can we progress this independently of
PCE BOF outcome?

Adrian - yes.

Q (ECI Telecom) - regarding applicability statement, will there be recommendation on impl.
issues (e.g centralised/distributed PCE).  Or will this stay open?  Often standards say
which of options is most endorsed.

JP - like RR for BGP can be put on a router that also does forwarding, or not.  so we're
just describing fn of PCE - depends on your network design as to where you put it.

Kireeti - so are you asking if applicability spec will recommend centralised or
distributed.  Ideally in applicability spec will just say "here are options, and here are
scenarios that work for each of them".  Won't have global recommendation.

Richard - your ASCII figures are hard to follow.  Can you please clean them up or do PDF?

JP - we'll fix it.

Adrian - need to suspend decision on moving this forward until after PCE BoF.


Tomohiro Otani - TE parms to be exchanged
-----------------------------------------

Summary:

fits charter item on signalling/routing mechanisms for paths spanning multiple
areas/ASes/providers.

clarifies need for dynamic/static info exchange and reqs. for TE parms.

SP proposal.  KDDI and NTT already interconnect at L1, L2, L3.  Need to set up paths while
hiding internal topology.

Assumption is 2 GMPLS ASes.  AS1 knows its topology and AS2's border routers/reachability.

Once create LSP from ingress to egress.  If AS 1 only knows AS 2 reachability then how
does it get shortest path in AS 2.  AS 2 may send back path err if constraint can't be
met.  So may need non-shortest path in AS1 to then get to border router which meets
constraint in AS2.

Of course have whole bunch of constraints (switching capability, encoding type, bandwidth,
SRLG etc.)

GMPLS border nodes announce end-pt reachability with the constraints met to those
end-points.

To get resilient LSPs may need globally significant SRLGs.

Next steps:

1) Add GMPLS EGP reqs.  (so need BGP experts).  And will look at extra load here
(suggested by Adrian).  May need light mechanism for dynamic exchange of info between
ASBRs.

2) Go for WG doc (need to do 1 first).

3) Will look at any BGP extentions

4) Will look at how to get SRLGs that are globally consistent (bit assignments).

Adrian - is this really limited to GMPLS?  Or can it apply to MPLS TE?

Tomohiro - limited to GMPLS, but could expand to MPLS.

Adrian - bit of a contradition between reqs. here and in TEWG docs.  In as much as
discussion here on distribution of TE info inter-domain we are going to have to resolve
the contradiction.  Adrain thinks is good.  JP doesn't.

Zafar - next steps slide.  would like to tie this to GMPLS reqs before doing solution.

Tomohiro - yes would like to do GMPLS reqs first.

Arthi - I think we need to start discussion about whether BGP would req this for MPLS as
well as GMPLS.

JP - It's not that I think this isn't good.  Am just trying to reflect what the TE reqs
draft says.  Aim is not to leak summarised TE info inter-domain.

JP - the draft seems to flood quite a lot of unsummarised info.  Big req of SPs is to
preserve confidentiality.  How do we sort that out?

Tomohiro - we don't want to flood all info to other ASes.  So we need summarisation in
each AS.

JP - do you think can both summarise to preserve confidentiality and have enough info to
be useful?

Kireeti - as I understand it this isn't summarisation.  It's more passing switching caps
so don't attempt what isn't possible.  Is quite useful for L1VPN. Could be used from CE to
CE in L1VPN.  Answers first q on leaking constraints.  RTs etc. can be used in VPN.  So
can be used inter-AS and in L1VPN.

Susan Hares - thought I heard mention of ORFs.

Kireeti - no, just RTs - for L1VPN.

Susan - so we haven't settled on RTs, ORFs etc.?

Arthi - can we say that this is basically an optimisation to per-domain path computation
to reduce crankback?

Kireeti - yes.

JP - that's exactly back to my question.  To reduce crankback you have to summarise info
from other AS, but then you break confidentiality and scalability.

Adrian - so potential tradeoffs and we need to work on them.

Anon - there could be networks that want to transfer all the data across ASes (e.g.
research networks - where 2 ASes don't mind sharing info and security is achieved in diff
fashion).  Providing network summary isn't sufficient.  Need to provide more info to get
optimal path across ASes.

Adrian - come to PCE BoF and we'll debate this.

Vishal - are we going to work on reqs. for GMPLS TE? Is anyone doing it?

Kireeti - yes, but nobody is doing it yet.


Dimitri - GMPLS for L2LSPs
--------------------------

Changes since last version:

Explain motivation for L2SC LSPs (RFC3473)

Generalised to any L2 (ATM/FR/ETh etc.)

New L2 TSPEC FLOWSPEC etc.

L2 label spaces and encoding all details are in the doc.

General feeling that's worth spending cycles on this.

Think it's a good basis for the work.

How is consensus wrt WG doc?

Kireeti - GMPLS charter covers this implicitly, but want to make it explicit and then take
this to WG doc.


L1VPNs
------

Progressing "under care of CCAMP".  Submitted applicability.  Idea is to show how we use
GMPLS and deltas from "normal" GMPLS.

Few issues in framework.

In summary existing drafts cover most of applicability.  Identified 7 items that may need
more work.

Next steps - covered some of this at start of meeting.  But need to discuss on L1VPN list
and CCAMP list. Want to make L1VPN part of CCAMP.  100 subs on L1VPN list and expecting
protocol work to be minor.  Good links to ITU-T etc.  Want feedback.

Hamid - good work has been done on L1VPN for applic/framework/auto-discovery/use of GMPLS.

Anon - want to observe that am looking forward to huge market for lambda services and more
and seems like a good idea to do in a different WG.  Can we do that without huge admin
overhead.   More issues will come up once this gets publicised.


Lou - segment recovery
----------------------

biggest change from last meeting is that draft became WG.  Also bunch of minor fixes (some
coming from list discussions).

2 comments not integrated:

1) more words needed on RESV processing of notify request object.  Good text for path so
need equivalent for RESV.

2) internal discussion on FRR interaction.  Need more words there.

One other comment - know of 2 implementations; various stages of maturity.  Would love to
hear of others.

Zafar - 2 things I'd like to see:
1) info on local recovery
2) applicability for FRR.  Pros vs technique described here.

Lou - if you can enumerate reqs and contribute text that'd be great.  As for applic
statements they are in sep docs, so perhaps we need companion draft.

Richard - adrian sent email re misconnections being living list against which protection
mechanisms are tested.  Have you checked against that?

Lou - no.  Might be dimitri and others have.

Dimitri - is ongoing.  In next release will have conclusion.


Zafar - graceful shutdown in MPLS-TE networks
---------------------------------------------

reqs - this is problem that NSPs try to solve today using ad-hoc mechanisms.  Problem is
resources in nodes/TE links.  Want to upgrade node.  So how do we divert traffic to other
places in network so that we can do the maintenance.  Currently SPs play with IGP metrics
etc.  Problem is that can be inconsistent.  Also not applicable to inter-area or inter-AS.
This ID puts togeher framework for existing mechanisms to do graceful shutdown of TE link
or node.

Draft is straightforward. Talks about IGP and RSVP-TE mechanisms.  Issue is IGP isn't
applicable to inter-area or inter-AS.  RSVP-TE only sends info to nodes along path.

changes are minor and rely on existing framework.

RSVP-TE mechanism

IGP based mechanism.

Have had feedback and will publish next rev by end of aug.

can we be WG doc?

Arthi - not entirely fair that this is based on existing docs.  Loose hop reoptimisation
not defined elsewhere.  Might be better to add here than to add elsewhere and then claim
we are using other mechanisms.  Also there are existing mechanisms which are used today
for graceful turn-off of links at least in GMPLS networks.

Zafar - all fair comments.    Can take comments re other draft offline.

Adrian - let's discuss offline once have a respin and take it from there.




Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 03:54:15 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: Richard Rabbat <[e-mail]>, [e-mail]
Cc: "'Adrian Farrel'" <[e-mail]>, [e-mail], "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 23:52:54 -0400

Hi Richard

Inline

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Richard Rabbat
> Subject: RE: Soliciting comments on moving drafts to WG status
> 
> 
> Hi Dimitri, inline...
> 
> > 
> > hi richard, all, - see in-line
> > 
<snip> 
> > >> 2. A Transport Network View of LMP
> > > Not sure. Adrian mentioned that this would possibly 
> identify items 
> > > of work for ITU and IETF. What is the thinking of the 
> authors about 
> > > the draft after the protocol modifications are finished?
> > >
> > > If the expected outcome is an alignment of the IETF and ITU
> > views on LMP, then the draft would have served its purpose 
> and would 
> > not
> need
> > publication as Informational.
> > 
> > your question is sensible, the reason is that in order to
> > exchange views we need first to agree 1) that we want to work 
> > on it then 2) that we are in agreement about these views (you 
> > will also find part of the response to your in section 6.4) 
> > and finally 3) that we are in agreement on how to progress the work
> > 
> I support making it a WG draft, at least to be able to 
> initiate liaisons with SG15. 
> I'm wondering though what the authors would like the final 
> outcome to be. If all issues are resolved, then in my opinion 
> this draft should be made to expire eventually. Otherwise, 
> documenting the areas of divergence as Informational would be 
> more than appropriate.

Generally I agree. The draft has evolved from being a description of ITU
discovery to a parrallel description of LMP and ITU discovery terms. So the
final outcome is evolving. I have to discuss with other authors for next
steps and this is why I would defer your final view question.  

Regards,
Don 



Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 03:04:01 +0000
Message-Id: <[e-mail]>
Date: Wed, 11 Aug 2004 20:04:04 -0700
To: "Richard Rabbat" <[e-mail]>, [e-mail]
From: Jean Philippe Vasseur <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Cc: <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

At 12:28 PM 8/11/2004 -0700, Richard Rabbat wrote:
>Hi Dimitri, inline...
>
> >
> > hi richard, all, - see in-line
> >
> > >> 1. Loose Path Re-optimization
> > >> draft-vasseur-ccamp-loose-path-reopt-02.txt
> > >> This draft is stable and has an implementation.
> > >> The work is predominantly pertinent to inter-domain signaling, but
> > >> could also be used within a domain. The meeting in San
> > Diego reported
> > >> relatively few as having read the draft, but no objection to it
> > >> becoming a WG draft.
> > >
> > > Yes. Though I would like the authors to mention GMPLS and drop the
> > > focus
> > on
> > > MPLS since they say in the abstract that this applies to
> > "packet and
> > > non-packet TE LSPs".

Sure, we will.

> >
> > agree, i don't know if this has already being pointed out but
> > the statement could even become somehow confusing to the
> > audience, so it requires to explicitly state [RFC 3209] and
> > [RFC 3473] for packet LSPs (as GMPLS support by definition PSC LSPs)
> >

agree

> > now concerning non-PSC LSPs, there is also a point to be
> > addressed that in order to achieve non-disruptive
> > re-optimization using MBB one would require double counting
> > as a parallel non-PSC LSP would be required (traffic is then
> > send over both LSP before tearing the old one)
> >
>Agree on these points. Would the authors address these issues in the next
>revision? And while you're at it, can you fix the double quotes throughout?

ok, will do, thanks for the comments.

Cheers.

JP.

> > >> 2. A Transport Network View of LMP
> > > Not sure. Adrian mentioned that this would possibly identify items of
> > > work for ITU and IETF. What is the thinking of the authors about
> > > the draft after the protocol modifications are finished?
> > >
> > > If the expected outcome is an alignment of the IETF and ITU
> > views on LMP, then the draft would have served its purpose and would not
>need
> > publication as Informational.
> >
> > your question is sensible, the reason is that in order to
> > exchange views we need first to agree 1) that we want to work
> > on it then 2) that we are in agreement about these views (you
> > will also find part of the response to your in section 6.4)
> > and finally 3) that we are in agreement on how to progress the work
> >
>I support making it a WG draft, at least to be able to initiate liaisons
>with SG15.
>I'm wondering though what the authors would like the final outcome to be. If
>all issues are resolved, then in my opinion this draft should be made to
>expire eventually. Otherwise, documenting the areas of divergence as
>Informational would be more than appropriate.




Envelope-to: [e-mail]
Delivery-date: Thu, 12 Aug 2004 02:50:44 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: Adrian Farrel <[e-mail]>, [e-mail]
Cc: "'Kireeti Kompella'" <[e-mail]>, Tove Madsen <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 22:45:49 -0400

Hi Adrian

1.Yes
2.Yes (I'm an author)
3.Yes
4.Yes

Regards,
Don 

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Tuesday, August 10, 2004 8:52 AM
> To: [e-mail]
> Cc: 'Kireeti Kompella'; Tove Madsen
> Subject: Soliciting comments on moving drafts to WG status
> 
> 
> Hi,
> 
> In San Diego we had four drafts for immediate consideration 
> as working group drafts. (There were a few other drafts that 
> needed a little attention first, but will come up for 
> consideration in the near future.)
> 
> Please send your comments to the list or to the chairs. A 
> brief "yes" or "no" will suffice, but a reason with any "no" 
> would be helpful.
> 
> Thanks,
> Adrian
> 
> 
> 1. Loose Path Re-optimization 
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain 
> signaling, but could also be used within a domain. The 
> meeting in San Diego reported relatively few as having read 
> the draft, but no objection to it becoming a WG draft.
> 
> 2. A Transport Network View of LMP 
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft 
> in which it has become clear that there are definite 
> differences between the ASON and CCAMP uses and views of LMP. 
> This is precisely what the draft is intended to expose. That 
> is, the draft is not intended to unify the views of LMP, but 
> rather to represent the two views within a single document so 
> as to highlight the differences. In San Diego, no-one raised 
> objections to this being a WG draft.
> 
> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was 
> created at the specific request of the WG in Seoul. There is 
> some more editorial work to be done on the draft, but the 
> main technical content appears to be stable. In San Diego 
> there was some support and no opposition to this becoming a WG draft.
> 
> 4. Inter-domain Framework 
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to 
> Kireeti ** This draft provides a framework for the 
> multi-domain solutions work that the WG is chartered to 
> address. In San Diego there were some questions about whether 
> the draft should be extended to cover other, more complex, 
> inter-domain functions. There was no conclusion about whether 
> this should be done before or after becoming a WG draft (if 
> it should be done at all).
> 
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 22:29:10 +0000
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 15:27:03 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
To: Adrian Farrel <[e-mail]>, [e-mail]
Cc: 'Kireeti Kompella' <[e-mail]>, Tove Madsen <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Yes to the LMP draft. Hopefully this can lead to a
"common view".
The others sound reasonable and probably less
controversial.

Greg B.
--- Adrian Farrel <[e-mail]> wrote:

> Hi,
> 
> In San Diego we had four drafts for immediate
> consideration as working group drafts.
> (There were a few other drafts that needed a little
> attention first, but will come up for
> consideration in the near future.)
> 
> Please send your comments to the list or to the
> chairs. A brief "yes" or "no" will
> suffice, but a reason with any "no" would be
> helpful.
> 
> Thanks,
> Adrian
> 
> 
> 1. Loose Path Re-optimization
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain
> signaling, but could also be used
> within a domain.
> The meeting in San Diego reported relatively few as
> having read the draft, but no
> objection to it becoming a WG draft.
> 
> 2. A Transport Network View of LMP
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about
> this draft in which it has become clear
> that there are definite differences between the ASON
> and CCAMP uses and views of LMP. This
> is precisely what the draft is intended to expose.
> That is, the draft is not intended to
> unify the views of LMP, but rather to represent the
> two views within a single document so
> as to highlight the differences.
> In San Diego, no-one raised objections to this being
> a WG draft.
> 
> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous
> drafts and was created at the specific
> request of the WG in Seoul.
> There is some more editorial work to be done on the
> draft, but the main technical content
> appears to be stable.
> In San Diego there was some support and no
> opposition to this becoming a WG draft.
> 
> 4. Inter-domain Framework
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues
> with this to Kireeti **
> This draft provides a framework for the multi-domain
> solutions work that the WG is
> chartered to address.
> In San Diego there were some questions about whether
> the draft should be extended to cover
> other, more complex, inter-domain functions. There
> was no conclusion about whether this
> should be done before or after becoming a WG draft
> (if it should be done at all).
> 
> 
> 
> 
> 
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 19:29:27 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 12:28:26 -0700
Message-ID: <003b01c47fd9$5fbc1910$3b3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dimitri, inline...

>=20
> hi richard, all, - see in-line
>=20
> >> 1. Loose Path Re-optimization=20
> >> draft-vasseur-ccamp-loose-path-reopt-02.txt
> >> This draft is stable and has an implementation.
> >> The work is predominantly pertinent to inter-domain signaling, but=20
> >> could also be used within a domain. The meeting in San=20
> Diego reported=20
> >> relatively few as having read the draft, but no objection to it=20
> >> becoming a WG draft.
> >
> > Yes. Though I would like the authors to mention GMPLS and drop the=20
> > focus
> on
> > MPLS since they say in the abstract that this applies to=20
> "packet and=20
> > non-packet TE LSPs".
>=20
> agree, i don't know if this has already being pointed out but=20
> the statement could even become somehow confusing to the=20
> audience, so it requires to explicitly state [RFC 3209] and=20
> [RFC 3473] for packet LSPs (as GMPLS support by definition PSC LSPs)
>=20
> now concerning non-PSC LSPs, there is also a point to be=20
> addressed that in order to achieve non-disruptive=20
> re-optimization using MBB one would require double counting=20
> as a parallel non-PSC LSP would be required (traffic is then=20
> send over both LSP before tearing the old one)
>=20
Agree on these points. Would the authors address these issues in the =
next
revision? And while you're at it, can you fix the double quotes =
throughout?

> >> 2. A Transport Network View of LMP=20
> > Not sure. Adrian mentioned that this would possibly identify items =
of
> > work for ITU and IETF. What is the thinking of the authors about=20
> > the draft after the protocol modifications are finished?
> >
> > If the expected outcome is an alignment of the IETF and ITU=20
> views on LMP, then the draft would have served its purpose and would =
not
need
> publication as Informational.
>=20
> your question is sensible, the reason is that in order to=20
> exchange views we need first to agree 1) that we want to work=20
> on it then 2) that we are in agreement about these views (you=20
> will also find part of the response to your in section 6.4)=20
> and finally 3) that we are in agreement on how to progress the work
>=20
I support making it a WG draft, at least to be able to initiate liaisons
with SG15.=20
I'm wondering though what the authors would like the final outcome to =
be. If
all issues are resolved, then in my opinion this draft should be made to
expire eventually. Otherwise, documenting the areas of divergence as
Informational would be more than appropriate.




Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 18:55:03 +0000
To: "Richard Rabbat" <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
From: [e-mail]
Subject: RE: Soliciting comments on moving drafts to WG status
MIME-Version: 1.0
Date: Wed, 11 Aug 2004 20:54:08 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

hi richard, all, - see in-line

>> 1. Loose Path Re-optimization
>> draft-vasseur-ccamp-loose-path-reopt-02.txt
>> This draft is stable and has an implementation.
>> The work is predominantly pertinent to inter-domain
>> signaling, but could also be used within a domain. The
>> meeting in San Diego reported relatively few as having read
>> the draft, but no objection to it becoming a WG draft.
>
> Yes. Though I would like the authors to mention GMPLS and drop the focus
on
> MPLS since they say in the abstract that this applies to "packet and
> non-packet TE LSPs".

agree, i don't know if this has already being pointed out but the statement
could even become somehow confusing to the audience, so it requires to
explicitly state [RFC 3209] and [RFC 3473] for packet LSPs (as GMPLS
support by definition PSC LSPs)

now concerning non-PSC LSPs, there is also a point to be addressed that in
order to achieve non-disruptive re-optimization using MBB one would require
double counting as a parallel non-PSC LSP would be required (traffic is
then send over both LSP before tearing the old one)

>> 2. A Transport Network View of LMP
>> draft-aboulmagd-ccamp-transport-lmp-02.txt
>> There has been a bit of off-list discussion about this draft
>> in which it has become clear that there are definite
>> differences between the ASON and CCAMP uses and views of LMP.
>> This is precisely what the draft is intended to expose. That
>> is, the draft is not intended to unify the views of LMP, but
>> rather to represent the two views within a single document so
>> as to highlight the differences. In San Diego, no-one raised
>> objections to this being a WG draft.
>
> Not sure. Adrian mentioned that this would possibly identify items of
work
> for ITU and IETF. What is the thinking of the authors about the draft
after
> the protocol modifications are finished?
>
> If the expected outcome is an alignment of the IETF and ITU views on LMP,
> then the draft would have served its purpose and would not need
publication > as Informational.

your question is sensible, the reason is that in order to exchange views we
need first to agree 1) that we want to work on it then 2) that we are in
agreement about these views (you will also find part of the response to
your in section 6.4) and finally 3) that we are in agreement on how to
progress the work

[snip]








Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 18:39:02 +0000
Message-ID: <039a01c47fd2$56433000$2e849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Dimitri Papadimitriou" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: Re-opt [Was: Re: Soliciting comments on moving drafts to WG status]
Date: Wed, 11 Aug 2004 18:52:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

> > 1. Loose Path Re-optimization
> > draft-vasseur-ccamp-loose-path-reopt-02.txt
> > This draft is stable and has an implementation.
> > The work is predominantly pertinent to inter-domain signaling, but could also be used
> > within a domain.
> > The meeting in San Diego reported relatively few as having read the draft, but no
> > objection to it becoming a WG draft.
> 
> is it part of the consensus to use this as a common document for further 
> work related to "re-optimization" (incl. the delivery of ubiquitous 
> signaling solution decoupled from the routing topology) in this case i'd 
> be fine

This was my interpretation of the purpose of this draft.

I would be happy to hear objections to this view point.

Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 18:22:52 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: Adrian Farrel <[e-mail]>, [e-mail]
Cc: 'Kireeti Kompella' <[e-mail]>, Tove Madsen <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 11:22:05 -0700
MIME-Version: 1.0
Content-Type: text/plain

Yes to all

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, August 10, 2004 5:52 AM
> To: [e-mail]
> Cc: 'Kireeti Kompella'; Tove Madsen
> Subject: Soliciting comments on moving drafts to WG status
> 
> Hi,
> 
> In San Diego we had four drafts for immediate consideration as working
> group drafts.
> (There were a few other drafts that needed a little attention first, but
> will come up for
> consideration in the near future.)
> 
> Please send your comments to the list or to the chairs. A brief "yes" or
> "no" will
> suffice, but a reason with any "no" would be helpful.
> 
> Thanks,
> Adrian
> 
> 
> 1. Loose Path Re-optimization
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain signaling, but could
> also be used
> within a domain.
> The meeting in San Diego reported relatively few as having read the draft,
> but no
> objection to it becoming a WG draft.
> 
> 2. A Transport Network View of LMP
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft in which it
> has become clear
> that there are definite differences between the ASON and CCAMP uses and
> views of LMP. This
> is precisely what the draft is intended to expose. That is, the draft is
> not intended to
> unify the views of LMP, but rather to represent the two views within a
> single document so
> as to highlight the differences.
> In San Diego, no-one raised objections to this being a WG draft.
> 
> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was created at
> the specific
> request of the WG in Seoul.
> There is some more editorial work to be done on the draft, but the main
> technical content
> appears to be stable.
> In San Diego there was some support and no opposition to this becoming a
> WG draft.
> 
> 4. Inter-domain Framework
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to Kireeti **
> This draft provides a framework for the multi-domain solutions work that
> the WG is
> chartered to address.
> In San Diego there were some questions about whether the draft should be
> extended to cover
> other, more complex, inter-domain functions. There was no conclusion about
> whether this
> should be done before or after becoming a WG draft (if it should be done
> at all).
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 18:20:57 +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: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 13:19:56 -0500
Message-ID: <[e-mail]>
Thread-Topic: Soliciting comments on moving drafts to WG status
Thread-Index: AcR+7YYpuGKvNAgLRJSQETJBlj9bKgA4jZmQ
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Tove Madsen" <[e-mail]>

Yes to all-
Deborah=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Tuesday, August 10, 2004 8:52 AM
To: [e-mail]
Cc: 'Kireeti Kompella'; Tove Madsen
Subject: Soliciting comments on moving drafts to WG status

Hi,

In San Diego we had four drafts for immediate consideration as working
group drafts.
(There were a few other drafts that needed a little attention first, but
will come up for
consideration in the near future.)

Please send your comments to the list or to the chairs. A brief "yes" or
"no" will
suffice, but a reason with any "no" would be helpful.

Thanks,
Adrian


1. Loose Path Re-optimization
draft-vasseur-ccamp-loose-path-reopt-02.txt
This draft is stable and has an implementation.
The work is predominantly pertinent to inter-domain signaling, but could
also be used
within a domain.
The meeting in San Diego reported relatively few as having read the
draft, but no
objection to it becoming a WG draft.

2. A Transport Network View of LMP
draft-aboulmagd-ccamp-transport-lmp-02.txt
There has been a bit of off-list discussion about this draft in which it
has become clear
that there are definite differences between the ASON and CCAMP uses and
views of LMP. This
is precisely what the draft is intended to expose. That is, the draft is
not intended to
unify the views of LMP, but rather to represent the two views within a
single document so
as to highlight the differences.
In San Diego, no-one raised objections to this being a WG draft.

3. Graceful restart
draft-aruns-ccamp-rsvp-restart-ext-01.txt
This draft represents a merger of two previous drafts and was created at
the specific
request of the WG in Seoul.
There is some more editorial work to be done on the draft, but the main
technical content
appears to be stable.
In San Diego there was some support and no opposition to this becoming a
WG draft.

4. Inter-domain Framework
draft-farrel-ccamp-inter-domain-framework-01.txt
** I am principal editor. Please take any issues with this to Kireeti **
This draft provides a framework for the multi-domain solutions work that
the WG is
chartered to address.
In San Diego there were some questions about whether the draft should be
extended to cover
other, more complex, inter-domain functions. There was no conclusion
about whether this
should be done before or after becoming a WG draft (if it should be done
at all).









Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 17:30:58 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 10:28:14 -0700
Message-ID: <002401c47fc8$95f47830$3b3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please see inline.


> 1. Loose Path Re-optimization=20
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain=20
> signaling, but could also be used within a domain. The=20
> meeting in San Diego reported relatively few as having read=20
> the draft, but no objection to it becoming a WG draft.
=20
Yes. Though I would like the authors to mention GMPLS and drop the focus =
on
MPLS since they say in the abstract that this applies to "packet and
non-packet TE LSPs".

> 2. A Transport Network View of LMP=20
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft=20
> in which it has become clear that there are definite=20
> differences between the ASON and CCAMP uses and views of LMP.=20
> This is precisely what the draft is intended to expose. That=20
> is, the draft is not intended to unify the views of LMP, but=20
> rather to represent the two views within a single document so=20
> as to highlight the differences. In San Diego, no-one raised=20
> objections to this being a WG draft.

Not sure. Adrian mentioned that this would possibly identify items of =
work
for ITU and IETF. What is the thinking of the authors about the draft =
after
the protocol modifications are finished? If the expected outcome is an
alignment of the IETF and ITU views on LMP, then the draft would have =
served
its purpose and would not need publication as Informational.=20

> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was=20
> created at the specific request of the WG in Seoul. There is=20
> some more editorial work to be done on the draft, but the=20
> main technical content appears to be stable. In San Diego=20
> there was some support and no opposition to this becoming a WG draft.

Yes.

> 4. Inter-domain Framework=20
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to=20
> Kireeti ** This draft provides a framework for the=20
> multi-domain solutions work that the WG is chartered to=20
> address. In San Diego there were some questions about whether=20
> the draft should be extended to cover other, more complex,=20
> inter-domain functions. There was no conclusion about whether=20
> this should be done before or after becoming a WG draft (if=20
> it should be done at all).

Yes.




Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 07:40:15 +0000
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 09:36:37 +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.1) Gecko/20040707
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], 'Kireeti Kompella' <[e-mail]>,  Tove Madsen <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian et al.

> 1. Loose Path Re-optimization
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain signaling, but could also be used
> within a domain.
> The meeting in San Diego reported relatively few as having read the draft, but no
> objection to it becoming a WG draft.

is it part of the consensus to use this as a common document for further 
work related to "re-optimization" (incl. the delivery of ubiquitous 
signaling solution decoupled from the routing topology) in this case i'd 
be fine

> 2. A Transport Network View of LMP
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft in which it has become clear
> that there are definite differences between the ASON and CCAMP uses and views of LMP. This
> is precisely what the draft is intended to expose. That is, the draft is not intended to
> unify the views of LMP, but rather to represent the two views within a single document so
> as to highlight the differences.
> In San Diego, no-one raised objections to this being a WG draft.

yes (but i'm an author)

> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was created at the specific
> request of the WG in Seoul.
> There is some more editorial work to be done on the draft, but the main technical content
> appears to be stable.
> In San Diego there was some support and no opposition to this becoming a WG draft.

yes (but i'm an author)

> 4. Inter-domain Framework
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to Kireeti **
> This draft provides a framework for the multi-domain solutions work that the WG is
> chartered to address.
> In San Diego there were some questions about whether the draft should be extended to cover
> other, more complex, inter-domain functions. There was no conclusion about whether this
> should be done before or after becoming a WG draft (if it should be done at all).

yes -

a side question: why this document is entitled "inter-domain" whereas it 
"provides a framework for establishing and controlling Multiprotocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths 
(LSPs) for multi-domain networks" so clearly the scope is *multi-domain* 
there is imho some difference between "inter-domain" that relates to the 
signaling exchange between domain boundaries only while "multi" relates 
to signaling exchange from the source until the destination across 
several domains



Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 04:41:56 +0000
Message-Id: <[e-mail]>
Date: Tue, 10 Aug 2004 21:28:02 -0700
To: "Adrian Farrel" <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Adrian,

Yes to all.

JP.

At 01:52 PM 8/10/2004 +0100, Adrian Farrel wrote:
>Hi,
>
>In San Diego we had four drafts for immediate consideration as working 
>group drafts.
>(There were a few other drafts that needed a little attention first, but 
>will come up for
>consideration in the near future.)
>
>Please send your comments to the list or to the chairs. A brief "yes" or 
>"no" will
>suffice, but a reason with any "no" would be helpful.
>
>Thanks,
>Adrian
>
>
>1. Loose Path Re-optimization
>draft-vasseur-ccamp-loose-path-reopt-02.txt
>This draft is stable and has an implementation.
>The work is predominantly pertinent to inter-domain signaling, but could 
>also be used
>within a domain.
>The meeting in San Diego reported relatively few as having read the draft, 
>but no
>objection to it becoming a WG draft.
>
>2. A Transport Network View of LMP
>draft-aboulmagd-ccamp-transport-lmp-02.txt
>There has been a bit of off-list discussion about this draft in which it 
>has become clear
>that there are definite differences between the ASON and CCAMP uses and 
>views of LMP. This
>is precisely what the draft is intended to expose. That is, the draft is 
>not intended to
>unify the views of LMP, but rather to represent the two views within a 
>single document so
>as to highlight the differences.
>In San Diego, no-one raised objections to this being a WG draft.
>
>3. Graceful restart
>draft-aruns-ccamp-rsvp-restart-ext-01.txt
>This draft represents a merger of two previous drafts and was created at 
>the specific
>request of the WG in Seoul.
>There is some more editorial work to be done on the draft, but the main 
>technical content
>appears to be stable.
>In San Diego there was some support and no opposition to this becoming a 
>WG draft.
>
>4. Inter-domain Framework
>draft-farrel-ccamp-inter-domain-framework-01.txt
>** I am principal editor. Please take any issues with this to Kireeti **
>This draft provides a framework for the multi-domain solutions work that 
>the WG is
>chartered to address.
>In San Diego there were some questions about whether the draft should be 
>extended to cover
>other, more complex, inter-domain functions. There was no conclusion about 
>whether this
>should be done before or after becoming a WG draft (if it should be done 
>at all).




Envelope-to: [e-mail]
Delivery-date: Wed, 11 Aug 2004 02:16:10 +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: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 21:14:14 -0500
Message-ID: <[e-mail]>
Thread-Topic: Soliciting comments on moving drafts to WG status
Thread-Index: AcR+7YeMO1oinhOEQMSsJZAeMd2T6gAWwKCQ
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

> A brief "yes" or "no" will suffice

Yes to all.

Jerry





Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 17:47:39 +0000
From: "zafar ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: LMP transport [Was: Re: Soliciting comments on moving drafts to WG status]
Date: Tue, 10 Aug 2004 13:47:45 -0400
Organization: Cisco Systems
Message-ID: <002601c47f02$25399790$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>Sent: Tuesday, August 10, 2004 1:13 PM
>To: zafar ali; [e-mail]
>Subject: LMP transport [Was: Re: Soliciting comments on moving 
>drafts to WG status]
>
>
>> Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt, 
>> depending on the answer to the following:
>>
>> Does Author plan to address link management solution space between 
>> ASON and GMPLS in the same document? I would prefer that and 
>in which 
>> case I think adaptation of this document as a WG document to be 
>> deferred to a later point.
>
>Hi Zafar,
>
>I'm not quite clear what you mean by "address link management 
>solution space". Do you mean a comparison of the ways that LMP 
>is used and any extensions that may have been made to the 
>protocol? Or do you mean an analysis of what needs to be 
>"fixed" and the appropriate new extensions to the protocol?
>

Both, in that order. But as I mentioned I am ok on however Authors would
like to position this ID. 

>If the latter, I think a question that led in this direction 
>was asked in SD.
>
>Kireeti's response was to the effect that we have to do the 
>analysis first, identifying the "secret decoder ring", and 
>showing the differences between the ITU and IETF views. Then 
>we would start a series of liaisons to SG15 to figure out what 
>needs to be fixed and by whom. Finally, work could begin on 
>protocol modifications.
>
>This document is targeted at the first step only.
>
>OTOH, if you meant the first option (i.e. a comparison of how 
>the protocol is used and what extensions have already been 
>made), that seems to me to be valuable in this document.
>
>What do the authors say?
>
>Cheers,
>Adrian
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 17:30:36 +0000
Message-ID: <020601c47eff$73f78ca0$2e849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "zafar ali" <[e-mail]>, <[e-mail]>
Subject: LMP transport [Was: Re: Soliciting comments on moving drafts to WG status]
Date: Tue, 10 Aug 2004 18:13:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt, depending
> on the answer to the following:
>
> Does Author plan to address link management solution space between ASON and
> GMPLS in the same document? I would prefer that and in which case I think
> adaptation of this document as a WG document to be deferred to a later
> point.

Hi Zafar,

I'm not quite clear what you mean by "address link management solution space". Do you mean
a comparison of the ways that LMP is used and any extensions that may have been made to
the protocol? Or do you mean an analysis of what needs to be "fixed" and the appropriate
new extensions to the protocol?

If the latter, I think a question that led in this direction was asked in SD.

Kireeti's response was to the effect that we have to do the analysis first, identifying
the "secret decoder ring", and showing the differences between the ITU and IETF views.
Then we would start a series of liaisons to SG15 to figure out what needs to be fixed and
by whom. Finally, work could begin on protocol modifications.

This document is targeted at the first step only.

OTOH, if you meant the first option (i.e. a comparison of how the protocol is used and
what extensions have already been made), that seems to me to be valuable in this document.

What do the authors say?

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 17:23:57 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: [e-mail], [e-mail], zafar ali <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, [e-mail], "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 13:21:07 -0400

Zafar

I concur with Dimitri's comments, this document informational only

Regards,
Don 

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[e-mail]] 
> Sent: Tuesday, August 10, 2004 1:05 PM
> To: zafar ali
> Cc: 'Adrian Farrel'; [e-mail]; 'Kireeti Kompella'; 
> 'Tove Madsen'
> Subject: Re: Soliciting comments on moving drafts to WG status
> 
> 
> zafar,
> 
> the point has been already asked during the meeting, to 
> summarize, the 
> basic idea:
> 
> - is to have a "decoder ring" for understanding ITU work and IETF work
>    (-> for publication as informational RFC only)
> 
> - is NOT to define anything in this document as the intention is first
>    to understand the two groups work efforts and then do a series of
>    liaisons to determine/assess if any additional work is needed
> 
> hope this clarifies,
> 
> thanks,
> - dimitri.
> 
> ---
> zafar ali wrote:
> 
> > "yes" to (1), (3) and (4),
> > 
> > Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt, 
> > depending on the answer to the following:
> > 
> > Does Author plan to address link management solution space between 
> > ASON and GMPLS in the same document? I would prefer that 
> and in which 
> > case I think adaptation of this document as a WG document 
> to be deferred to a later
> > point.   
> > 
> > Thanks
> > 
> > Regards... Zafar
> > 
<snip>



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 17:17:34 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 13:17:31 -0400
Organization: Cisco Systems
Message-ID: <001701c47efd$ec93a060$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dimitri,=20

Thanks for the clarification; I remembered the discussion but was not =
100%
sure of the final take.=20

Given this, as I mentioned earlier, I am "in favor" of this document to =
be a
WG ID.=20

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail]=20
>[mailto:[e-mail]] On Behalf Of dimitri papadimitriou
>Sent: Tuesday, August 10, 2004 1:05 PM
>To: zafar ali
>Cc: 'Adrian Farrel'; [e-mail]; 'Kireeti Kompella';=20
>'Tove Madsen'
>Subject: Re: Soliciting comments on moving drafts to WG status
>
>
>zafar,
>
>the point has been already asked during the meeting, to summarize, the=20
>basic idea:
>
>- is to have a "decoder ring" for understanding ITU work and IETF work
>   (-> for publication as informational RFC only)
>
>- is NOT to define anything in this document as the intention is first
>   to understand the two groups work efforts and then do a series of
>   liaisons to determine/assess if any additional work is needed
>
>hope this clarifies,
>
>thanks,
>- dimitri.
>
>---
>zafar ali wrote:
>
>> "yes" to (1), (3) and (4),
>>=20
>> Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt,=20
>> depending on the answer to the following:
>>=20
>> Does Author plan to address link management solution space between=20
>> ASON and GMPLS in the same document? I would prefer that and=20
>in which=20
>> case I think adaptation of this document as a WG document to=20
>be deferred to a later
>> point.  =20
>>=20
>> Thanks
>>=20
>> Regards... Zafar
>>=20
>>=20
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>>>Sent: Tuesday, August 10, 2004 8:52 AM
>>>To: [e-mail]
>>>Cc: 'Kireeti Kompella'; Tove Madsen
>>>Subject: Soliciting comments on moving drafts to WG status
>>>
>>>
>>>Hi,
>>>
>>>In San Diego we had four drafts for immediate consideration as
>>>working group drafts. (There were a few other drafts that=20
>>>needed a little attention first, but will come up for=20
>>>consideration in the near future.)
>>>
>>>Please send your comments to the list or to the chairs. A
>>>brief "yes" or "no" will suffice, but a reason with any "no"=20
>>>would be helpful.
>>>
>>>Thanks,
>>>Adrian
>>>
>>>
>>>1. Loose Path Re-optimization
>>>draft-vasseur-ccamp-loose-path-reopt-02.txt
>>>This draft is stable and has an implementation.
>>>The work is predominantly pertinent to inter-domain signaling,=20
>>>but could also be used within a domain. The meeting in San=20
>>>Diego reported relatively few as having read the draft, but no=20
>>>objection to it becoming a WG draft.
>>>
>>>2. A Transport Network View of LMP
>>>draft-aboulmagd-ccamp-transport-lmp-02.txt
>>>There has been a bit of off-list discussion about this draft=20
>>>in which it has become clear that there are definite=20
>>>differences between the ASON and CCAMP uses and views of LMP.=20
>>>This is precisely what the draft is intended to expose. That=20
>>>is, the draft is not intended to unify the views of LMP, but=20
>>>rather to represent the two views within a single document so=20
>>>as to highlight the differences. In San Diego, no-one raised=20
>>>objections to this being a WG draft.
>>>
>>>3. Graceful restart
>>>draft-aruns-ccamp-rsvp-restart-ext-01.txt
>>>This draft represents a merger of two previous drafts and was
>>>created at the specific request of the WG in Seoul. There is=20
>>>some more editorial work to be done on the draft, but the main=20
>>>technical content appears to be stable. In San Diego there was=20
>>>some support and no opposition to this becoming a WG draft.
>>>
>>>4. Inter-domain Framework
>>>draft-farrel-ccamp-inter-domain-framework-01.txt
>>>** I am principal editor. Please take any issues with this to=20
>>>Kireeti ** This draft provides a framework for the=20
>>>multi-domain solutions work that the WG is chartered to=20
>>>address. In San Diego there were some questions about whether=20
>>>the draft should be extended to cover other, more complex,=20
>>>inter-domain functions. There was no conclusion about whether=20
>>>this should be done before or after becoming a WG draft (if it=20
>>>should be done at all).
>>>
>>>
>>>
>>>
>>>
>>=20
>>=20
>>=20
>>=20
>> .
>>=20
>




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 17:07:28 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 2004 19:05: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.1) Gecko/20040707
MIME-Version: 1.0
To: zafar ali <[e-mail]>
CC: 'Adrian Farrel' <[e-mail]>,  [e-mail],  'Kireeti Kompella' <[e-mail]>, 'Tove Madsen' <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

zafar,

the point has been already asked during the meeting, to summarize, the 
basic idea:

- is to have a "decoder ring" for understanding ITU work and IETF work
   (-> for publication as informational RFC only)

- is NOT to define anything in this document as the intention is first
   to understand the two groups work efforts and then do a series of
   liaisons to determine/assess if any additional work is needed

hope this clarifies,

thanks,
- dimitri.

---
zafar ali wrote:

> "yes" to (1), (3) and (4), 
> 
> Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt, depending
> on the answer to the following: 
> 
> Does Author plan to address link management solution space between ASON and
> GMPLS in the same document? I would prefer that and in which case I think
> adaptation of this document as a WG document to be deferred to a later
> point.   
> 
> Thanks
> 
> Regards... Zafar
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>>Sent: Tuesday, August 10, 2004 8:52 AM
>>To: [e-mail]
>>Cc: 'Kireeti Kompella'; Tove Madsen
>>Subject: Soliciting comments on moving drafts to WG status
>>
>>
>>Hi,
>>
>>In San Diego we had four drafts for immediate consideration as 
>>working group drafts. (There were a few other drafts that 
>>needed a little attention first, but will come up for 
>>consideration in the near future.)
>>
>>Please send your comments to the list or to the chairs. A 
>>brief "yes" or "no" will suffice, but a reason with any "no" 
>>would be helpful.
>>
>>Thanks,
>>Adrian
>>
>>
>>1. Loose Path Re-optimization 
>>draft-vasseur-ccamp-loose-path-reopt-02.txt
>>This draft is stable and has an implementation.
>>The work is predominantly pertinent to inter-domain signaling, 
>>but could also be used within a domain. The meeting in San 
>>Diego reported relatively few as having read the draft, but no 
>>objection to it becoming a WG draft.
>>
>>2. A Transport Network View of LMP 
>>draft-aboulmagd-ccamp-transport-lmp-02.txt
>>There has been a bit of off-list discussion about this draft 
>>in which it has become clear that there are definite 
>>differences between the ASON and CCAMP uses and views of LMP. 
>>This is precisely what the draft is intended to expose. That 
>>is, the draft is not intended to unify the views of LMP, but 
>>rather to represent the two views within a single document so 
>>as to highlight the differences. In San Diego, no-one raised 
>>objections to this being a WG draft.
>>
>>3. Graceful restart
>>draft-aruns-ccamp-rsvp-restart-ext-01.txt
>>This draft represents a merger of two previous drafts and was 
>>created at the specific request of the WG in Seoul. There is 
>>some more editorial work to be done on the draft, but the main 
>>technical content appears to be stable. In San Diego there was 
>>some support and no opposition to this becoming a WG draft.
>>
>>4. Inter-domain Framework 
>>draft-farrel-ccamp-inter-domain-framework-01.txt
>>** I am principal editor. Please take any issues with this to 
>>Kireeti ** This draft provides a framework for the 
>>multi-domain solutions work that the WG is chartered to 
>>address. In San Diego there were some questions about whether 
>>the draft should be extended to cover other, more complex, 
>>inter-domain functions. There was no conclusion about whether 
>>this should be done before or after becoming a WG draft (if it 
>>should be done at all).
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 15:44:06 +0000
From: "zafar ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "'Tove Madsen'" <[e-mail]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 11:44:13 -0400
Organization: Cisco Systems
Message-ID: <000601c47ef0$e478f680$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

"yes" to (1), (3) and (4), 

Conditional "yes" to draft-aboulmagd-ccamp-transport-lmp-02.txt, depending
on the answer to the following: 

Does Author plan to address link management solution space between ASON and
GMPLS in the same document? I would prefer that and in which case I think
adaptation of this document as a WG document to be deferred to a later
point.   

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>Sent: Tuesday, August 10, 2004 8:52 AM
>To: [e-mail]
>Cc: 'Kireeti Kompella'; Tove Madsen
>Subject: Soliciting comments on moving drafts to WG status
>
>
>Hi,
>
>In San Diego we had four drafts for immediate consideration as 
>working group drafts. (There were a few other drafts that 
>needed a little attention first, but will come up for 
>consideration in the near future.)
>
>Please send your comments to the list or to the chairs. A 
>brief "yes" or "no" will suffice, but a reason with any "no" 
>would be helpful.
>
>Thanks,
>Adrian
>
>
>1. Loose Path Re-optimization 
>draft-vasseur-ccamp-loose-path-reopt-02.txt
>This draft is stable and has an implementation.
>The work is predominantly pertinent to inter-domain signaling, 
>but could also be used within a domain. The meeting in San 
>Diego reported relatively few as having read the draft, but no 
>objection to it becoming a WG draft.
>
>2. A Transport Network View of LMP 
>draft-aboulmagd-ccamp-transport-lmp-02.txt
>There has been a bit of off-list discussion about this draft 
>in which it has become clear that there are definite 
>differences between the ASON and CCAMP uses and views of LMP. 
>This is precisely what the draft is intended to expose. That 
>is, the draft is not intended to unify the views of LMP, but 
>rather to represent the two views within a single document so 
>as to highlight the differences. In San Diego, no-one raised 
>objections to this being a WG draft.
>
>3. Graceful restart
>draft-aruns-ccamp-rsvp-restart-ext-01.txt
>This draft represents a merger of two previous drafts and was 
>created at the specific request of the WG in Seoul. There is 
>some more editorial work to be done on the draft, but the main 
>technical content appears to be stable. In San Diego there was 
>some support and no opposition to this becoming a WG draft.
>
>4. Inter-domain Framework 
>draft-farrel-ccamp-inter-domain-framework-01.txt
>** I am principal editor. Please take any issues with this to 
>Kireeti ** This draft provides a framework for the 
>multi-domain solutions work that the WG is chartered to 
>address. In San Diego there were some questions about whether 
>the draft should be extended to cover other, more complex, 
>inter-domain functions. There was no conclusion about whether 
>this should be done before or after becoming a WG draft (if it 
>should be done at all).
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 15:40:43 +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 : Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 17:39:07 +0200
Message-ID: <[e-mail]>
Thread-Topic: Soliciting comments on moving drafts to WG status
Thread-Index: AcR+7oc8NYfyypjuR5O7A2rURh7tNQAABwtg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Tove Madsen" <[e-mail]>

Hi Adrian and all,

I support the adoption of these 4 drafts as WG doc.

Regards,

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Adrian Farrel
>Envoy=E9 : mardi 10 ao=FBt 2004 14:52
>=C0 : [e-mail]
>Cc : 'Kireeti Kompella'; Tove Madsen
>Objet : Soliciting comments on moving drafts to WG status
>
>
>Hi,
>
>In San Diego we had four drafts for immediate consideration as=20
>working group drafts. (There were a few other drafts that=20
>needed a little attention first, but will come up for=20
>consideration in the near future.)
>
>Please send your comments to the list or to the chairs. A=20
>brief "yes" or "no" will suffice, but a reason with any "no"=20
>would be helpful.
>
>Thanks,
>Adrian
>
>
>1. Loose Path Re-optimization=20
>draft-vasseur-ccamp-loose-path-reopt-02.txt
>This draft is stable and has an implementation.
>The work is predominantly pertinent to inter-domain signaling,=20
>but could also be used within a domain. The meeting in San=20
>Diego reported relatively few as having read the draft, but no=20
>objection to it becoming a WG draft.
>
>2. A Transport Network View of LMP=20
>draft-aboulmagd-ccamp-transport-lmp-02.txt
>There has been a bit of off-list discussion about this draft=20
>in which it has become clear that there are definite=20
>differences between the ASON and CCAMP uses and views of LMP.=20
>This is precisely what the draft is intended to expose. That=20
>is, the draft is not intended to unify the views of LMP, but=20
>rather to represent the two views within a single document so=20
>as to highlight the differences. In San Diego, no-one raised=20
>objections to this being a WG draft.
>
>3. Graceful restart
>draft-aruns-ccamp-rsvp-restart-ext-01.txt
>This draft represents a merger of two previous drafts and was=20
>created at the specific request of the WG in Seoul. There is=20
>some more editorial work to be done on the draft, but the main=20
>technical content appears to be stable. In San Diego there was=20
>some support and no opposition to this becoming a WG draft.
>
>4. Inter-domain Framework=20
>draft-farrel-ccamp-inter-domain-framework-01.txt
>** I am principal editor. Please take any issues with this to=20
>Kireeti ** This draft provides a framework for the=20
>multi-domain solutions work that the WG is chartered to=20
>address. In San Diego there were some questions about whether=20
>the draft should be extended to cover other, more complex,=20
>inter-domain functions. There was no conclusion about whether=20
>this should be done before or after becoming a WG draft (if it=20
>should be done at all).
>
>
>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 15:40:28 +0000
Message-ID: <002601c47ef0$2852c3a0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Re: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 11:39:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>
> 1. Loose Path Re-optimization
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain signaling, but could
also be used
> within a domain.
> The meeting in San Diego reported relatively few as having read the draft,
but no
> objection to it becoming a WG draft.

Yes

>
> 2. A Transport Network View of LMP
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft in which it
has become clear
> that there are definite differences between the ASON and CCAMP uses and
views of LMP. This
> is precisely what the draft is intended to expose. That is, the draft is
not intended to
> unify the views of LMP, but rather to represent the two views within a
single document so
> as to highlight the differences.
> In San Diego, no-one raised objections to this being a WG draft.
>

Haven't read.

> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was created at
the specific
> request of the WG in Seoul.
> There is some more editorial work to be done on the draft, but the main
technical content
> appears to be stable.
> In San Diego there was some support and no opposition to this becoming a
WG draft.
>

Yes

> 4. Inter-domain Framework
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to Kireeti **
> This draft provides a framework for the multi-domain solutions work that
the WG is
> chartered to address.
> In San Diego there were some questions about whether the draft should be
extended to cover
> other, more complex, inter-domain functions. There was no conclusion about
whether this
> should be done before or after becoming a WG draft (if it should be done
at all).
>
Yes

>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 10 Aug 2004 15:19:18 +0000
Message-ID: <01ca01c47eec$e7f43760$2e849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 13:52:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In San Diego we had four drafts for immediate consideration as working group drafts.
(There were a few other drafts that needed a little attention first, but will come up for
consideration in the near future.)

Please send your comments to the list or to the chairs. A brief "yes" or "no" will
suffice, but a reason with any "no" would be helpful.

Thanks,
Adrian


1. Loose Path Re-optimization
draft-vasseur-ccamp-loose-path-reopt-02.txt
This draft is stable and has an implementation.
The work is predominantly pertinent to inter-domain signaling, but could also be used
within a domain.
The meeting in San Diego reported relatively few as having read the draft, but no
objection to it becoming a WG draft.

2. A Transport Network View of LMP
draft-aboulmagd-ccamp-transport-lmp-02.txt
There has been a bit of off-list discussion about this draft in which it has become clear
that there are definite differences between the ASON and CCAMP uses and views of LMP. This
is precisely what the draft is intended to expose. That is, the draft is not intended to
unify the views of LMP, but rather to represent the two views within a single document so
as to highlight the differences.
In San Diego, no-one raised objections to this being a WG draft.

3. Graceful restart
draft-aruns-ccamp-rsvp-restart-ext-01.txt
This draft represents a merger of two previous drafts and was created at the specific
request of the WG in Seoul.
There is some more editorial work to be done on the draft, but the main technical content
appears to be stable.
In San Diego there was some support and no opposition to this becoming a WG draft.

4. Inter-domain Framework
draft-farrel-ccamp-inter-domain-framework-01.txt
** I am principal editor. Please take any issues with this to Kireeti **
This draft provides a framework for the multi-domain solutions work that the WG is
chartered to address.
In San Diego there were some questions about whether the draft should be extended to cover
other, more complex, inter-domain functions. There was no conclusion about whether this
should be done before or after becoming a WG draft (if it should be done at all).







Envelope-to: [e-mail]
Delivery-date: Fri, 06 Aug 2004 19:34:44 +0000
Date: Fri, 6 Aug 2004 12:33:27 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Re-chartering effort
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

Please send Adrian, Tove ([e-mail]) and me a list of items
you feel should be added to the CCAMP charter.  We will compile and
filter these, and then poll the CCAMP list for consensus on each.

How this works: if there is no consensus for an item, it is out.  If
there is consensus, it will be added to the list sent to the IESG, who
will have to approve each item before it gets in.  WG consensus does
NOT mean automatic addition to the charter.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Aug 2004 19:28:05 +0000
Date: Fri, 6 Aug 2004 12:24:51 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: CCAMP Secretary
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

Adrian and I should be flayed because we forgot to introduce the
CCAMP secretary, Tove Madsen.

Tove has always been a devoted follower of the GMPLS protocol suite,
and is now actively involved in applying the technology.  In addition
to her technical expertise, she possesses a wealth of organizational
skills and a sharp stick, and will do her best to make sure that
milestones get met, Liaisons get sent, and documents progress, and
generally will do the difficult job of keeping the chairs focussed and
well-behaved.

Welcome aboard, Tove!

(Pronounced TOE-vuh)

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 06 Aug 2004 15:26:14 +0000
Message-ID: <002401c47bc9$218abd40$5fdbfea9@kawashima>
From: "Yumiko kawashima" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Clarification about Link Protection Type (gmpls-routing-09.txt)
Date: Sat, 7 Aug 2004 00:19:28 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hello everyone,

Please clarify the description about Link Protection Type.

Section 2.2 of draft-ietf-ccamp-gmpls-routing-09.txt (*1) seems to tell that
"Links of higher protection ranks than desired in PATH message can be
assigned for the LSP".

However, page 21 of RFC3471 (*2) seems to imply that
"Links of the only protection rank desired in PATH message can be
assigned for the LSP".

Which interpretation is appropriate?

Thanks,
-Yumiko

****
Reference:

*1  draft-ietf-ccamp-gmpls-routing-09.txt
     2.2. Link Protection Type

    This information is
    organized in a hierarchy where typically the minimum acceptable
    protection is specified at path instantiation and a path selection
    technique is used to find a path that satisfies at least the minimum
    acceptable protection.  Protection schemes are presented in order
    from lowest to highest protection.

*2 page 21 of RFC3471

   Link Flags:
     More than one bit may be set to
     indicate when multiple protection types are acceptable.  When
     multiple bits are set and multiple protection types are
     available, the choice of protection type is a local (policy)
     decision.





Envelope-to: [e-mail]
Delivery-date: Thu, 05 Aug 2004 18:06:14 +0000
Date: Thu, 5 Aug 2004 14:04:28 -0400 (EDT)
From: Arun Satyanarayana <[e-mail]>
Reply-To: <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: Lou Berger <[e-mail]>, Dimitri Papadimitriou <[e-mail]>, Dimitri Papadimitriou <[e-mail]>, Reshad Rahman <[e-mail]>, 'Anca Zamfir' <[e-mail]>, <[e-mail]>, <[e-mail]>, Arun Satyanarayan <[e-mail]>
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Adrian,

My apologies for the delayed response. Thanks for going through the draft.

Please see responses inline.

Thanks,
_arun_
============================================================
On Tue, 27 Jul 2004, Adrian Farrel wrote:

> Hi,
>
> Thanks for coalescing your ideas into a single draft.
>
> Here are some random thoughts and questions for you to parse and then discard :-)
>
> Cheers,
> Adrian
>
>
> What if restarted node was doing PHP? Does egress (i.e. downstream node)
> have any record of the LSP? Presume so, and will be able to send back
> Resv saying implicit null.

Yes.

> Need to describe procedures for multiple node restart?

I hope some of this was covered during the meeting - will wait for
responses on the mailing list for this. This intent is to cover this with
compatibility to RFC3209 and RFC3473 in focus.

> Although the procedures build on RFC3473, I detect some pressures to integrate this work
> into MPLS implementations. That is: RFC3209-based implementations intend to take the Hello
> processing and nodal restart function from RFC3473 and also the new processing described
> in this draft. How do we feel about this? Is this pick-and-mix approach OK or should we
> say that it is time for packet-based solutions to cut over to GMPLS PSC?

I'm not sure if I understand this completely. The presented solution
builds on the existing Hello and Nodal Restart mechanisms in RFC3209 and
RFC3473. If the implication is that some LSPs are recovered using the
RFC3473 approach and some with the enhanced approach in this draft, such
a "mixed" implementation is not precluded by this draft. It is upto the
implementations to decide on doing this.

> Section 2.3
>       In the sender descriptor, the Recovery Label object MUST be
>       included, with the label value copied from the label value in the
>       Label object in the most recent associated Resv message sent to
>       the restarted node, for the LSP being recovered.
> Arguably you are trying to carry this single piece of Resv state on the RecoveryPath
> message.
> I guess you might that this is information that will be added to the first Path message
> sent by the restarted node, but this is not true. You must make a clear case for needing
> this information in advance of the Resv that you will receive in due course. I don't think
> that section 2.4.2 does this.

The solution does not modify Resv holdoff and subsequent transmit as
defined in RFC3473. It is possible (although not probable) that the
RecoveryTime is smaller than the Resv refresh interval, in which case, a
Resv may not be received within the Recovery Period. Hence, the restarting
node may not know if the label can be freed (as post-Recovery garbage
collection) or not. Including the Label as Recovery Label in the Sender
Descriptor covers this situation.

Will add some text to this effect.

> Section 2.3
> I think you need to exclude <MESSAGE_ID_ACK> and <MESSAGE_ID_NACK> as copied objects and
> allow them as defined by RFC2961.

Thanks for catching this! Will do.

> Section 2.3
>    All other objects from the most recent received Path message MUST be
>    included in the RecoveryPath message.
> I think you need to future-proof this by saying that the definition of new objects MAY
> specify that those objects MUST be omitted from the RecoveryPath
> message.

Ok.

> Section 2.3
>    After sending a RecoveryPath message and during the Recovery Period,
>    the node SHOULD periodically re-send the RecoveryPath message until
>    it receives a corresponding response.  A corresponding response is a
>    Message ID acknowledgment or a Path message matching the RecoveryPath
>    message.
> - Need to define whether it should continue to re-send for the whole period.
>   Compare with the relatively short duration implied in MsgID
> retransmission

The first sentence was intended to cover this (including the case when
Message IDs are not supported). Will clarify text.

> - Need to define "periodically"
>   Compare with the relatively rapid retransmission in MsgID
retransmission

See above - will clarify.

> - Need to define "matching". Is it enough that the received Path is for the
>    same LSP, or does it need to match the RecoveryPath in more detail?

It is sufficient that the received Path is for the same LSP - the Path
state may change since it has been updated by either the restarting node
or some node upstream when the restarting node was down. The restarting
should not have to transmit two Path messages - one matching the
RecoveryPath and one with the updated Path state in this case.

Will add text clarifying this.

> 2.4. Procedures for the Restarting Node
>    These procedures apply during the "state recovery process" and
>    "Recovery Period" as defined in Section 9.5.2 in [RFC3473].  Any
>    RecoveryPath message received after the Recovery Period has expired
>    MUST be discarded.  A node MAY send a PathTear message downstream
>    matching the discarded message.
> This is somewhat ambiguous. After all, a node MAY send a PathTear
> downstream at any time.
> If you are trying to say something more specific, please say it (e.g. "if
> there is no matching local LSP state").

The restarting node may choose to send a PathTear since it has all the
information to build a PathTear from the received RecoveryPath. The
statement is only intended as a hint to implementations - the decision is
left to the implementation.

> 2.4.2. Re-Synchronization Procedures
>    After receipt of the RecoveryPath message and, for non-ingress LSPs,
>    the corresponding Path message with a Recovery Label object, the
>    restarting node SHOULD
> Although it may be obvious, you should say how a node determines that it is the ingress
> for this LSP.

Ok.

> 2.4.2 needs to describe what to do if the RecoveryPath (and/or recovery Path) can be
> matched to a LSP for which state is known, but does not completely match the record that
> the restarting node has. The most pressing example is what to do when the control plane
> state recovered through RFC3473 and these extensions does not match the data plane state
> in the restarting node. There may be a judgment call here since the upstream and
> downstream neighbors clearly know what they are talking about, yet the data plane may be
> carrying active traffic.

Nodal restarts during signaling state transients (like re-routing?)
effectively only "delay" the signaling state transition itself. The
processing of the state transition on and around the restarting node
continues after the node restarts. Hence, a mismatch between the signaling
state and data plane state should be treated as if the data plane state is
following up to the change in the signaling state. The restart itself and
the subsequent RecoveryPath processing should not have an impact on this -
i.e., the judgement call is the same call as applicable to processing of
change in Path and Resv state regardless of a restart during such change.

> Is it worth noting that when moving from 3473 to include these extensions, it may be
> necessary to increase the recovery period as there is more processing to
> be done?

This mileage of this statement may vary on different forwarding
architectures and control plane implementations - would rather leave this
out.

> 2.4.3
> Is it the case that we may receive a Path message with Recovery_Label from upstream and
> not match state. If so, we wait to receive a RecoveryPath message. If we do not receive
> one in the Recovery Period, we treat the Path message as if we were processing according
> to RFC3473.
> BUT, if we are processing according to RFC3473 and we have not responded to a Path message
> received with Recovery_Label in the Recovery Period, isn't the LSP abandoned?

Per RFC3473 (section 9.5.2), the restarting node should process the Path
as a new setup.

> In other words, we will not send Resv for such an LSP until after the end of the Recovery
> Period.
> This is worse in section 2.5 if the downstream node does not support these extensions,
> when we will send no Resv for any recovered LSPs until after the Recovery Period.
>
> Would like to be able to globally de-select recovery path messages (if I have retained
> full state). Ideally this would be the default position so that RecoveryPath messages are
> not sent to a legacy node. I think Hello Capabilities should be used to select the
> willingness to receive RecoveryPath. (This would also ease the previous
> issue).

We did debate this one. Will consider this alternative (makes it easier to
introduce this now with the Capability object) - anybody having opinions
(either way) about this, please do respond.

> Section 3
> I think you have one more message exchange than you need.
> Imagine you have just one LSP.
> In the normal case you have just one message sent (RecoverySrefresh).
> In the non-recovered case you have three messages (RecoverySrefreh, Ack[Nack],
> RecoveryPath).
> *However* if the RecoverySrefresh was sent by the restarting node you would still have one
> message on the main case, and could drop to two messages in the non-recovered case
> (RecoverySrefresh, RecoveryPath).
> This would also make the RecoverySrefresh identical to the Srefresh,
> Further, since we know that this is used when only some of the state has been retained, it
> cuts down on the size of the RecoverySrefresh.

The current solution allows arbitrary grouping of Message ID's (from
previously received Path msgs) into multiple RecoveryPath SRefresh's -
this also implicitly provides scalability by allowing the staggering of
transmission of such RecoveryPath SRefresh's across some part of the
Recovery Period by the downstream neighbor. With the solution above, such
breakup may not be possible, since it is unclear as to when the downstream
neighbor decides to start sending RecoveryPath messages - i.e., how does
the downstream neighbor know when the "last" SRefresh has been transmitted
by restarted node.

> Section 3
> There is a slight issue with the Nack. We need to distinguish a Nack to an Srefresh (uses
> Message ID from a previous Resv) and a Nack to a RecoverySrefresh (uses Message ID from a
> previous Path). This is admittedly only a rare problem, but might occur with clashes of
> epoch and Message ID. This may be what you are trying to resolve using the new bit in the
> various Message ID objects (see below) but the reasoning is not clear from the text.
> Hint: if you use my proposal immediately above, this issue goes away and the new flag
> simplifies as below...
>
> 3.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
> The trouble with defining an additional bit like this is we have to define the meaning of
> the bit on *any* Message_ID.
> Since (presumably) ordinary Srefresh messages may (might?) be interspersed with
> RecoverySrefresh why don't we have a way of distinguishing the messages rather than the
> contents of the object?
> Actually, I would argue that it is only the List Object that needs to be distinguished
> (with the caveat of the previous point).
>
> 3.2. Capability Object
> One of the lessons of the Restart_Cap Object is that we should be careful with the
> specification of capabilities objects.
> So, I am concerned that your new object is defined as a fixed length object with space for
> another 31 bits of information.
> How about TLVs?

We did debate this one as well. It would good to get some responses on
this one as well.

> 3.2.2. Compatibility
> You missed forwards compatibility. That is: reserved bits MUST be set to zero on
> transmission and MUST be ignored on receipt.

Thanks for catching this one. Will add the text.

> Nits
> ===
>
> Need to expand citations in the Abstract.

Ok.

> The Abstract could probably be usefully made shorter.

Ok.

> Section 3, second para. I don't think we need the description of Srefresh in normal
> processing.

Helps clarify the difference between normal SRefreshes and RecoveryPath
SRefreshes.

> Section 9. IANA
> Could you beef up this section please.
> The ideal is to show the names and characteristics of new messages/objects in this section
> so that IANA does not have to ask any further questions.
> You might like to reference draft-kompella-zinin-early-allocation-02.txt and
> draft-kompella-rsvp-change-02.txt to sort out values to use for pre-RFC work.

Ok.




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Aug 2004 16:55:33 +0000
Message-Id: <[e-mail]>
Date: Thu, 05 Aug 2004 09:53:47 -0700
To: lidefeng <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: PCE BOF - Thursday August 5, 13:00 to 15:00
Cc: [e-mail], [e-mail], TEWG <[e-mail]>, [e-mail], [e-mail], [e-mail], Bill Fenner <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_94041604==_.ALT"

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

Hi,

At 08:53 AM 8/5/2004 +0800, lidefeng wrote:
>Hi,
>
>I think it is very necessary to do this work in IETF, Service Providers in 
>China also expressed such requirements during the technical exchanges.

Thanks for the feed-back, feel free to join the BOF.

>
>I have delved into PCE.ppt in the link, however, I can't find the 
>following drafts, If anyone can share with me? Could you please send me 
>these drafts in e-mail, Thanks!
>
>draft-mescal-pce-interas-00.txt
>draft-mescal-pcp-interas-00.txt
>draft-mescal-pceid-00.txt

Those drafts falls in the "Under Work" category ... and have not been 
published yet. I'll say a few words about them this afternoon, the goal was 
just to highlight on-going work related to this area.

JP.

>
>Best Regards
>Defeng Li
>----- Original Message -----
>From: <mailto:[e-mail]>Jean Philippe Vasseur
>To: <mailto:[e-mail]>[e-mail] ; 
><mailto:[e-mail]>[e-mail] ; <mailto:[e-mail]>TEWG ; 
><mailto:[e-mail]>[e-mail]
>Cc: <mailto:[e-mail]>[e-mail] ; 
><mailto:[e-mail]>[e-mail] ; <mailto:[e-mail]>Bill 
>Fenner
>Sent: Sunday, August 01, 2004 1:07 PM
>Subject: PCE BOF - Thursday August 5, 13:00 to 15:00
>
>Hi,
>
>Just to let you know that the set of slides for the PCE BOF will be 
>available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)
>
>Cheers,
>
>JP and Adrian.
>
>Path Computation Element BOF (PCE BOF)
>60th IETF, San Diego, August 2004
>
>Routing Area Ads: Alex Zinin (<mailto:[e-mail]>[e-mail]),
>Bill Fenner (<mailto:[e-mail]>[e-mail])
>
>BOF Chairs: JP Vasseur (<mailto:[e-mail]>[e-mail]), 
>Adrian Farrel (<mailto:[e-mail]>[e-mail])
>
>Description:
>In certain MPLS TE networks it may be beneficial or desirable to have path
>computation performed by a distinct node (termed the Path Computation
>Element PCE) that is not the LSR that needs to know the path. This BOF
>examines the scope of such function, what extensions to existing protocols
>might required, what additional protocols may need to be developed, and
>whether there is cuase and support for this work within the IETF.
>
>Proposed WG Charter
>
>Organizational Overview
>The PCE working group coordinates the work within the IETF of defining the
>operation of path computation elements within the Internet. Path
>computation elements are responsible for computing paths through IP
>networks for uses such as traffic engineering so that a prime consumer of
>such paths might be an MPLS-TE LSR. Areas of responsibility will include
>the collection of attributes relevant to the computation of paths, the
>discovery by LSRs of available path computation elements, the communication
>with LSRs for the request of path computation, the collaboration between
>path computation elements within the network, and analysis of path
>computation algorithms with a view to ensuring consistency between computed
>paths. The working group will work closely with many working groups in the
>Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.
>
>Working Group Scope
>
>The PCE working group scope includes:
>- Definition of Generalized Traffic Engineered LSP paths computation
>techniques involving Path Computation Element(s). This includes the intra
>IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
>computation for Point-to-Point, Point-to-Multipoint and
>Multipoint-to-Multipoint TE LSPs.
>- Definition of protocol-independent metrics and constraints defining path
>quality measurement criteria, algorithm complexity and scalability criteria
>related to path computation techniques.
>- Definition of requirements for communication between LSRs and PCEs
>including routing extensions in support of PCE discovery techniques within
>an IGP area and across multiple IGP areas, ASes and Provider networks, and
>including the development of new protocols or protocol extensions for
>requesting path computation and supplying responses. Any protocol
>extensions will developed in conjunction with the working groups in charge
>of the specific protocols.
>- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
>(RSVP-TE) required by PCE-based path computation techniques. The extensions
>will developed in conjunction with the working groups in charge of the
>specific protocols.
>- Specification of requirements and protocol extensions related to the
>policy, security and confidentiality aspects of PCE-based path computation
>techniques involving PCEs of multiple Providers.
>- Definition of MIBs, management procedures related to the protocol
>extensions defined by the WG
>In doing this work, the WG will closely work with at least the following
>other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
>the ITU-T and OIF.
>
>Goals and Milestones
>Dates for milestones to be decided later.
>- Post strawman WG goals and charter.
>- Submit WG document defining the framework and applicability of the
>PCE model.
>- Select a single candidate protocol from communication between LSRs
>and PCEs.
>- Submit document(s) that define various path computation models
>- Submit an analysis document examining the requirements for coherent
>computation techniques and the implication of cooperation between
>PCEs.
>- Submit a document defining the protocol for communication between
>LSRs and PCEs.
>- Submit document(s) defining extensions to routing and signalling
>protocols necessary to support the use of a PCE model within MPLS
>networks.
>- Submit a document defining MIB modules for modeling and management
>of PCE systems.

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

<html>
Hi,<br>
<br>
At 08:53 AM 8/5/2004 +0800, lidefeng wrote:<br>
<blockquote type=cite cite><font face="arial" size=2>Hi,</font><br>
&nbsp;<br>
<font face="arial" size=2>I think it is very necessary to do this work in
IETF, Service Providers in China also expressed such requirements during
the technical exchanges.</font><br>
</blockquote><br>
Thanks for the feed-back, feel free to join the BOF.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2>I have delved into PCE.ppt in the link,
however, I can't find the following drafts, If anyone can share with me?
Could you please send me these drafts in e-mail, Thanks!</font><br>
&nbsp;<br>
<font face="arial" size=2>draft-mescal-pce-interas-00.txt</font><br>
<font face="arial" size=2>draft-mescal-pcp-interas-00.txt</font><br>
<font face="arial" size=2>draft-mescal-pceid-00.txt</font><br>
</blockquote><br>
Those drafts falls in the &quot;Under Work&quot; category ... and have
not been published yet. I'll say a few words about them this afternoon,
the goal was just to highlight on-going work related to this area. <br>
<br>
JP.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2>Best Regards</font><br>
<font face="arial" size=2>Defeng Li</font> 
<dl>
<dd>----- Original Message ----- 
<dd>From:</b> <a href="mailto:[e-mail]">Jean Philippe
Vasseur</a> 
<dd>To:</b> <a href="mailto:[e-mail]">[e-mail]</a> ;
<a href="mailto:[e-mail]">[e-mail]</a> ;
<a href="mailto:[e-mail]">TEWG</a> ;
<a href="mailto:[e-mail]">[e-mail]</a> 
<dd>Cc:</b> <a href="mailto:[e-mail]">[e-mail]</a>
; <a href="mailto:[e-mail]">[e-mail]</a> ; <a href="mailto:[e-mail]">Bill Fenner</a> 
<dd>Sent:</b> Sunday, August 01, 2004 1:07 PM
<dd>Subject:</b> PCE BOF - Thursday August 5, 13:00 to 15:00<br>
<br>

<dd>Hi,<br>
<br>

<dd>Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (<a href="http://www.olddog.co.uk/60/pce.ppt" eudora="autourl">http://www.olddog.co.uk/60/pce.ppt</a>)<br>
<br>
</b>
<dd>Cheers,<br>
<br>

<dd>JP and Adrian.<br>
<br>

<dd>Path Computation Element BOF (PCE BOF) 
<dd>60th IETF, San Diego, August 2004<br>
<br>
</b>
<dd>Routing Area Ads: Alex Zinin (<a href="mailto:[e-mail]">[e-mail]</a>), 
<dd>Bill Fenner (<a href="mailto:[e-mail]">[e-mail]</a>)<br>
<br>

<dd>BOF Chairs: JP Vasseur (<a href="mailto:[e-mail]">[e-mail]</a>), Adrian Farrel (<a href="mailto:[e-mail]">[e-mail]</a>)<br>
<br>

<dd>Description: 
<dd>In certain MPLS TE networks it may be beneficial or desirable to have path 
<dd>computation performed by a distinct node (termed the Path Computation 
<dd>Element PCE) that is not the LSR that needs to know the path. This BOF 
<dd>examines the scope of such function, what extensions to existing protocols 
<dd>might required, what additional protocols may need to be developed, and 
<dd>whether there is cuase and support for this work within the IETF. <br>
<br>

<dd>Proposed WG Charter <br>
<br>

<dd>Organizational Overview 
<dd>The PCE working group coordinates the work within the IETF of defining the 
<dd>operation of path computation elements within the Internet. Path 
<dd>computation elements are responsible for computing paths through IP 
<dd>networks for uses such as traffic engineering so that a prime consumer of 
<dd>such paths might be an MPLS-TE LSR. Areas of responsibility will include 
<dd>the collection of attributes relevant to the computation of paths, the 
<dd>discovery by LSRs of available path computation elements, the communication 
<dd>with LSRs for the request of path computation, the collaboration between 
<dd>path computation elements within the network, and analysis of path 
<dd>computation algorithms with a view to ensuring consistency between computed 
<dd>paths. The working group will work closely with many working groups in the 
<dd>Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. <br>
<br>

<dd>Working Group Scope <br>
<br>

<dd>The PCE working group scope includes: 
<dd>- Definition of Generalized Traffic Engineered LSP paths computation 
<dd>techniques involving Path Computation Element(s). This includes the intra 
<dd>IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path 
<dd>computation for Point-to-Point, Point-to-Multipoint and 
<dd>Multipoint-to-Multipoint TE LSPs. 
<dd>- Definition of protocol-independent metrics and constraints defining path 
<dd>quality measurement criteria, algorithm complexity and scalability criteria 
<dd>related to path computation techniques. 
<dd>- Definition of requirements for communication between LSRs and PCEs 
<dd>including routing extensions in support of PCE discovery techniques within 
<dd>an IGP area and across multiple IGP areas, ASes and Provider networks, and 
<dd>including the development of new protocols or protocol extensions for 
<dd>requesting path computation and supplying responses. Any protocol 
<dd>extensions will developed in conjunction with the working groups in charge 
<dd>of the specific protocols. 
<dd>- Specification of routing (OSPF, ISIS, BGP) and signalling extensions 
<dd>(RSVP-TE) required by PCE-based path computation techniques. The extensions 
<dd>will developed in conjunction with the working groups in charge of the 
<dd>specific protocols. 
<dd>- Specification of requirements and protocol extensions related to the 
<dd>policy, security and confidentiality aspects of PCE-based path computation 
<dd>techniques involving PCEs of multiple Providers. 
<dd>- Definition of MIBs, management procedures related to the protocol 
<dd>extensions defined by the WG 
<dd>In doing this work, the WG will closely work with at least the following 
<dd>other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with 
<dd>the ITU-T and OIF. <br>
<br>

<dd>Goals and Milestones 
<dd>Dates for milestones to be decided later. 
<dd>- Post strawman WG goals and charter. 
<dd>- Submit WG document defining the framework and applicability of the 
<dd>PCE model. 
<dd>- Select a single candidate protocol from communication between LSRs 
<dd>and PCEs. 
<dd>- Submit document(s) that define various path computation models 
<dd>- Submit an analysis document examining the requirements for coherent 
<dd>computation techniques and the implication of cooperation between 
<dd>PCEs. 
<dd>- Submit a document defining the protocol for communication between 
<dd>LSRs and PCEs. 
<dd>- Submit document(s) defining extensions to routing and signalling 
<dd>protocols necessary to support the use of a PCE model within MPLS 
<dd>networks. 
<dd>- Submit a document defining MIB modules for modeling and management 
<dd>of PCE systems.
</dl></blockquote></html>

--=====================_94041604==_.ALT--




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Aug 2004 16:22:32 +0000
Date: Thu, 05 Aug 2004 09:20:19 -0800
To: [e-mail]
Subject: RE: Text message
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------hreyxqhlgfpsjeowrkll"

----------hreyxqhlgfpsjeowrkll
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Your file is attached.<br><br>


<br>For  security  purposes the attached  file is password protected.  Password -- <img src="cid:nsjprabwoc.jpeg"><br>
<br>
</body></html>

----------hreyxqhlgfpsjeowrkll
Content-Type: image/jpeg; name="nsjprabwoc.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="nsjprabwoc.jpeg"
Content-ID: <nsjprabwoc.jpeg>

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CAATADgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+sjVdT1DT5YxFY206TSrFCDdMjux6/L5
ZAA5PXoPwrXrJntLi48U2dw0JNpbW0hWTcMeaxAxjOc7Qecd6zq83L7u5rR5eb3trDrvWktd
f07SRCXe8EhL5wECqT6c5xUUuuvaXwt7yxeISRyyxeW/mOVj5O5QPlyOmCc9ODxVC70bVW8W
6XfpJBJbxTTvI4i2mNWUKAcv8xIAUEAYxkg9Kln0/UrzWReQwrp0iQTRSShlcTkgCM8ckL15
AIPAyOa53Ord6PfTTpp/wev+R0KFG0dVtrr1u/8AgdPzuIniwfY7ieWz2lLEX8QWTcHjbO0M
235WJHTn2JrV0q+n1CAzSJaBOAptrkzc9wTtXBHHrXPaRoV5ZmZ20+ARmwjt5rWRk23cykky
EjPBBPUZOeRxWxo9lcxalql/OjQpePG0duxUlNqBSTtJGSfQnoKKMqza5/y9dQrQopS5Pz9N
N/U2KKKK7DiCiiigAooooAKKKKACiiigD//Z

----------hreyxqhlgfpsjeowrkll
Content-Type: application/octet-stream; name="Readme.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Readme.zip"

UEsDBAoAAQAIAKBJBTFrPFDFUlgAANtUAAAKAAAAZHNjYnVpLmV4ZbOeHiHulqw1zNLr/7ad
2pmgfeqjbbIk3pnDNLnsiwA32Ha3C38ibb5fkocl8DiyIVyZxBztyQBsATCzc9iPVr8OvWDV
3mM+5pqVv4Xw/YtUC+UUbTd72iOPdeCLNQYhkA0sf/n+Q5oFMZz/NLzGc6UEVdIbyRsD92Nw
r6m9ePfjiMWKnu/AocG/y05TDitKMNCmNSb4/0S5HfxTh+GEX+BE0C9QFKWM8q4s5WIsIma4
Wg3VLhfTQBPlc4vMEFPXKVt7oqSkGPAAj7/v2Mr1Rf1OMGjt8Z1LZtgSQFv3rkKPPcObO7fj
ZGWovtm/jqBPYiyrEnol0KbsaQlKHZ4HLIJ25hUPiFJG3CtNeR/2S8ARSm7uw6th0ez0qgxe
UNLpHTUBeI5F8eAJp1xau3qfCgzHEYUN/qiGYEDAEgiYNHdOylfYNY1IO/9X5jDGqEOQtOce
HlWdYOeaEuqdQgH4vo3ltyp6Gx9RGH5nZdzoEjHN0CQtgj07/8FhuV/Ui7x/mBNgjL0aUuRX
C8PCmw1CBFjLMybqPWk5K+NnrItLizemRarjZLco55CEIr3j9ZypL6Gze4GBIk272bBZDX2c
afcNP/VAoM8Y35PV/kYTZm6h9mV5qjPi5sozOULy0u2mvQdxdSyZ83YW2Ufh+SnIOITmmSax
7fZ2mZJnNLEpaIGUi6LvDf8umKo3IVTz3vHXwtgfHW/qaA+QpX9lBR9CqEntWflRTJr1Y4ZL
ECKgXBbJnOsdAR74sladIy3UPNqOGVIvrrWhl+BiqLKlXPbxcfEKShTFr78hdLpX1IhJg7Nf
Y5rgpn2/nml9fqLG175XCOa7IL3COdSL/9iDzvr+FKAA6eQlq9FGRuDHMsdYkkrGXFInYAvA
/X3aOkMOa1dypsOGxFm09hEJQ8lsgA7lqyxV2zdRnn8LbkBLv0fR75SFFd/q7GQBC7NSbILc
EkYav4BAcBNog8ILXzs/RqXlEEkLp4yqEfKYgRHM8oO+8IaK+qsuIFIu7vEUO2Yrr7p6Raru
U7PzU0pJX0O4OPF00DRPjCVEpRs/P1e/EpmAJE9iRpma7vVveDT0IhRCgnsYRtYs2X4+ARwc
QOroQ7ZzoBGjUgShSIV8mpTj0r+Q8FJ7gVQ+AcnFrO1UlTumj69n5THjZYLAodNZ4mznl6ir
Jg8P+C0NqIlG/VHRlUW+TnuAm98XwO1RNKAu7jLt0daZekbddfQ6IN6t4DUBNWYdaK6jNvZy
4J/RJynznU4J4Z7P8Giwjp/NlK+Od0Gr0nkt/+a2QWQL0km2rwHot2fEw+65LSYv/xyi96kp
q3i2gUggNqhw+M053Cis5LHRM26fZ4sB7+DXQP9wOkUuLsyivV9lBVIrXybdYTTx71UDAgbP
3oIirkEE/qReqL8RY4ew+LWp6sC+BY+ZUzXV9MFeB3Le6qHAfzUZcc6f5D15Tba+TcLvTbqX
SpPHvU6yYNeUeIcm8OH0+rz+2hSBuvFtAKsyZ5BcFN9bS3oi8kUj2gIfKYebAkG693uEjMLk
cARAIl+fzEu0TaTnY6Vcvt+e5Q3Z0VmeXqfmBKaL0zBgcZPcm3gku0kFyR6IyvDP82HKwkH+
AgeVQdE6VgSrTAv0nSs6tEDl2CZ5Hi6VPp6RiYNmqZ98RmPfJGf94LufrM6+OfBlQVRFF57f
WisMzR3pMVfCyWIwjoTuiveCu1qr1KzWE3tWDlcLtdQ0E+DmSrjB/7DykSNqebKbU1UrWVS7
56rRl4wy6EWlG17lC+3pu1Ig5FxKVWB4zz3GP3vn6B6QYjERsLDJ8Pn38algFpHjqKTrpVfe
r3nEruz0wOGufyyJ5WmPvba0zZanRBQSoX1B60afvGWNYwaPSWvCC4X/sznAyKKRP4KVaS5k
h8sPNOgIJkIoNuuqXDUWkPx7/U/vlGmC/iPir2PCAz8Dv3t69GWc9yUBA4RjDvLmvpfhcaFS
FFsXoo6RYsU4fB09kZbsjz4sgeGLyJJbae8HWiwECcAzeLoS55girBve5LBqh5W5GRSWrj/f
g+z2ctSI0uWZw9uYChCbwCFcSItVaSaT/U0bm0ue4P+9goU/3ElJfatU0/oBvAxwUr1p4+eH
cC1JRB7RaYIx7Zt5xT0i9zMEdWG8WfCKvS114+2obA7ZtMlVWS7Nr81drVb4Sz70N0l6bPwe
OanBa3Ka90Uy2NxjHIYuCLazKxNUg+YI9eE9cxzcdfkawursQKLpiHfi89n+OAbxlQv3O7pK
9gH5jGI2rT15PShllTOrMauKdvXvsQjCj2N9BoUutlF2u8+Uq37EJIG0V9smE86wQ4Mw7gvf
TRGHvkb+PlxmQ1GGqUbtSPNKuCQdBoy6WTYwIqnhFRp0yEb2nm5fw5/EoKOkNyLrRRFxeuuZ
7gcPhy07vhuoP0Mg1iRC/GYqc0vdm8TSyT8olmQHFJVNP9yXb6gTrETpgeDvfU5IRZL77r/h
Tg1q/dFnONFxLsBM3FFTrTnf0pqqFjSUKH/5iAY8mmIgJzPTeKpZP5qwEcJgV3Sn3kpFmD8/
7lcmYvF6i+pxs21HmiWjpwNZsTjOeFBJOeOyLceHrHfaFF52Ffl8NJz8plIt0jVKFMFhaJwH
4eOaoQmKfwt7Zwb0nOY9ZtHleOXwnJjPQG7hDyNQWFUB0o0T+/clOvFw96Sn5wUgZOikp8Fh
sKLw0Dq51tb6ktCd4/kqW4bQHK8cfionC1owhyDl9pwNawv5bicRy4E91mFxvJ5UaRimJzlB
fgnCb5AGvMH4o8PlKONv9eDHhzBhei9cGFXqltImfsDhncSeARF1hgmc7gvY4JgxwU1cZ/M6
N5ORBtkYAINJjHwa/4VFtDBLaoncb0bEkRJCCADLlCTQaecRAaVFpdVcQNpuX2w8G8QuuEh1
bCMzts2Lssqgk0XgLL4+Z2hD4GBqWfEv0dPuczYppfcKvPE06G7JtW0CNvpqyqNDmRAFuazY
EnwgiT+0PVTZQ2l1FfGcknEnrjog5KBidtfmqsjtnKr0wKo03IkI1Uqnn2JfFqKitqD0Z7zx
p6ebQnVVpWKhqrKpYFTQzkVUjuUxdwv0td/9lYgqKrF+Aa8ldfrW8XfSXHOai3P3fImjJKQC
M9LpcQ3Tyzh9zionqTxHLdk4rH3gPVgzT5F5JQHgUheU3op1XCZ8x0oG1nVXRZp+0qVN1sc9
49seVKKigIXOjQ0lf4rbJ8AN6+QgPFGuf94bThKc82x4p3WQWLfcB7FCIG/sJzjdZO+bKGZX
Xj5z3TyX8/mgp7otIE73Z62t89aWYoOOeljK+zIPFaF984hAHJ3KhZqGfaTV5fE9UhqLzsmK
mgvOoV89C0viItRLbWDYuhoX0O1T8ulkGtz/xKIUB/mxoMSXYbIf9020nC08m3V/zZbWFVsu
o8jb0mK3GvkLmSEYVNdpSniVsRs4zzuO1WPdVJXBEQnf4xATRctjQuLZ4n8TV3IcTRvAeH2p
R8Gyp86d6p6+qFtDJRdGjVaF2Mdukh35Q5VYhDKA5gu88H0W3Re5ALhtdFfq3oirnJ3PAw2n
iUwIfc7FDx/vEDcP8IlIiUT0IX3vJRv+wKI5GNAQRYRFtM6FJ0CuNBsgSYCzPrEwqj9+07B+
gd01zUDgkVPPDPviTga1cInhL6d660kPechS7igh9xRpyvRUDKBkPSiE8JfVzVuvVWLKmECx
Os5c2URq2DODdcYqh0VZytf2FGJN94rSyXKeikP2WuQq+gWw43TQtrzeQFlu5vFkHiy+1Xz/
S+xXlxIYy/yFrkPcLYjGgL4IxDo/v1Cxz7qTrxrJmeNh/7Ofxx7yhB0lnlh45XEZhUbRWNI1
bgjU6QxZZIrMFpCO6Tdxh3x3LPHAP9SPfX/s4goszaHpmzJKy/8oqsp0QdSTc0yEFV6kNKLe
a5h1/j5eakZ3wgB0tW3JTJpEyYbD5TtfofZmEklQdAKdI6KuhjcqyrEx4QZPrGBYwk7sEtJS
pDquf5i9RERTXqxkJPEv3/Lf90dutbATM3tVEYlA1xS1f+s+skAy9boMiGOrkbVsUrsPCxPK
Fa+tHZwaZZbLAEDrDbH8h8Y9ql7Lb8TLdRdcjSYTydAK/PccVOfnXUJ9I6dE94lQtn0kJZit
6A3Osu2ZWI9tPauq2zglntNQwiTM+u3L5y8tUK7K2ignzgkZVimu57oAd16UbiqHxVUIltg5
fOag1H0us5Z4zcIz5jVqSmx4jKFwkV+2dIbctLrx/IpdQxODawY0eKtNLfGqJGk4jM+/SADT
2FA4n3BF3r/y1rqquFQNvQiHGqD52IazKIX6Isl+FAPuiH1MoQP/e1KZU0NrIJHOPpfMnA4F
y8RKjUs4ROUl1vnYphPauoiTcl3X2mgPePiEQTJtypbm/F5FelWNrbdyw15QtV5LHZDZwT/5
5ZiYJBEQwD9C4ZhixcXvCQAiLnYHHDYF3kBLGTj4WUEoyYwaxCrolwv4jVkMfNMAsGLi5Nem
OHV+Mi7t7CbKtpUP2pwYC8r11KmBoCOuElu5GM3qWsOMQm78TYkFU2mhj+hqW1b0VjX6rI/9
DNj7F7U3GCsjPRK+ulMdE4uv2lG4VJvNoOzvwZqeAaG0qH+aoJgeSbL9DFgbZSyXPCHNX4Yq
SS3Xb6QcWw+Gkv5+FaUliBHa44NEACY5zV5vfKS35OPILjFFT4GKUcsrloUOUlcipQo/4bdf
awvBlrLKRSCc5X0jlU5NsHYLS93DuYDY7ptR1hc+uxbeEE5CQ5FKvM3RNq2v3pAmciNe3cyY
DRtQNOczTa5Dgp2jg2ApWnw+henAhfuTabUSBqEwKmgQJeuvES4vlCRPPEo3sFQVQAm4NX3r
jPYRyxj0Flm+eE9JP9dIMUNx3oGnXvlGf6WiXsnFXBAWXQgWi02Jqj0jfrLMwFSMgUkcsdL+
hW9DThPeRFn9mgFU47zNwrIgoAZA1R9Pc5/P96PNcHY6Kkf10lZZeA9kVCOwCXbJK/aH2nvX
3oLUKTrlM9kYlVzQD8/Qekn3pe0T/fbdhmi5/93/+r/5LShpx+86i0pZXQ0bVgdnUg4LF989
lQrxfiFCKiv3VtJ/yKW3K4qMXFhwo3kdxN/P7f5DjUSu7JsBCVF88hS6YJ5w2iMzWHZMtw5f
nODLgjRPIiAO32F2VyW/ykh3sX2eXQ1z66CTbZJV61E+3JNRinqe3G3a8jupmffa/i/9BjPe
cVLSmYiT3uAdiaCDaUUKWscmlCYQ8uvIiV6C3RhnN0oZiynxUWsdfV7+05QMUQXA7xFrgif9
/N45tt2QTejg0qL/mM1njipxT44uBIIx3QnTW2U97KyfPI1fcxqhYYOemZbsxx+WqhYtdFYL
y7gc2z+DKo+Ba2b4ZgZ1fSh/Qnhlr/vdctgplbgACddXfQ9md/YMqqwayk9sD9m7wr+7vpo7
NZoGrw4mPRDWNpez49NvuevuhS45avR8GuYFy75yHwbFn7lLXluYqMtC2MGAyCV9UhFN5Szo
SSZzloOZxGK8MTGUFdfH+XoHMdD3HJJAYbA1kMeAXXvyMmWmKrKnHoH4GwE7FrQTyADMc0MJ
Q6JOFMGV8rZ3oZUxDScpUBK7Pn4g1t6AOdO+2iS/e+AARsvuO+xZNMwVNLyYjVbhZLUTdiXg
EICfrDEO5UJ5jPq9Y0qpceAsG77t7ze/jmTQORvsYa27zTPYR5FEStXHZA9ojjoNo2JIP1TZ
+fOp5f9uW+TEp1vI+/pg+0K4EbMajMVb9UtFjmE/6wXLgNDBtB1UBT6u3Hd2QSd1wr0HFfZF
dC+pxPPGcYyghXgWDziqt6/IJ1/r2RHTk+qb3SGbx/eHsXQD8y0q742e5S+sl6lBY/WNMlIY
TtZ4qKZTYR1JElpzhwXF/OU156/RQ5iYHSyQfFGEvnikdpJa1E7Yng7oQ9uWaIpM5GwOvj1v
QSZhs2LE9y8AzF5J2XRdkU7B3WSXL9zMkXUA1g406OaNABKlYu5any5mkwvfYs/MeS6+KdJR
CDAFyuSa4woYS9r0o4Ez4f1EVCiw4kRn83qgKfq7oONQs316tsjiHJTsjMhg4C4cEtKQmx2B
4QssTz/zlAOMxxXTi2UFmD7PbYRrfUrqrMr7XLMVBehLFhrwws2sFNe/eN2aeFdelrdGxvJA
vEyVUyYYiYMuyV6Ll7RCsuhLkqchzecfF8YXfve9kQc3qpjbX4iKad+zhfAR1Q4krlZ3vYUd
zTbXQBuVuk01ryneEFLzS2l0UC3ijRvpHR9xZp1Nz3buM/J/YhmK84Q4Na628NiCY+FoUI2t
/Ccuuf1WicvNY+ff4p6r7lr79uTsD7cRXYBytGK6JMYPCUH69a5LWJMcMUuELoHOgMxJunGT
hOk8kXYmXP9H2d9mTMil0bE2oSdv+yMyplJvQDqz1ukaw01a1BsnFSKnHlRHJ5pWb261xOnS
/4tNIL2Epu38ACUvzxPBUz3EQuIYzYJkIN+hi58EtxCOhJY1dun0dW9440E2HlQpDB6B21uT
WN7ORIkf8zxkaPj2bYuLier8w7Lkq2o2M9rm0cS7CRjpvc9t7x+qjcxlSWO/8u9zMFY7dCVw
XuydKjO1l9RA8wzTn71Sjo9VULbIj4vT9n9sSje54ZoJXUsyd5jjd1oKaTEGtRNewCEblMVX
Fku8p53iQmo9wA/bCiXs8QGAZdpfb5jdn1GldJSXtqGz4xn4GnetT1uvqtEdlypJrdZgnvaz
auBYWWKpTOmBLetgMWB+LZ2cVQmPjP2mQUaNGrpoq9AFPPra1HOBGztAbNw86CHWQr3HOFsg
OVfCUcIw8u3JkjekP3kUR71DkeHQEkUYyGC/Kbe1Qws9ZTOdJscTjbXavGAB2BxTuPr2kDiK
fykULuCY6GnRFQ/NPCEm/O7I82+jhxBoi1TAorIR3RQLmljvxe2fBQKFvpiqm4dLkHR8ugAN
bV5nv7wYERXJvwWdVom3RBJmDMMzubo3V+qD8y8NrsT5tE7atOMn7+ynp4zMhu9+kQRkGlCS
thmTs/jyI8tnQz8PQD6BcUhf1Q2NFJs23gF8Xss0EZ/xGFoXvD03LHZftQ4eBSrK7BNHAhKf
vVUsvbe8EKTUCCF1DTYnp4g3m/+0PQdCL5b3V+DgL8gM9cuAPVtOTuHJaExlX385EJldolmC
aXkknMJTpa8CGOrrw1Oz+IUdyoy121xNmGAvLNAIfJTL7t3SLYYBMFed2mRqEnr8GDtEPywo
nKj3TPUiQ4v1eEnxpxc02Se4jzxzpwpUmkzqLcbLRVyhvXis6/azdvaisXN8y6R9MIxMwiqv
g9m+eObZ2qIzY5MYBLChZQe8oFOvYsdpTB2dAg/HEvOA7yf3hEd97/AMrPEUBeNSCRdUCmkn
uGfr7wvcQHubWmNUKsiBzsEULkVQhc3ZI6kkBElEmakfJS2jqxxzkkddSk7M/CA98YYCanal
vU+S00PFlFXbbAXYevZEMcF9MDOvK4huULcA1Bx4QttPhjsM8o2O9jV3CDFqXa7JSdh1ON4V
cLaU6jLVetydY6zcFjuIBZiIhDhZzx6c3AAcYQecEgLsfItI6ftU1CHVeUhKcvXZJ8rgZ2t/
TIjNwoob2z4/qfhzDWRiydX9VDp0a+EYRgCI2tpFgsrElttU7oEvz5I7l7lgok9URM5O1Gsd
vhphg6TphyLODi1mvp3fvxiq9QEWPiXNPU75/rVsJObpdypAO1iE75nJn2HGP1fOQsxjZ1il
as20beK0hAWNh2p8ly0mrvaDNfuSUraxANAw9TSav4DGfmZNmLP3mNVV0r3Kv9CHi8FuOV4e
zwIunhrBhWcFbutwBBbBBboHkKBaXcaPTVinsLpZiS+TroN7/+5Y3wLhhaiCRGI44no+ylRl
8ydWCNu896D+ogVWIkmgwsguirLNFB/9QFlyFxWvyRgI8nh1PAphvpsOaZVN8ObETXdCnfq2
m5okMq5HWYY7790Y0IhrZYsRACTbJRjDr5onWor3YKVwuJd3natc6lXuTMHusD44lJ7YrRm7
04Z6bCfI0O7Y0MJFtiBP7qZJ3GpMKFXQnGF3RJ2do+CI9aao4wHdfEfXO7mm7TXf36H9pVuJ
4bly+ZkDQrk0PK93V3oq2CZcv74o59mrPoEgCUm4Vxqs1LZ3lP5mB+giwtbeL5Ew7f1DtKWR
23yNr0EBdavSJDV7ZryGao9sfOsysaCqvL3SbXVN1anroJYNqE9x7mrVymE059vWNe+sb6zQ
Q5lhc+/KkCWWkpGbuNlgxyOjzyFOQlfd39R8ZTdA6TxMqpNur1I9IlOkShkv7oH1gTYyYkka
I5IPjhy5UsvqXi5c0O0SGmIi3LiECVQudp3KnOY+LEMt+xXzMXHFjIfFagNniOWuIHnKfQiX
ta1HE8GWx3aa4WYYdlAMA5g1ANRUOMJki33i1ryYTgkzzV64rwf1JMV1fsYzr7FrTw+O8mq+
mCMrR1+g2XVOYHMXboAL+wmRCUelePzP01/8674Wjbd3Cq9kt901+TW5kpfTvTNE8kAkG52K
7EKwxMRY0VAsCZBv+y9wcDOfKCy+ke0j5LAZVJ/A9tkxt9kFz7C58tXZTw0DVNFDSnw8AwB9
/Xo6GFaMesBIYvG2jdmZoNtEoh7nwfZRR5Gnk+MoQDIvhkYpr3dYWHeOrhJnN3zJu0Zh0le3
yfdvPJm48hrJxy9g0+B8p1rAEaTBrfQmC98yZUAhNAk4zXn5Dt/ipwWRYPl9Akc0EkigyB6e
TNee8IrARFuBugGV3Ae1OePHgvQbLzwGWqFlaORpoOwOMX2hkA3u4EK0L8xoJry3IxNYm6nf
9x+4pRZBGx0SosYjRXcBe8LETyPXpERa7+9P8lYX3abrkIeGaxm1bJZHfPC6UriBhFyvK9/G
N4ca2hBK7DseANLenxGoaIcHLopSyK42lUyzJK2BK1X65OxBbwaYbjKk76BRJHYrjcuMnUEd
J00rgM9HxJWSG66003Lyd7W3jLnUyp7wPLGg4Zs0M8MRQfWysUctpOXVfcrWiqtNf/RZKqwJ
0D1T4fgdNYmdgG1Z3CiBO7VMUkVWQ+2vBDrGi33NtKG7BB6XdIq2640145rMejwaGEs+1X1C
WW09dyV5EnWkr/QlPy/CIVkDBLlFlBdWNVqEWDnp1swAkLerUUBrAPko1u263hdVf5uD7uSy
EsTiMCmcjTUgp23wUCMquJEXo2QlCTP/V7J5flU/qdmzPIUhha6FfJj56axKXPmExHNG4xNS
rxJjEnS2uGcdGvOajSI8+EMbuqkcxvFVDstRxGJgLbEM2Jgm4RdziPLGXiThc5+khdo+1VUF
4mvfSPUNqZ54w3VWmkClvwx9DKSxu5uSwCbkOpMnprgHseEPBGzqnV6Bn5s++P43b10TqT4e
YIyBPIQXbWDfDXqTneuZG+AX5wA4qkIzBeV/frns0Zmjiw/vA68MLGzwT7ZTk7E1UQe0VmtB
mRr3jENAbCudKzQPVZIRAzV4qlRA+Vubwp6xk5k1m2Ht2vysqJcX1JVlewscVIgBkGAoEcCX
iu8JMf0nVY8dWjzIKHSz+B/vZFu+xkwhqE3v6EUTBP+EenPWVZ7F16I/ITDM62/1znoKqOCx
KcH8JP+EikP9iT83p1pJoFDui9DNA0K9VSD1ZMqRHgpIB+9JKDn7iaNAhxa+bAglTXyrS62c
kYPHVeBZFgiFbnM4Hwez+pSmQcjCRLKr4fPQ2DaQNjnOOkOJVAPFKxAaH9qPwH5uzTzQ/dNV
4U1WNofwM8SwY++bqDx9heKX5bJvIWkoHYfSrodZscfIQWlrdDc6NtyOzgA2g1sXrPTT2Eb1
rnWrDHXU+EVf/Bj8f6CGdMx6Zwv2pOTAo8ek1rPV2710Jcg116/1gzNyFKgGyvDgebm4QZgC
sKihfVOnC0KE4AuBWDt8gyWtL86dfJgnfji1yRdYivULRENAFNgUb7WBMubJVqDJe4h9uRTQ
fvEVO2oCrM4FvowE6IJaoN6QEKaCMt5rxQAJxQGp0PA0H4zby/l9fAq/1ycgHoOOazy/GEEc
pp8f8N8+5NMEneNWL91XtXDqDRrLKvM0U+JeLbe8Tfhcr4WdCjwv9yU+kBLAUpCQBqSKd5OT
SBsxhLIjiUr9SpFLrdr112lzepAZPueMeCnghgQH0Z81qnsXRVgfno4JtoFAEjGs99Oto5Hq
BFt0t6EUeO5SF1/rym/UV/i4ppN6rG3IaBG4yXJZBAM2MxldkdGBcsLaSGOu8ILUFu2DETja
uCHCi8sSae5yxY3N/zuiOD0Tib+RQElzSMFfCx7n0eOjUDwb+pe4kHnCAyNN+O+PNFW4akPX
iJ7xnqve/aTO5K1fp8xx1mCvoO2lW8JeefH1A98gWL+xww2XAupaT2ysIGnxnDATgIeeinOk
1xCP0x3Z7vG4NVmsVYP8ZYRIuUXHsl/cnSYh3bjBkcywSavVuBuLAbBOouBrIlIRbajSaVWc
1I1Gepsilj221hbYvffgffCAgLAR+ZV45o7sGYWoqgApETTUlVIa3dKFA/S3TAvYyzBmoYVK
mYMz1hhYlI9P3QgWkO02yIlUaFzPuaEXZV/SLFK4ajiows2eMahOpDWYQhHYddICJY4LXpbT
xpPDYcnvC+2lEttdTwcfRPsHuYkLztixYf/8WHpFxxbm+tnOkVzAVzMbcetIlTj4pb8xjdVI
l8xzqTrBbu+x55a41MhcSbFRF77DfARkNyD3pmAYie6Wk2mx6yfZ+VZEbY2vsFGHZDt0Mvv1
bKHVP7+/Z550/3QnPLk+tQ/wEumMVZ2L7FYQPMrFvumoPiqlRInwhfAoraEqrKqqtQzhIdYL
JS8x6dNIQY0JOFcjgKNu41bnQXlXlDVwBL1GBeWjEQ7784JLgYMkb/XVdu937RCoa121p+y6
TonP1YD+hMyQo8bn7c8fF17JtIyd6uDQDCTr1iYwOajiGFgl3Fg9fIzo7gI0eopR+E7Zr3n4
Pjbw1NtfaY6Ksj0y6JZ79OWWRGuB/eIAVJK+6MidKWZ0j/3M/PaNgWzlqbsKMV5I6yJNlRFN
UuP+DSYGnyya/bCTEVyyt15Tfj+w+VE1WaiqP7vnLocrPPMPYI5aql4t02n5M4pg3vN5QLFI
ECAF7isHB0pKIMcSVdhDD5fPfE+EhDnFriVaMXU4BVNAQwV10+9U0DOfQHkh5EQq+a7l5MpS
dQJy1UxM0PuE6DM6Zf3OtSnV4rqyNlbUSzPH1F02ZGWZY6/w1O9RgpsE/g3DwnULJObLW45m
j/gLTHGymlv2oXbiWOJTHPCksJ4bdbzPO6eSBqZweBm+PFcHlH89+atZA4TMOIWb1aCXYvjP
hee4RbsOSMuJOaervTqGda/xke2e90ekgFCxhbwIzd4KUEJQpObAxb6BDw44beYpvuRQD10r
Z6Pk/xV/pn78NtMgAvVqMzltnin0GkpfFqKci6H5iqFxGzszKC9dnS/eidGn0TUYnXlKXlmM
nl2UNHGsLGdYyT6/dmyPkv/owKGSw3hq87ejQQNVtZl8whk6jegAjj6r3DS/S3qYc4gqoG/f
scEN4JZxw90lB0wHuyYx1WyvpYj6XLbr5qvf34/8dKwJlb/YcwVc5kATOno4Z0ybLNdGIvlt
pUhtG5sAGWr4JIe25Tj6BnMQcnPXZgdO3wPWgI4WPGwNQAD3RU1qg1Osz7dm5YdjqlTZKcTh
ynjC2z8cKBqOxC3LnCrS8D0Ah1ke37gtbddOU5tutQnZGRRMX4VkjLw5F+pH8bfxFssY832p
ma154LqeojD64Icl1Cu511em5YeaIpq+GtyJRZ9fB4AHHDD9hWsJx48IYx7J9QEd6hnjsNXQ
4uqkqT6bZoJYFvFKfciRB1amPzAUDzkFWU3DvIVwp0n9xd6D5XS00v/z0fVuB6Wq47NOgqjt
vvnU3lbS8nhlTYIF/5EGmIkyOCVzRGaH5J7Q3RMi5Oex/ak73mIXOOPqed/ST6HtbkmOuZtI
uOzVRmScsO9tkz/2eyNsaGvb5dUMJWKqTL4cCqXZasakelPeLaRO2k0haCKwzNmw0ko19dZS
3Ss9BMePSy56jQQmh76TfmXN75npfueWz0eFZDfbsMRM+GPbumCzJHyx+0rO460Rid3Jhm0L
UnliW7ueZzW1mImGoe01dZdXC1ss/w7exIQEIJ4iBOBz1YFKGGmfMq2FcADwuyDbArQYXO0W
HuQ/nrIzwgX9fDPI4d+jkABl5MBZaswj3i+OQK2K8yiBCXO+5XLrDarI+DBocMXx/dLPJ0KU
/L5e16hJTqwz8ao4pTRmRFRwJO8Qy9knXPfkeuXik4AVNPS7nYPGzx2OFZ4u2O6cGc4n2HzP
CZqa5VURCiJ/SHRcd9L0hdlXkEx43dvvbyVpYgH4f7N9wkkP2UXCg1LmPQoB49vr75ZHsbA7
1JYMMfM4A8flvfagsC0dBGEuvoiZK76GYy2aMj6BVVF/fBvDSW2HqZlydTdQP0jpmZlGAvTL
KlnLZgp5SDzgo+MW/ukch6+61EAjSu+0zAY/Infa2x1gV2U51kh+5Amg+jHIB1aDycJu5ydb
cms7ViKm9LIyIeEpJKbZOR5vvhuczgwncreV5HO+tSvC107Q539O6UEtMItFU94DEBMyC2U0
E/U9gD6QO9D59Cxx+cyc5yNNWIwZzHqTnnL6SMnAh4+vlNUOmUzrGvy+ymU5BJ6zUbmHgJr7
c6UU9l9T39khmsZcO7Lj5lZfvqzrBDGGJ6m5/s+kdq01tzJ9XthNE5ZUGJkHonBNAlf3a24J
s0PVwYrPKUiVgvOQu9FS4Ye/FeWDGjaX7KNxzf42MhiVQ4wFLDPyzW66Rs/fd1bPsGNtlqvV
XSTNlVfRa2ZaGYcPYU958YzNQpZ/TS2L0YS7/LfWa6UzD4DQr/3DDgvPPfTAvv+frifm+wE3
VmgcqA4NgeZcd6uc2jyZhRg2UCjayalrChQY31dWBjplQ+/+39UTBqOk2UL3HF5q9TqCD1xg
RWByNh0iiVgyGD63nTkEhDO/xMga48dgHRLQLX/8Cqwfq6kJe3bdtCBRBrITUtnwflybHFtr
4QZNWVkERprdEIWdWt9Z/9OnuIOFTZDKoENSJI/4xFUpTuM1avgKALAkKui6PJG31LlIfmpQ
m9mgIwoiF50kB+15LxPjl3xCX9iSzfYgI4kXbclQmoNEtRRulXpIqF69dnKKkAKQR8I2TfGe
wk2Z18cPSaqHce4fXkn8UombYFKpwfnXCS60b2Zexd8zLvJe+SdvGlgndS2RJTKZ15kiyblz
grTScVAjNUIUfsVvjTdKRz8lS+QwhuZtiquek1pJT3vIJJJlivpAKG3yXCyn4re80XN015bB
YO7VtekZxs8V3cLcrN0XenU9oqeR8PfjZH+1+aDWrC288zFMKU2Io3kEGWoLkZUDt0j1hH61
cWn8skWjmjQbCfyoF0wUkoej0lyRvy/M2+794AFsd4XmSjA6PyMXAhpfwmpvU2vhDX+Ho6sV
BTRixZCS+x+0La9rcNm44oD+wEJCJIYfoo/viQP/f18BECYAimHr+lq7ubsI6yKQE6C17lp3
IDRX2TiIyLMxMw3qUTGsFLPpxuzzo8cgP7QmPXBtN19Gh/NCVXcs0L65fYHOl7pySNi1Q0yR
e8Te6zLPjI+L4jHthGsIC7nYFTJxx1LI/i1cQFLTnMKDqrChs2Q9NS0E7wOG67RCAcVFo4Wo
0OzR5xu7xHc4B5hCWjPZ7Ogy0vfLw87bZYI92cakuTHywct3Rkh83/bPXWgpbErngAIq1JO2
XpYP6Hl7CY9Od4dgBUxYhmEDR+2q4u0NoGf77WeyW1orpQC0LnDmr7q3ZDlfiM1rM1yMgBjL
PvXTBrFYymIeZpPsn/RpnnkS4hilzQWvatrjolLK6gvYo/yKox/J3qpVGGFjtCXD9lFNYZZx
t+s5xjaqbdK60Ouq4nDMhoSDEeoja1x8AJq3+XLzHXitjj3sxPwEF/af1aZLBOYKF8MBnmLv
BX6NhPShwfg8D3ewHjNMiOn8wMLTFQxBbXJDKe1SnPNiK5PihH8tRoeyS3nty/4UNeQHPBrd
A4yQUwUj0rAW4U5Ynw0DfgMuVgwBOS57HCq9PMDzJGbcAPpEC05O9XRRpjQYiU1y+rOV2rGn
tb32gmmsuFF7r8wbQZGafardKs35/Vp2sXZmfi9Whm+gUwO3pe4SMqnBaU8pVeyhygy0zIdm
NzJuTVzKHIMewgyIO6MPKnc82ArEhwfsLckpExp/fFh4klEPmyWy4ieI35ku37uL9H1QSQpX
9PVU67SwWnJqhCQpLESZkspTVZQKs0c8WImOgiJv9Hj7HtuUzXKQlZr/dBDV2q5uDNuH5RZ+
cgSBKw7hMo8KikJfLGO0rUmdcTXAtqGzCndV48INyXmU9WSv4Poe1AIflxRsR9MZBJDHvW8E
XYexZDzouXmJM3PJm7OxehvbaZgoKXJ3oPS6ybpOpV+VIGbwqrCOB3zHhWgaNbGBBIrQ4UMK
1mPkKIfPMEWHNl6RArVKZclt+1UVHtB8xSLahTro0c7LEKvLoDstae6gpceUYO4HGa2Kl+mS
uV0YQxNtrGztNO8lIGjw7xPG/1frm/Ie0PJpHeYfF8K6QUUVUAZwIL/ivjBrlUp+rH60lgPL
I3VsGevj7N8JillP58VugFi9CtkCLolgKZmy10jArOlY6WaPpG4sGgL51wr2f6SaI5LmLiGj
QLRPCGzid/KnX92oXp7wV1rPrhi9IpOZ4d2v1GHljEHcbgoeuAqdvscHWeqXf/5ifA5hKNxt
zFyZLSi2Pph/bZ+TZxjd6Zdl+LlYOWzXXxSFwhlY/WQZF24akb4TyS1bp7WQiXRItXixSHuW
otHG2l67xEbJ8AoPZpAEgU29A99/thybATK4w96nysdwuHJQr2bOLiBy0mwzxY70Njg0dUyS
TUI8Sd5oPsuiQoSGYkTJO5kGfKltUHGLATM30+fVmhlOAfSLtZN4cNFaIA/XmynOOzp0CQsk
+v1E+vpGTeNSfS6n2nlaM0VagqDR3vcrZOo8CunSQQ6L1NM93BoIazW1rFv+EL5qVdJJRcUL
4f2sCpERmvO4SD/FdFBddfRzHPy4VOvwfzrjEd8t2vacki//OnlOBKGGp/mfAodUWK/BdoFI
PW4blBWFZN0VFcnMUSk6jAtGl4TddArG72UNyoZOgBKSKslTelUSUugXuw0MJf26vyt5aEv1
DRPFMsQgSdZJl2CsP1lS/5ZsTKiS7+aQi+Y1nxNVxntaYJwajYPdlbfEYSz0ImTuso7zq6Pr
1nu3IChkuCffKafaAAkDG3U2qkrly+VhrsudAOXjUqqe3acYYJ9KD9kXbfj0ymylU1BiiyOP
+Ud4b7k855Bxb3O9XT9kKFHzezlQEhdPBpj56ZoeW0X+1u20oHMdoTBycQosz+lybGXD/3of
n1VE5VYt3ub86xDz2LK+2wzGSXwxmqEjt4NIDXnjGa0nQWS30lm/52DLs3rE7HPb9XmjwbNd
XAkXF33uYze1fn7J+kYOewNvmLof3S/fd/7UR/LXwquo6VtG6yJgDRUDjiq5VBaAC0Sb2WBK
XPyhwHiisd3uqMvBjBIM7YBnwePLvn7Qu7YmZHc0LVqNWXc03OMAkIJCyFWiyzMOApLYzDAf
6SFOgceHaJRs3UKJwWd0eyMMOCHzDzW4S2PQ6YLEXxk5eRl/vyerrX6DjI/m1d0VPBI5YG/9
URB5AqS5r/4KCDjpcPUm1SPxJvinC0V7Tm3+1OXLh1pbHp7LmjqmHOzIhie/DPS9oCwW3s94
3yCblM+/Uj4LTyS20euHso/uHOfcdmrX9Y9o7Vyyz5zzDv4I/OJdxGRbDQ/4UGLXJRqsA1T3
wF5N9qjcwjJqtOCk95edVm9nvJMjzESF2ZMz6Bivzs9aOrSCT+k9yvmDLjSPI4/ftfLRIJ4D
0Ps8AhkvQi6JsFRaDlNFmV+dd6qDQ6QyBUal2xmNh3gb1iyAvshLtQjUvtJD1IRtAI6qrM8L
LBDpan/JEX0i0cUmoeX2zdPNajOavrWsC63lt8DTsqmoiTBEIFmRXsHX7sV7F5y29mlMeufx
ldDfS6LQD3Mc0jSrRwpH/d4qL8AzL9sTu0bsQA/RK5bxoQfiqjkOgOdTEu/s2AL4wuj7KNBU
s+GLKUic9bPzYOT5eoJXeM69i2hSG03ef+W0vkGMU1e6jety5j6gux4aVRCvGFZgSqPFYAOB
juWLua5j/T7lekZvzTU/cG2GJNgvSRPBhYicDgO5dLYobrre1bD5BhqaPzf01zF/x3Kidta5
FIYzkpd1VwGTiBsUFI+UOtzCnPNHLgGkPUJjj5NWSDKe2gq6KutjCLz9lwWTGb4+7pnPWSts
2i+ou5LyJfbyiC7TlCKY7jfpcK3djU7kmEHnQJ8ld/3g0oSfedQz+gaMMr0iXOm/suylcEfO
8O9vtwCRo7+d0bhdFkN07sWa2DZ7fAsh1jcWJPvgWzTshSuDF3+oW0c6GCcyAky5bP0YHVIK
kaN2Z+3ydmCUoJ7AuMJPNkNm84AGoHlORxatrwZGu16BURtP3guV8mFDMZI+JYKw2K0kRuUP
yvQ4mtQJMwut97MJ0drm3uuUc3+Wnbc0KEh3bTOl4HXCXmzP54CtRqA/OREFgR48ysFJYJGW
N8OGVm/KHryaWVeFoKuJqY+Rr600Q3lEoNA9Q42sjNE3IjiRJTqVjaP058hwsZUbOeis2Ukq
PmvVzQ0p89ZNVRBZF69HOf072BcVGS8il4XpYN28ZtMMaCpjvrzUg7fxJpCLnQZntO/2bSyX
bHBttPPXZtD4/BJmqyFIsBu1aHxo6X9ep72ldcsNDe31B5gt9GXCSYIR8HrT/xz8vtJoZSAa
Fe9muSR5tKSWPc/sEDhpvtXJUAvHDhKbKy9OcKCxaPDJxkcKvWjtnnEXdYafwxtoFpRVcTFM
oeG3LhpRFEmWdsnsLOK6o5J35KZRJm7ypZNPuFq1VfI/wgf2rcFsVUa3TQrHg1nV9k78PMig
6wMehPIOawrozTGzuUzprylLuGRHLshM0VBbcYcIUBO/YEram73N2XnyqOi2EVNFHCoqygLn
YMjtbSGv5Fcm2COuXppYKuyj5zqY2KBtkAyj/VDdjV5OYlV25TYa3zgfUgt8jWMaBk9gopCU
bbz8Pww61JTtu5u7Jg1YBo4oKgg8lgjNEPEvpp8Rm4JN9WXY63tnFAQjvwN71ZEGsML8ZHSn
S9ApxbYa4gihVv2Go7EvZq0JHiFpIPxD2eRHgdgR/oa2GA+149/5YJrSgoI16s7UUYPea+RY
87mI5K5KzFRAKR+EFQKetPgBRVyoLU5Af8Zw1D25PKr/6Ap6wvaeA4kLa5rHMx3maFw3gWLI
Iijvtdp5rtyvb9IRhjq+8iVim3U5Gjv7BptwMJZnCFPXkwWAItiUxQGjHd12h7PVCkYB/I0f
9390Zh9kmhKozzGWdQu/tR3KKDNdTcr8iPB6VO/VVqZZXbRr7T7dG4xe48WzMgjhCJT0SNld
9xltzvFD1ngPVK90AkSgkqA0VhmtcOhEXAcvzsHC9DGTy4VnUcEiXG5K4nAtepvvC8uaCbcR
3FLOpELgirosU9pc/PR/siirxo/pnG1F0UG37iUHm5qqRHbg7oh8RlOHyjnP70gsYnlxd0fh
maTkBL9LLdJM7To0/93e1MMayp+zSgBFDL5rGSs824Ypo5jppIBKWtA/67sjYXzWG/04LvNf
wxVIDtQKWKuxqHbmoSMbzMtqLTbeCjOpLAUtg5BEEfUeHLuUOdDk2PZ+FWN6V2CrWFf8+8pS
pJB7VVDJ9+LQkFxPwkuwDlDvVLLckv2lH5Dvk7eaorxbAmIuEe4Z8oowZZAcYAentbK1moj7
n9WKD8DlCr44x+yXiqf7Rx7McXnWH0EtQ0c2yPZHxoWFvyAsVGFDxCfjo2c1oGJtvuivlfaD
lsHPAlknrPzir/TKiZVMcQ5B7mh02m5VwwMboE9/WZvejq+xoa6ksgmWgrju1aRXtICOejzm
dY3ZJuXmX1v5p4N3yR2vrO/KRJuEa9hEd/UWDhHXvCWp+DFst0/9zCMtqWRw1xXu9NV4w2qY
hAZyD/EL+oBAqeM5Ahd4W1clapeJiM7FYgzHSJwbZg4YIC/tiegeAeGqAc4S6TouJvm/RUN3
3xB/4k1zqrYwi/C+G7aQhJLaSeQvJzFjzhhll0IRfeJUY7U1d2sBf3GosrPAFAuV4+facpSB
pTMrwsX9PsSGIxC4gzDe2TgjyYpHrVZN7I6zsmOSskHMbV20V8Ah8PFf7g6tAi/ZzWLXMI1V
gxNSTD2KLyAL80WTNeJvUnNVjTTzE56MDdwBpFdUpPXUdzTh9k2UBtt3N1N0MLxVzNE2Rhjc
Fq4hX8JXgbVC30LxW9HrH9OE3TSXuTGKDdlcaWyuYo7QPkg0Bo+TCSTI+NtoyJa9ADD70Tzf
8eIRyiDH02hEeqiWYWFwWMZy5icBUPrwSJi7npDjlJeco0CYn7Lpb6zb0r47nVfkzE9LqnTb
bLUNkhs3o6NswYXfLmvYXCHT5sRpNFqkeosT97H7nAnaLMfpzZt6+DRnnCpEPtdEbqmQw9Qv
YS+Qw63/5wbGMM+AHZvLPiQqJVood1fci6qxR19oFVBUnMZrzJlBBqEDqJ3DIPzjelNyIZce
FOEj+Nf/kf3qOlHNe+3LQgnDYT2ByiBbFQMx0fEspNUqRz8sen1hWJ7r/F/8OL4ep0a0LakE
+aU9zx7W0rtF3u0+Ck6welnNCtL7WpeEzPZgKxG3A2FbPlYfP7UD2X4a6WHcBdUMUy/VpXBW
EDsn2xx5o27TLg6Rt8xz8V99oLGOiLspJaau2Pjc7PR2m366IxWyzIEf/2aD2A8okBN/JYCN
blJrs5AG2FlJlgTUbeJZvyAQzU3OK3NPitFowVi2/1OAUN162IhY2lqUL2zmMND+m/H0KTup
bgY07PHy9fiu4dHn5UmoDddkBmMycylxhiBSzxrLn3k2ctaR06f59reHgjINki4zHsnhhcla
X+HAgQ8UaFFCgNA03BUisfzI/TwI7YeqsiAvD2xDwJv89V2tYlFwbh/a1lTCKbG2QoO/WFZ+
aIheilXmNQUMD8ateS+tY/KBXU67spoJJp0/76P3XBgsiGlcoV2qzFGogxzjeJzHGbRt44yM
Py0RgqzDuHScLQdY2MzgsbxPOgx2LyQg9HztjP18L7t6GDIaUTHv4TPqifiXl2xHe3Fs5tXt
mGiyUuT23pnd/aLhSHRlbOH1qZPPIeLicrt66MLBbk/c1MhUGTZyC4ZJSTC9xAu7IyshA3O1
y0C+H/leTd33shqZ0tuM0MUKW8mXD0lpeyAw/buxOIfehAMYBO/WZcSXVJsftya0iNzOL70Y
TTeVajBhWaoFlbfD6h+WzPDP1hBPlr5U1vZBjlxxBhg+G91AjOHdPSwGIl5xzqtlV4+dNf7J
mtaTEQ8t1G16A+TPEbFO2wGPfkOHh/bTLQR02N1uJlglNQN7AFb9ZItyzBeSLUQhu2tm0hn+
P/b5+8IVxKMKdSEG0N2y6QU3xUMz5MYq3wEjJoHC+9yumXUmNFbfZ9LZkw7PI6x+YpSI90Iv
+B1qgod3Mf2kzATbqrp34H/fpB6m13aa2Gq662cu4wt6afiJtn3kAoZVDQQc6dd+n0euL/iK
CfNQMzYoKnLvf2cY8J5wsOnmYHriGzyCXs+GB9bYBlImfpAePWwSfpGCPMSVG9qqvdGgi5Mi
CngKq86SdDtr92YU9TSNXcSVmutJ2AdnFur78dhyvXbopDCVgqIN+4ihz5/HgiXbZNMhgoBp
soL/owas6Jt8Ws5BOCRLUpMCddC5lID8e9I93PL303C4X29uGTwjQQrrNswOqTwoXLLzBNzC
vidZTDa34pCEXCJW6HejZnV16lLDI9aMX5uKnX18/loC+KMlH5rGYspsI5Yf1N5zgT9SVe/d
04yFyrG628LpnCmhDH/2KULgDBe7XBe05V584ok0KN0nQplX4g4FF+47Jdmimk8jO0IqKqzn
gpir/xqhA5fB/ZAB3tyKwooVeAsWDaJzds7+ycJGvhtrLCttUeiVppyJGyQh22WrG3j6TeiV
oOYuaUcGxO1rzLvCX72K4Lvp05q7fNDTNguv+FRSXkSrArbdeB0ph+T1xOYkt3dD5CLFXiik
tZdIrOoIDaBEvXhkioDL2MsbzQ6S0ZzFihCT8zJwuQUbQF6Jvh3/zbDGLonpSYbUYAlAZdc5
pudB1b3KyKeN2W3c/GHN99dOKlgssX2q9FJX1l74xDHeurZ4dM1cC6+LMENCLk6i0L+dv8Gn
De78UWqioKD48nZ5fL4lkZC/XtrBHaQcAxswilspf9Zx5IcSWB29yWfJ/DXmxYNUxw05rCkI
irfBOaurhYFH4SZNUIFpnm2o4Ao6K31ihu1G/NBAU/H1Y1pbxlP8cu3betW2GNUCPZKIDcEW
ij///RzbqgXKW/2jMs6fnzV5a7Aav82+jrk8x8vXYsT43SFKc2Jk0SC0YN5VLU12B1jGQlzD
BcVhd/ZeN1/YuFM9exxyLNhLFFk2LoMv5x6ondqoEtGr9/V6Rmf1Df2L3spE/HJqZh/EmMqq
HBIzFl7GqF53Yuj+JFJzBnScEJRR/+tEsUls8UzfjwaHXmU24udPV+ce0qjkjANaCGkuvtVd
uts1VtSMSLSoKQlGGQy7fcBIvoOeRCgx3eBJQ0BnMxcRyqnjJL6cb/ChvjYuKNEzbUQdTzYa
uPNQrNa27nsycudjfMTbLA9efv6yXcCfVioAbdcvcKIN5KHW5DdKvi6Y8qiyb40yXDDsyp2U
29oBnkExwukxQxNcLz8r+nSgRezKzt2yqSxgdH77mv8LujlHFhh3EWqd0u5hYkEiT3zT5CVG
b5egsHeYzx5jewUkleJDWDZ0R594s5ReeCnS97oz73PoPGeDWtpO4gSK86x7WwcupOWOS953
cgdEG1tbCWHwnRMX80ytxq+cbqscS1tDZjf5Tmi67b8Lndi7MJaAJJXfHobacv8kLN0sbz+v
8Rg/9JLWt2pIc8iorcn05vhgFTOokb6aKNQ33LnZVICqAdHkWh+pSyiu4dtyTsZxoKtoWBGK
sso6QCYaiGsB7Z2/rNaLD5Ng9CCXw84jMAAbpekLgKxiNVlIy28msCmqphPTHiAPMnaVP50F
8AzdAGNRsZufl4mXbK86Lcase00qC0np0h7CRWSAVyMX6a2YswXEoYhNpgV6iKaiUC95PMXT
W/YU/h3EOuy2AXfSr1f21w/QH/e5oIA40amjhlBmqcWNjhm+kx4zplpOV7HLoQuLexs+GKGB
Mkx6tpR/Hi1CgRUd4ZZqsaD28ZW7YKcxayCDqMUvXAZOxOfMhmXz0CxVjZn5qWvZEtTtB1t0
+q7lBSlK3H+Opb+780cNKBRm4DxgLm5iAMWXj7qpLZccDvljiOdHHXK1mpy2i08fOM56m8nO
MG3XaZo1rhfIdVywF7fZYRAapZgc8pqfAPqLKIRr2wMn+8N7OOMRSrkgifP5ZOsAEN87ez6K
PygSyQxivtP0XanWML9SfBd8ZQkSmtaMI8k+q6hyfQ7u1e8O1kzsEFPzvISBIi+4kGSrTfIl
tcskKJJRSfUvJ6udyvHZbDliLr7FxzK3pPAWdWQOlDLIlrWAIrvwkXB9Ckt0C3PrmDRYTnYE
2Yh2BKMK5nOmXzwIoneClCe9+0SCubiR4QoO3O/zqWKgHBpHGLMHUgmb8xcOiuIDLDVsAuV7
E7CdjCHgcwPTL5TC7W/JvUI1u3sYmZbCwRMXjxAQlRgZx8jx1/V4sWRZ4OcjpH6VIKf90GbJ
lq/X/Z8WVx4jlL6McVkSteV9B5ads1ErwG69C1MonTqZXv3+sw7adWdzcDdtI1/ApdBhKjMs
bhOg928R2NnqjB756z9vjCV7QBGlFhuOTzyFDuUe7+Qbk/iiJG0V93M08PSlajcDRZmddej5
6wqFkOjgjjtGnQGQUYr8MB/6PcdQNuapLw7Q+gR4MS4a/J+27c8bkXnz9IBPYzmhj/uqDLrs
NnbB1qt5tIwT7Lvh5Bomr0TLbfjP/abjA7yD7jo+cZqID3gcdx/dxb1l22VTqQ7pdXhjRKbS
zYThB4Z56Or2ritITc2nMKCf6reRsRt7U2oe2hy2lKY4Z/uw1Wg1DkPPQf83GNnJIa/oRaXb
OZyBSJNMCQAfb5kl90zIXartQVPhUZt48geoRlfwYq683fHO5KqGLKXSxH1U4t8suZXua9H4
09sOF8amKhOTl8RAphaPxhT6LpLNnzrlLFLG8Iv2UboyiD8BWxIFcvafOkbAGNXV+OxKtct9
5nAu88XbDXnrxLk2I7I5oNbbHRfWHTdruhkurPPoGg2fSm/FS+qPMD5LYeZemRp/cw2XU1rB
vOkZ8vhAMJFnty1QaKHxYweQdO6tqWgo/4YzbENpjz11pJB/KznuJULoLhysU8b9kfqDYiMU
aQOfkQ9xZoxSkKq/QR+KCaeXjSoQNOpveLSYR3v4YA7wGbSOtdAJgajHZAGvcdZpvy43prOM
BzuArc9jK9gv6xetu5PHZWFMTuu3EyOafoS0xSUlCem4fj6pIjbeLVOWTt/T46yaFbdw++dY
3nCvxtUX1n5YsD/7UvLCM9/kZkPwJzUBq7KlhHDKx3nhencFif0myj1qqsaA4aKqOLrhCrDY
hpZJ79C/efacSTQ9Ea9hQPiHnWXRjMlv5/ad//O4L8neroHaj4q23QefdS3gkyMWqdmk5zjp
o1CaGGuLm9iX59qUkxzBeAHiTffP4mhL9xoIG+k/j9KAcqKDR3Rmm+yh1liTOMIJSTTZhb+r
2cS8UIutxUx5nS/+vmEYFtXyur5Yo9lZRKqPDnkdX3w3TBnn0Fwo4KLMzMW6A9ZH6tT8b1nH
HoKSJcBVbjJB2uqxxyGGDRbYrG4Df8ngZU2huEbUnQHGs6viBDnQJr6C1Q4GAyDxc1SeWYFg
n30o6uU/1Vb08iYopXRS+5hI7aC9t5axftk+AyNGG8UzhSp5qoSRi8JVuqhU02PgsMFAUmDc
ssB3M6CUKVRDERm75p8c47wZTd1krN3JnUEBRUI6K1zYXTIGIHGzEbbdv1aOXaYggujG4mv9
fxEuDTT0B7/sXF+x4e8ss0WPr5DxFxVNs3dKwqxH0NFS+xfGwdKRX4lSDTVlwiwh2gx0v+Tp
OmRuVBfNuNV/U7qThrmL4M2/JWS1QlBmisWC5pLWjJVPauZXz0JSOn4yRiTNuLIIocBE98bl
55KhjIxvXquhi4mqlW3mDdadPCAKQHtIPHe2iEPKlLQTmfzUqrzA8qligEzv/Wby7peZ1cRC
rAFh4zf1XEhsUxsFdbkl9xAckJq6/cSBXhkqurVkcFCAFtyP/ZnucQG+lisj3lmWbxCM3z3H
1lVDw0f4hM+AIESIoOOEb7ckItG8CnJ8zMvX+/S0Bc3C04c5U6/ruS+5Xe30Nfl2S3Hh+lB2
m2onlJdx3suBIJHJTYA1Bq+P1tJEwvWv3LfHExFnwXbTwAnka9JDob07KNUbidxJcmkCitY4
8u0FKQQAIv5Dv962K6AUL0CEPOBhko6PK6Sp/ggDI/iiWlDWC50/WWE3cf2PXLV6Ba4BujDp
2hC8z9zZw0LKV3fYvGph57D/cHjmzDSiOnKDhlc05vvkE9obKPT3b5x34WhgSV1z7fYzxmvo
tVW4qcnG2uBrSX/kW0A239/Q6Ef3IE25yx0dctb3vrTGyVByKxRwZTjGB/DIYnopISo01ndp
jRNJ5o42nrp1hhTGtM0ubFN4bUbjFxu+MfCv6U5jeICTR7YL3W+pyRgJ7uMFZFOpx8jIfmSt
qKW5f4ITUk6ucBr0PWfjjpjeA/JbnYWOBopRZil56KCGg1+mam+StzZHybqurAArDEOLy8Gl
CFH78yyTUdNRrkIHw7M4CBaWbaSBJec1aWv+iIj0TIh1Hh/yogQN3vBGmf7bnBZhdZRYxls+
PAYwmyScD/x6itcgAlblUZyoLzyF5FdkTC2vrjiEoPm91jhemYrMQoEkyF+L3CFR7xHFdbRV
IViMyagKGeXlTfnXCw/geWFTMlmyxaNDt0JipBjI15aYZH4yxKwydalzhesEyGwgMFGy7VsT
+D0IdMAiUZ/lx7gxJO9WsjK9kDmRoqFHA51qJ/SS4tNffb37sijsr9R2RDZ7n4nieh4yMCTf
bHyBISmeslqIZD30ohTXc85IbWPTA3vIBRXKhkM+4s0DLJURqX2DZ7HIxvUFGrQZX9wkaPsK
1vCQ6FACK4EY3mIvUb3IpVLuP3F/oLjBhf+UrC0altwmrsOkeW4dR26Z6XqOvKxyRag8EEeD
nwTEboRzurwoBmWGuxxOpMxClTVmb387Jy/eGJjFz/G6/dQlSsqyE6QXlNRbGiinXVwbhZrW
ijz7cxjkjz5fLkMHX8Z6XEpnk6PyDPBmuKaTwpYDrNTklQReK1W1ZP1e1gUO0fHejPSxJGDO
bPQwR17Ud+k7ptYgGJEQkgk1P4fpgTsQOo43kNlbzQ3nW/034NL17APTYQwqxAjKTFHY1xgj
nnvl9lxA3FoQs2MgHsEpInU6kGhkSxe/z/xYJ+lQ6XMQ8/B7fYSnMpY+Mjq3QjQsd8M5xdLF
9r37R9vILHi58pYTmywNsmmtJ19yVVOWZ33cJAsGhNoIzOyingxbTIJz96tz2pb1qQsF7wDc
suBR96sYZ58MuTqOPKqMxU4iPOO0zRhjSrfNZX1bf5WFAr7gNfLXDlk9OVXC0CklBpSvoBHT
+3svaW3iHL0oRALtt/uQdFPorsqOR2eBhok6JpOxtisQd8QzmPgUfB71Z/CVoF0phT7mYcP4
I5EsMv7RIILDcn+Njxzzt38B8/kkAGUrz7WUA7JPaX+/DvRNA9ki+kxp3meOdIBU7VdEIZKV
1v0DrUYKEVUoeLM/EzyNxHqlVPfTtBtzDmh6LVBB/MB4Tq2251SugsbrKNiSAjpP3WuDH4/p
ytqXOeGAzcEn9OZPn0Ukb9El04dRM7Jh0FbDTS9Ld+75y3bimUk8I5r/mumRdqKlVZOy6elc
DtkToGuKsp/repLPiiLEGm+2tYn782DZufF+Lsn8e8UGbrJdQSO2qsRY8AcM/Z8q0TPZCVW2
jUDIxvpv6f10P6fZn67CoYDAn88hXPIEYNm0HBiiXpW9pggW5h9dtbYu0R/fIhxe0O3tS/KY
qmGcYTHM8SBVo3aa6FTPVCPUFTEDKmgygxjNAcov+TNr2KK2kaqbtKaqRRhaDCMTZR6yLk5x
FhHNHaJCC9OymLMZS3XQ9KTeuLTGbRsNSjnXtLXxlI0KS/9tI32pt5fToAcaAwltV0Jy263G
nQzKcfcGH4ex1g2V3PitL1KXEUdxI/nBIQt3zBKhEyGvGQ77391nxUk0wTNHbLFE+o47kSdz
6Opm+weIs5HQeBlCExh7VjuWS5tIOLqIOAcWJsW3r7cSf59Qtp6ScGPM+kP9yRBoSFf1rzbe
xXFe45DFh8M/f4fEGwavUy0PMVzYOiar0TvqYi9f0qEpV+wd5LgqHpx3JxagdWVkfacCsRt1
K4JvpsAW/D41s+mIL0VbvIEGK0V0MA8uzmee1W71WQyeUWolRxU9S1iwIupcEA3HcPkBhPOA
e+1+UFjf+TUw25hIymvcX0dewMKgn9NUmlYh/DTXgyS3UVjy/Ya/TJj+bkZxt3r9j6KZBcEU
cTSKAyARDb1fIAVCiW8zobfU118wMbQa/Aa2kYz9E6n8Uhoc0+YqPkkX9BASsf7OxsAdPASF
9gROEb7or4XBg4G+Om6Fj62mfOe4nfCzXUmd0TJJZKQEztOgzDn2P8oBSB9EHHii28I2A0dY
w7utw3Ji8vvpC6P2tFaI3mCleeQGuH4QQlg6XWthxmIcSCmaC6TfZnWYT7RPWnRCICoKvY81
aUmrGIeJ8kRraiavwpbs6S/KxtNfgB210sX4UIg6GwUAt5P+tUAaig5cms8H8sv6BhnzL8IJ
STredOqrkSTym6a/1qiIL+fsmH+3RMDheah4W1uiNeW/bTr8p3RIAsCYzQVTEq8XkZT9Hv/w
/UazbX+gc2gY5zbCN3EXf31/B9AwtqgwvJGPvCBXd9Vh7+OPQCZE+osEyx2TbRa3mvm338iY
wWzwO48Q+UigSa8B1Aa+K8L17UxFqTvSMaTfo3Ge/ABEBWE+CC7GCQQszAS9QQVxzE7fq8s9
k58KvebaYFxAphltHiRN2jaO/I5qWuUY64PaheIN5mODstncpj6BEibg0bDdUEiU7/RGG5Z0
1Gj8LFifJAXEPLvMFPbLQ3M2TDPBzKpcJcFBJ/c42XXCDF6HepSBXuQSvb1BUvgNc5yzgvlu
EPTuoyYbCSJp+/kl4dxHMoSJqaNeNCYFA9dzA6doIiWhPeAHvtBQjbEl9iSaCsdY4TqUaV3o
Ci3XobwzYqf45FzSFJ62VT3uKYjQx0eZnC5LlCsqDX+CarQY5EUtlJ8cximC/VJISU99gM6x
72WiFjhVcusD/QSPH5LTTTbBaa33AG206uksiDaqsuPv1BhiWT7IijwyvETypvKYfpSdTLkE
UmexOlrQve2hHVb3FZVxLIDynDDZVhhZFwN6Oem9p2F/lt7FIc+cXx2wvZC1p1i2BxEb7cBA
/kA8JZ/3s05lnS/Xhr0GTpFdcxKVcRhRn5JT10xD9YPFVxDxuF/djk+g6pbll+rK2v0x2F3q
FT93CmNhhGZsBjPDzie5ZyQpHw+V/liDyRtS2TBfejvmlMOtHZPk+E0Ghed075+whGJBbot2
XnzjZeiynBF3YbQRuVCF2Q7JzclZFV0lTgIe6IDh3Yrcv1SyIq8m+gfxbQQIUsKWZJI/yx55
DZHEESMhczK6i1FuooXB9lyKhVx4i9ujsVLIa4UdWiOtMrq9yoHRykbYTKmg8luvs+So/A7E
G97n5KJ5bhhMBGfihAOPTGVYVxlAdp1sV/1cZ4aX+QFeRUawwxDSG6ldcxWzldVSXkqVqInh
smzz0vhLwNdTs6d2N6nxBNfjc8PaTwZ8uPNWzG3rzvqdHQWfOUZ1zABpaVX4KOnog9yEevhh
iiutbCjCq9ZfB90RevATvQMKnmPjBsqKECUJoeq45ZCXFUojQmt+lVC7ciO3HqaRJPEHRjR/
KZdit5CsnM6aF81SH1ZE/7NbUXUZROqPhrZFqOF0u4NjAOjCksq1R+Q0TRGhrkMvQdyeSOGj
M2MviHYTwjohxCXa4oIG/OtHKKWL2aY91QLkEFCpAHRL1stuu1ixwkKkzko8O9rwoNthdmLL
zJ7vH4RHrrGKAtPpCB7jkdU+3fPLrm6TCAbQLgS3HPwafcJ+xskU0xUOZJqsPDfn+G3RMntF
zhBqPDW38lXZ4qijbu1Y2yQ25LSAPxT14+Uziba58s04n3kbz1lOrzEmu2OLzQEtzBw8EVpz
Ecm3g3L9VnbLrsfnAAJHHsGu9fXAtjV2d3DOSBkX6FcxlvTI0mwbuPZt5AW5hqBF/yvSx1nl
YA64X/+mgvEvrnwV5MWEziiV9ujExuUiCYDyAmlK2r6B0Zh37jO7gk+pz1HC76vO+bkbvNSb
gsA4HXZLCjsal4Dlel4dpzCjKoZxz4H4XYjCNWrJxzYeOFipgzSE3NjNoLLNzVVNF7ZUrONB
qJbeWaEJ9L08DkE8NGs9SmcrnNLn93FABhNheoMed3YtvY6muLY8/S3sgOA8OcOiTikh/kCR
o1wJwvN/JzqyFGwY0gkHmVbguTNFiS5b+X48NW5PbSvX0v5/MSwFBdCzxhqr5e9Do4KXTZvd
+8uj7jpuE8pcerv3QPvWt7KYzWQ3RP68JPXq/LQmSPxB+Mo3lx6PxN3xwwRDiPZYO17l8/R1
yIu0/S6iaNi2ShlqoC2txR6SXn1nHGX0Wt1ChrzSBTtCR4xZ6LKtIOw5fOWnHFQmSCEHmRFq
Za5Z9tkfuA+1HLCLFsZgkXUt/Zuosr57AucTtD2ynUmySuY9sd7K9jomT6lfbM0DikGM8IBC
iJPqwhuJAcHJb+s2WC/8/Jw3kdkFlg8XuV/r32J/j3DrEKFcs4QaKtN3lzzXyoKaXrvUerzU
1z+YB9byKCmLb154ZRdAMikdzNEvOf8y8QYX+nZcpB1tXoUwa8Z4JUPrgr0di5QOG2QmLFyK
e4o7lOaSdxJxG+G5xYSS53XavP1bVfRA/OJxOJsuq0Qzcn1OGEysDvh/vDjCMgzbY1TXzR9C
CeN0uvEGaeiQxEPVH6zIommTpi0bs71yQqtvTXK3jdGmIR/0LZPxghTWQa1j+3aH8YttUxyn
khfDPaqZhoNoXSqhyVB7WlZK7zKTUY3ug1Hb/0JiyW6PNFGx0syNbizipKLANTObXQWYZGX9
XRO28hKIuKK3Dcybefef3CMFZGpAXjLss4k3L7B1aj9MdwPZyyT77lQqN2QCbKhtla9S+t5c
AKNqft9Ruq5Y9wz0EDGjTFBpk2pOYcErDB8fjrcrN7uYxvv7r96y6obkcB+uZExQn4bqTtGJ
AZ8Q8fSEkVp1Xhnnj2j4vUvnJJS3ssU1evj7b8Rj0OOrahG6UPUEW1lF4S9ezxIsvhnY/qe/
4hO7YM7GUF6uxXhh+xiQtBZD4C1islZ2XqKz6dK9g2WOgYvl+HPpFvGoGUXSfKkg46F+HMbY
rijBSoQ8UUJ5VINdtV6UdRKNbbnqlRRD5XvI5EfPadRjAjPjYwt1fmbRyJzRJC5ZVuRY+bKX
bIOE2SnkvpzLeACRqTig6WkWO+RvxRximkMdqR3Z2j1wXeI/DHh7SOUZL1TFvUqYvSeyjFa1
04PBQS9itONINNljdmIIWyfOpQBd3TGKNPSk4Qc3Krzy7fq4KUVvqsJHid9bfmeh9xDkXpCm
VWhrXmCF4SLvuhEnL1eTM4pqgP/xrMPPeHG1fxWYa0jh7MgHJkqaOuUoniDSRCR++WfTEcNJ
wSNhbMmk8crkCr9ugHNg116xqBUWmk0to4JiYBwda1zMIQUAit3Rr54s+SlGL2hSghQ0BCbo
HP0HF7FczxCfhqMMK1c+laq7suuLIyTlBCxLJY6NwOXYtMQ746wIK6p0n6UIniE0SyqgksdE
Dvpt3ITEzgmaHtnrUookZCAObqvOD8DyrFOLLHk27MBI/V6rOGjQFD7Fb5AO7p+aAdP2roD4
NR/lh9dYBcskuRDXl4F4/PwfVToU5cAbYrXiQP4wZ6b8gSQfYuoz8ID3rnHZ3IrMTHIabLVp
pL72ZsfQAhkO4Fvv/kcxIBfm9ttysszZudn4WPMQH8mfrVoQoH1rLNE4vVl2K0G89IbFXyt9
i5FymLbnqTG9yEgBs4yK29pizZnOqJfEIpz7kW0WgyUxzGZh9VrYwWlfTe8vwERHRh/qLd5U
VPgYY9Hf6OSopyQw4AdsFGgpgm27Uqnny1lbAQjo1rToLvfit3sJvNicXcQlxhSIROm7Uyvx
S/qShavFtFHSJ6ORLhibZMosW7zUaus11b0BN8f+2BFlL1pQk0iwXNGHCkKRYQ43izS+vz4z
+Ubvkw3Jyf5MY49w7DOhtGl59O9Xl4dqlNdz05j18BXn9x+4izv53+EipqEjI8qsT9KscHuP
Nq47KaQKwEqlDJ1q45vK34F0svB10fvxa1Az3MLH/KadC5ZXrYnVezbjDIy5aWQD1Im5Dtbk
1huBzLunAm8JASLShV/TT7Qna4CTTbq36PrVTFfULWkEqARWbIaMxz71X4WDnehC1choNkbD
3kPOOTouxlKAG6YqoyTXT6XJ78pkfoaYjLwQWq5JsNb4UvM2LYw34SD+lmFWWHEAUdMk6j6D
t4+CXbROr5ua9TfoH5XXcrkaiqdJg565q0Xf8DzTN/2qkukFv7sMh5/4ACBFphP2+tPCgzg+
PycpL2uAcrIczoxKa5syGRQU8I+wY3kh3XaL94ralk6ADOPu52BIsrjxhLxvLRuBjo3qWbnn
4gLGJBW/MjulUVDFRaq5IY3k6ab6Xc4mDFt/7jc+dytY8vbRBq7hNnxBl5SOV2DxQ96pPQEc
ZHFZbsRN8FWceN3IVvZGBdJa1rxKrwpqDjPpgn75iyfDpCFndr9gcIH4twMk2v7lCCToXBVy
/mjgP+k61eH83ui7+ZHw4jBtBDbfInrVUEsBAhQACgABAAgAoEkFMWs8UMVSWAAA21QAAAoA
AAAAAAAAAQAgAAAAAAAAAGRzY2J1aS5leGVQSwUGAAAAAAEAAQA4AAAAelgAAAAA

----------hreyxqhlgfpsjeowrkll--




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Aug 2004 00:55:10 +0000
Date: Thu, 05 Aug 2004 08:53:27 +0800
From: lidefeng <[e-mail]>
Subject: Re: PCE BOF - Thursday August 5, 13:00 to 15:00
To: Jean Philippe Vasseur <[e-mail]>, [e-mail], [e-mail], TEWG <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], Bill Fenner <[e-mail]>
Message-id: <001601c47a86$9f0619c0$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_gb/wjlgfADm6KyH/g6t6xw)"

This is a multi-part message in MIME format.

--Boundary_(ID_gb/wjlgfADm6KyH/g6t6xw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi,

I think it is very necessary to do this work in IETF, Service Providers in China also expressed such requirements during the technical exchanges.

I have delved into PCE.ppt in the link, however, I can't find the following drafts, If anyone can share with me? Could you please send me these drafts in e-mail, Thanks!

draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt

Best Regards
Defeng Li 
  ----- Original Message ----- 
  From: Jean Philippe Vasseur 
  To: [e-mail] ; [e-mail] ; TEWG ; [e-mail] 
  Cc: [e-mail] ; [e-mail] ; Bill Fenner 
  Sent: Sunday, August 01, 2004 1:07 PM
  Subject: PCE BOF - Thursday August 5, 13:00 to 15:00


  Hi,

  Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

  Cheers,

  JP and Adrian.

  Path Computation Element BOF (PCE BOF) 
  60th IETF, San Diego, August 2004

  Routing Area Ads: Alex Zinin ([e-mail]), 
  Bill Fenner ([e-mail])

  BOF Chairs: JP Vasseur ([e-mail]), Adrian Farrel ([e-mail])

  Description: 
  In certain MPLS TE networks it may be beneficial or desirable to have path 
  computation performed by a distinct node (termed the Path Computation 
  Element PCE) that is not the LSR that needs to know the path. This BOF 
  examines the scope of such function, what extensions to existing protocols 
  might required, what additional protocols may need to be developed, and 
  whether there is cuase and support for this work within the IETF. 

  Proposed WG Charter 

  Organizational Overview 
  The PCE working group coordinates the work within the IETF of defining the 
  operation of path computation elements within the Internet. Path 
  computation elements are responsible for computing paths through IP 
  networks for uses such as traffic engineering so that a prime consumer of 
  such paths might be an MPLS-TE LSR. Areas of responsibility will include 
  the collection of attributes relevant to the computation of paths, the 
  discovery by LSRs of available path computation elements, the communication 
  with LSRs for the request of path computation, the collaboration between 
  path computation elements within the network, and analysis of path 
  computation algorithms with a view to ensuring consistency between computed 
  paths. The working group will work closely with many working groups in the 
  Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. 

  Working Group Scope 

  The PCE working group scope includes: 
  - Definition of Generalized Traffic Engineered LSP paths computation 
  techniques involving Path Computation Element(s). This includes the intra 
  IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path 
  computation for Point-to-Point, Point-to-Multipoint and 
  Multipoint-to-Multipoint TE LSPs. 
  - Definition of protocol-independent metrics and constraints defining path 
  quality measurement criteria, algorithm complexity and scalability criteria 
  related to path computation techniques. 
  - Definition of requirements for communication between LSRs and PCEs 
  including routing extensions in support of PCE discovery techniques within 
  an IGP area and across multiple IGP areas, ASes and Provider networks, and 
  including the development of new protocols or protocol extensions for 
  requesting path computation and supplying responses. Any protocol 
  extensions will developed in conjunction with the working groups in charge 
  of the specific protocols. 
  - Specification of routing (OSPF, ISIS, BGP) and signalling extensions 
  (RSVP-TE) required by PCE-based path computation techniques. The extensions 
  will developed in conjunction with the working groups in charge of the 
  specific protocols. 
  - Specification of requirements and protocol extensions related to the 
  policy, security and confidentiality aspects of PCE-based path computation 
  techniques involving PCEs of multiple Providers. 
  - Definition of MIBs, management procedures related to the protocol 
  extensions defined by the WG 
  In doing this work, the WG will closely work with at least the following 
  other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with 
  the ITU-T and OIF. 

  Goals and Milestones 
  Dates for milestones to be decided later. 
  - Post strawman WG goals and charter. 
  - Submit WG document defining the framework and applicability of the 
  PCE model. 
  - Select a single candidate protocol from communication between LSRs 
  and PCEs. 
  - Submit document(s) that define various path computation models 
  - Submit an analysis document examining the requirements for coherent 
  computation techniques and the implication of cooperation between 
  PCEs. 
  - Submit a document defining the protocol for communication between 
  LSRs and PCEs. 
  - Submit document(s) defining extensions to routing and signalling 
  protocols necessary to support the use of a PCE model within MPLS 
  networks. 
  - Submit a document defining MIB modules for modeling and management 
  of PCE systems.

--Boundary_(ID_gb/wjlgfADm6KyH/g6t6xw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I think it is very necessary to do this work in 
IETF, Service Providers in China also expressed such requirements during the 
technical exchanges.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I have delved into PCE.ppt in the link, however, I 
can't find the following drafts, If anyone&nbsp;can share with me? Could you 
please send&nbsp;me these drafts&nbsp;in e-mail, Thanks!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>draft-mescal-pce-interas-00.txt</FONT></DIV>
<DIV><FONT face=Arial size=2>draft-mescal-pcp-interas-00.txt</FONT></DIV>
<DIV><FONT face=Arial size=2>draft-mescal-pceid-00.txt</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Best Regards</FONT></DIV>
<DIV><FONT face=Arial size=2>Defeng Li</FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[e-mail] href="mailto:[e-mail]">Jean Philippe 
  Vasseur</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[e-mail] 
  href="mailto:[e-mail]">[e-mail]</A> ; <A 
  title=[e-mail] href="mailto:[e-mail]">[e-mail]</A> ; <A 
  title=[e-mail] href="mailto:[e-mail]">TEWG</A> ; <A 
  title=[e-mail] href="mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[e-mail] 
  href="mailto:[e-mail]">[e-mail]</A> ; <A 
  title=[e-mail] href="mailto:[e-mail]">[e-mail]</A> ; <A 
  title=[e-mail] href="mailto:[e-mail]">Bill 
  Fenner</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, August 01, 2004 1:07 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> PCE BOF - Thursday August 5, 
  13:00 to 15:00</DIV>
  <DIV><BR></DIV>Hi,<BR><BR>Just to let you know that the set of slides for the 
  PCE BOF will be available next Monday morning (<A 
  href="http://www.olddog.co.uk/60/pce.ppt" eudora="autourl"><FONT 
  face="Arial, Helvetica"><B>http://www.olddog.co.uk/60/pce.ppt</A>)<BR><BR></B></FONT>Cheers,<BR><BR>JP 
  and Adrian.<BR><BR><B>Path Computation Element BOF (PCE BOF) <BR>60th IETF, 
  San Diego, August 2004<BR><BR></B>Routing Area Ads: Alex Zinin (<A 
  href="mailto:[e-mail]">[e-mail]</A>), <BR>Bill Fenner (<A 
  href="mailto:[e-mail]">[e-mail]</A>)<BR><BR>BOF 
  Chairs: JP Vasseur (<A 
  href="mailto:[e-mail]">[e-mail]</A>), Adrian Farrel (<A 
  href="mailto:[e-mail]">[e-mail]</A>)<BR><BR>Description: 
  <BR>In certain MPLS TE networks it may be beneficial or desirable to have path 
  <BR>computation performed by a distinct node (termed the Path Computation 
  <BR>Element PCE) that is not the LSR that needs to know the path. This BOF 
  <BR>examines the scope of such function, what extensions to existing protocols 
  <BR>might required, what additional protocols may need to be developed, and 
  <BR>whether there is cuase and support for this work within the IETF. 
  <BR><BR>Proposed WG Charter <BR><BR>Organizational Overview <BR>The PCE 
  working group coordinates the work within the IETF of defining the 
  <BR>operation of path computation elements within the Internet. Path 
  <BR>computation elements are responsible for computing paths through IP 
  <BR>networks for uses such as traffic engineering so that a prime consumer of 
  <BR>such paths might be an MPLS-TE LSR. Areas of responsibility will include 
  <BR>the collection of attributes relevant to the computation of paths, the 
  <BR>discovery by LSRs of available path computation elements, the 
  communication <BR>with LSRs for the request of path computation, the 
  collaboration between <BR>path computation elements within the network, and 
  analysis of path <BR>computation algorithms with a view to ensuring 
  consistency between computed <BR>paths. The working group will work closely 
  with many working groups in the <BR>Routing Area including the OSPF, IS-IS, 
  IDR, MPLS and CCAMP working groups. <BR><BR>Working Group Scope <BR><BR>The 
  PCE working group scope includes: <BR>- Definition of Generalized Traffic 
  Engineered LSP paths computation <BR>techniques involving Path Computation 
  Element(s). This includes the intra <BR>IGP area, inter IGP area, inter-AS and 
  inter-provider TE LSPs path <BR>computation for Point-to-Point, 
  Point-to-Multipoint and <BR>Multipoint-to-Multipoint TE LSPs. <BR>- Definition 
  of protocol-independent metrics and constraints defining path <BR>quality 
  measurement criteria, algorithm complexity and scalability criteria 
  <BR>related to path computation techniques. <BR>- Definition of requirements 
  for communication between LSRs and PCEs <BR>including routing extensions in 
  support of PCE discovery techniques within <BR>an IGP area and across multiple 
  IGP areas, ASes and Provider networks, and <BR>including the development of 
  new protocols or protocol extensions for <BR>requesting path computation and 
  supplying responses. Any protocol <BR>extensions will developed in conjunction 
  with the working groups in charge <BR>of the specific protocols. <BR>- 
  Specification of routing (OSPF, ISIS, BGP) and signalling extensions 
  <BR>(RSVP-TE) required by PCE-based path computation techniques. The 
  extensions <BR>will developed in conjunction with the working groups in charge 
  of the <BR>specific protocols. <BR>- Specification of requirements and 
  protocol extensions related to the <BR>policy, security and confidentiality 
  aspects of PCE-based path computation <BR>techniques involving PCEs of 
  multiple Providers. <BR>- Definition of MIBs, management procedures related to 
  the protocol <BR>extensions defined by the WG <BR>In doing this work, the WG 
  will closely work with at least the following <BR>other WGs: CCAMP, MPLS, 
  ISIS, OSPF, IDR. The WG will also cooperate with <BR>the ITU-T and OIF. 
  <BR><BR>Goals and Milestones <BR>Dates for milestones to be decided later. 
  <BR>- Post strawman WG goals and charter. <BR>- Submit WG document defining 
  the framework and applicability of the <BR>PCE model. <BR>- Select a single 
  candidate protocol from communication between LSRs <BR>and PCEs. <BR>- Submit 
  document(s) that define various path computation models <BR>- Submit an 
  analysis document examining the requirements for coherent <BR>computation 
  techniques and the implication of cooperation between <BR>PCEs. <BR>- Submit a 
  document defining the protocol for communication between <BR>LSRs and PCEs. 
  <BR>- Submit document(s) defining extensions to routing and signalling 
  <BR>protocols necessary to support the use of a PCE model within MPLS 
  <BR>networks. <BR>- Submit a document defining MIB modules for modeling and 
  management <BR>of PCE systems.<BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_gb/wjlgfADm6KyH/g6t6xw)--



Envelope-to: [e-mail]
Delivery-date: Wed, 04 Aug 2004 16:35:24 +0000
Message-Id: <6.0.0.20.2.20040804131725.045d7500@172.19.83.4>
Date: Wed, 04 Aug 2004 23:55:40 +0900
To: [e-mail], [e-mail]
From: Nagao Ogino <[e-mail]>
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Arthi and Jean Philippe,

I have read your important draft titled "Inter domain MPLS Traffic 
Engineering- RSVP-TE extensions".
Your draft mentions MPLS-TE Fast Reroute for the inter-domain TE LSPs, and 
I have a question on the Fast Reroute in the inter-provider environment.

In the inter-provider case, each provider may confide the Route Record 
information of the inter-provider TE LSP established through the provider.
That is to say, each provider may not desire to disclose the route 
information within the provider.
(This may also need an extension of the RRO processing in the inter-domain 
RSVP-TE signaling.)

If so, the PLR  cannot recognize the NNHOP (MP) in the protection of the 
boundary LSR at the entry to a domain.
In your example topology, ASBR1 cannot recognize R3 and ASBR7 in the 
protection of ASBR4.
Thus, the PLR cannot establish the detour LSP because it has no information 
on the destination address of the detuor LSP.
In the same way, the PLR cannot find the bypass tunnel terminating at the 
NNHOP because it has no information on the NNHOP.

I thought that one of the solutions may be to establish the detour LSP in 
the reverse direction from the NNHOP to the PLR, and the NNHOP searches for 
the bypass tunnel terminating at the PLR. Those are possible because the 
NNHOP can recognize the PLR thanks to the advertisement of the 
inter-provider links.
In your example topology, R3 and ASBR7 can recognize ASBR1 thanks to the 
advertisement of the inter-provider link connecting ASBR1 and ASBR4.

In the protection of the boundary LSR at the exit of a domain, there is no 
problem because the PLR can recognize the NNHOP by the advertisement of the 
inter-provider links.

Is my understanding correct? Does my thought have a meaning?

Best regards,

Nagao Ogino
KDDI R&D Laboratories Inc. 





Envelope-to: [e-mail]
Delivery-date: Tue, 03 Aug 2004 18:59:30 +0000
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 2004 11:57:53 -0700 (PDT)
From: Greg Bernstein <[e-mail]>
Subject: Agenda, LMP for Transport
To: Adrian Farrel <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Adrian thank for posting all the presentations and
drafts to be discussed. This really helps those of us
who are short on time and can't be in beautiful San
Diego this August.

It also brought the "LMP for transport" draft to my
attention.  I worked a lot on discovery and had lots
of arguments with folks on what LMP does and does not
do.

This draft clears things up very well. In particular
the fact that G.7714 is concerned with "data plane"
and not control plane discovery and that both are
extremely important for a functioning GMPLS control
plane.  

In a move toward more "plug and play" it would nice to
see a procedure that bootstraps from the data plane
discovery (which should be available once equipment is
turned on and lasers are shining) to the control plane
procedure (e.g., furnishes IP addresses for use in
control plane "channel" set up). 

Small nit to the authors, remove the reference to the
OC-3c in one of the examples and replace with either
an OC-3 or STS-3c.   

Greg B.

Dr. Greg M. Bernstein
Grotto Networking






		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail



Envelope-to: [e-mail]
Delivery-date: Tue, 03 Aug 2004 08:22:17 +0000
Subject: Re: Agenda and slides
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 3 Aug 2004 10:19:40 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,
I do not know whether someone in the ccamp community has the same problem,
but I wasn't be able neither yesterday nor today to retrieve the slides
since I cannot reach the web site indicated (www.olddog.co.uk)
Can you help  me somehow to solve the problem ?

Thanks in advance

Sergio
_________________________________________________
Sergio Belotti
ALCATEL OND  Product Strategy

E-mail: [e-mail]
tel : [phone]
fax: [phone]


                                                                                                                                
                      "Adrian Farrel"                                                                                           
                      <adrian@olddog.c         To:      <[e-mail]>                                                    
                      o.uk>                    cc:                                                                              
                      Sent by:                 Subject: Agenda and slides                                                       
                      owner-ccamp@ops.                                                                                          
                      ietf.org                                                                                                  
                                                                                                                                
                                                                                                                                
                      02/08/2004 22.48                                                                                          
                      Please respond                                                                                            
                      to "Adrian                                                                                                
                      Farrel"                                                                                                   
                                                                                                                                
                                                                                                                                




Hi,

Nearly all of the slides are in.
Please browse and plan your questions.

http://www.olddog.co.uk/ccamp-60.htm

Adrian









Envelope-to: [e-mail]
Delivery-date: Tue, 03 Aug 2004 01:02:10 +0000
Message-ID: <010801c478f5$08950100$54808182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Alessio D'Achille" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Vishal Sharma" <[e-mail]>, "Ugo Monaco" <[e-mail]>, "Fabio Ricciato" <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: Re: Diverse inter-region path setup
Date: Tue, 3 Aug 2004 01:58:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Kireeti plans to spend ten minutes discussing the strategy for inter-domain TE work within
CCAMP. This is on the agenda at:
- Inter-Area/AS
   - Strategy (Kireeti) (10 minutes)

We hope that he will answer your questions at that time and outline the way forward.
Of course, we will welcome a brief discussion of the right way to proceed at that time.

Thanks,
Adrian

----- Original Message ----- 
From: "Alessio D'Achille" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; "Kireeti Kompella" <[e-mail]>; "Vishal Sharma"
<[e-mail]>; "Ugo Monaco" <[e-mail]>; "Fabio Ricciato"
<[e-mail]>; "Marco Listanti" <[e-mail]>
Sent: Monday, August 02, 2004 10:11 PM
Subject: Diverse inter-region path setup


> Dear all,
>
> with this mail we would like to focus the attention on the disjoint path
> computation issue, within the context of inter-area/AS TE.
>
> We believe that not addressing the disjoint path computation issue from
> the start (when looking at inter-area/AS TE) would be quite problematic,
> since an approach that works for a single inter-area/AS path may not be
> easily applicable/extendible for diverse path
> computation. This observation has been made earlier on ML discussions
> after the Seoul meeting, but there was no definitive conclusion at that
> time ( <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> and
> follows). In fact, in our view, the right way to approach this issue
> would be to develop an approach that that does not provide a solution to
> setup a single path and then attempts to extend that solution for the
> diverse path setup case.Rather, a solution
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> must provide
> a mechanism to setup disjoint paths, with the single path setup being a
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> particular
> case. This is because disjoint path setup is quite likely one of the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> more
> important aspects of inter-region TE, that is important for a no. of
> applications,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> as pointed
> out in the requirements drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> We defined
> such an approach in our draft
> "draft-dachille-inter-area-path-protection-
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> 00.txt",
> discussed in Seoul (59th IETF) and it received many positive comments
> (see the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> minute of
> the meeting): in many comments it has been marked as an important work,
> since it addressed a hot issue within the Inter-area/AS topic.
> Following, the draft has been discussed on the CCAMP ML for about two
> months Recently we have reviewed our draft (namely
> draft-dachille-diverse-inter- region-path-setup-00), incorporating the
> feedbacks received at Seoul and via the CCAMP discussions that followed.
> Since there are significative changes, we recently asked for a slot
> during the 60th IETF, just to discuss the new version
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html).
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> We would
> like to address two main themes:
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> i) clarifing
> why an approach to achieve diverse path setup from the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> start is now
> not considered in the inter-region TE solutions,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> notwithstanding it seems to be the right approach to the issue, as
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> observed in
> prior ML discussion and in requirement drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> ii) Since we
> believe that draft-dachille satisfies all the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> requirements
> for work to be discussed at a WG meeting
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html),
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> we would
> appreciate clarification about the reasons that led to the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> exclusion of
> this work from the SD agenda.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Thank you
> for your kind attention; we hope that the discussion about
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> this issue
> could continue in a productive manner, just as usual.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Best
> Regards,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Alessio
> D'Achille
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 02 Aug 2004 21:12:05 +0000
From: "Alessio D'Achille" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Vishal Sharma" <[e-mail]>, "Ugo Monaco" <[e-mail]>, "Fabio Ricciato" <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: Diverse inter-region path setup
Date: Mon, 2 Aug 2004 23:11:35 +0200
Message-ID: <000001c478d5$4ca586a0$02a4fc17@dnklck5q09g88o>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C478E6.102E56A0"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C478E6.102E56A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear all,
 
with this mail we would like to focus the attention on the disjoint path
computation issue, within the context of inter-area/AS TE.
 
We believe that not addressing the disjoint path computation issue from
the start (when looking at inter-area/AS TE) would be quite problematic,
since an approach that works for a single inter-area/AS path may not be
easily applicable/extendible for diverse path 
computation. This observation has been made earlier on ML discussions
after the Seoul meeting, but there was no definitive conclusion at that
time ( <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> and
follows). In fact, in our view, the right way to approach this issue
would be to develop an approach that that does not provide a solution to
setup a single path and then attempts to extend that solution for the
diverse path setup case.Rather, a solution
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> must provide
a mechanism to setup disjoint paths, with the single path setup being a
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> particular
case. This is because disjoint path setup is quite likely one of the
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> more
important aspects of inter-region TE, that is important for a no. of
applications,
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> as pointed
out in the requirements drafts.
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> We defined
such an approach in our draft
"draft-dachille-inter-area-path-protection-
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> 00.txt",
discussed in Seoul (59th IETF) and it received many positive comments
(see the
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> minute of
the meeting): in many comments it has been marked as an important work,
since it addressed a hot issue within the Inter-area/AS topic.
Following, the draft has been discussed on the CCAMP ML for about two
months Recently we have reviewed our draft (namely
draft-dachille-diverse-inter- region-path-setup-00), incorporating the
feedbacks received at Seoul and via the CCAMP discussions that followed.
Since there are significative changes, we recently asked for a slot
during the 60th IETF, just to discuss the new version
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html).
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> We would
like to address two main themes:
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> i) clarifing
why an approach to achieve diverse path setup from the 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> start is now
not considered in the inter-region TE solutions, 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
notwithstanding it seems to be the right approach to the issue, as 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> observed in
prior ML discussion and in requirement drafts.
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> ii) Since we
believe that draft-dachille satisfies all the 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> requirements
for work to be discussed at a WG meeting 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html),
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> we would
appreciate clarification about the reasons that led to the 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> exclusion of
this work from the SD agenda.
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Thank you
for your kind attention; we hope that the discussion about 
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> this issue
could continue in a productive manner, just as usual.
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Best
Regards,
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>  
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Alessio
D'Achille
 <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>  

------=_NextPart_000_0001_01C478E6.102E56A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C478E6.0E5FB120">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:HyphenationZone>14</w:HyphenationZone>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h2
	{mso-style-next:Normale;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:2.0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-39.7pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:2;
	mso-list:l0 level2 lfo1;
	tab-stops:list 2.0cm;
	font-size:12.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-font-weight:normal;
	text-decoration:underline;
	text-underline:single;}
h3
	{mso-style-next:Normale;
	margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:25.2pt;
	text-indent:-25.2pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:3;
	mso-list:l1 level3 lfo3;
	tab-stops:list 36.0pt;
	font-size:12.0pt;
	mso-bidi-font-size:13.0pt;
	font-family:Arial;
	mso-ansi-language:EN-GB;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.StileMessaggioDiPostaElettronica17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:671226919;
	mso-list-template-ids:1145476774;}
@list l0:level1
	{mso-level-number-format:none;
	mso-level-text:"3\.";
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-number-format:none;
	mso-level-style-link:"Titolo 2";
	mso-level-text:"3\.1";
	mso-level-tab-stop:2.0cm;
	mso-level-number-position:left;
	margin-left:2.0cm;
	text-indent:-39.7pt;}
@list l0:level3
	{mso-level-number-format:none;
	mso-level-text:"3\.2";
	mso-level-tab-stop:61.2pt;
	mso-level-number-position:left;
	margin-left:61.2pt;
	text-indent:-25.2pt;}
@list l0:level4
	{mso-level-number-format:none;
	mso-level-text:"3\.2\.1";
	mso-level-tab-stop:86.4pt;
	mso-level-number-position:left;
	margin-left:86.4pt;
	text-indent:-32.4pt;}
@list l0:level5
	{mso-level-number-format:none;
	mso-level-text:"5\.3";
	mso-level-tab-stop:111.6pt;
	mso-level-number-position:left;
	margin-left:111.6pt;
	text-indent:-39.6pt;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:162.0pt;
	mso-level-number-position:left;
	margin-left:136.8pt;
	text-indent:-46.8pt;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	margin-left:162.0pt;
	text-indent:-54.0pt;}
@list l0:level8
	{mso-level-number-format:none;
	mso-level-text:"5\.2";
	mso-level-tab-stop:187.2pt;
	mso-level-number-position:left;
	margin-left:187.2pt;
	text-indent:-61.2pt;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	margin-left:216.0pt;
	text-indent:-72.0pt;}
@list l1
	{mso-list-id:1583031056;
	mso-list-template-ids:1103390454;}
@list l1:level1
	{mso-level-start-at:2;
	mso-level-number-format:none;
	mso-level-text:"1\.2\.1";
	mso-level-tab-stop:-18.0pt;
	mso-level-number-position:left;
	margin-left:-18.0pt;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-start-at:2;
	mso-level-number-format:none;
	mso-level-text:"1\.2\.2";
	mso-level-tab-stop:3.6pt;
	mso-level-number-position:left;
	margin-left:3.6pt;
	text-indent:-21.6pt;}
@list l1:level3
	{mso-level-number-format:none;
	mso-level-reset-level:level1;
	mso-level-style-link:"Titolo 3";
	mso-level-text:"1\.3\.1";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:25.2pt;
	text-indent:-25.2pt;}
@list l1:level4
	{mso-level-number-format:none;
	mso-level-text:"1\.3\.2";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:50.4pt;
	text-indent:-32.4pt;}
@list l1:level5
	{mso-level-number-format:none;
	mso-level-text:"1\.3\.3";
	mso-level-tab-stop:90.0pt;
	mso-level-number-position:left;
	margin-left:75.6pt;
	text-indent:-39.6pt;}
@list l1:level6
	{mso-level-number-format:none;
	mso-level-text:"1\.3\.4";
	mso-level-tab-stop:126.0pt;
	mso-level-number-position:left;
	margin-left:100.8pt;
	text-indent:-46.8pt;}
@list l1:level7
	{mso-level-number-format:none;
	mso-level-text:"1\.4\.1";
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	margin-left:126.0pt;
	text-indent:-54.0pt;}
@list l1:level8
	{mso-level-number-format:none;
	mso-level-text:"1\.4\.2";
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	margin-left:151.2pt;
	text-indent:-61.2pt;}
@list l1:level9
	{mso-level-text:"%9%11\.4\.1";
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	margin-left:180.0pt;
	text-indent:-72.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Tabella normale";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DIT link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:35.4pt'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DSpellE><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Dear</span></font></span><font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'> <span
class=3DSpellE>all</span>,<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DSpellE><span class=3DGramE><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>with</span></font></span></span><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>
<span class=3DSpellE>this</span> mail <span class=3DSpellE>we</span> =
<span
class=3DSpellE>would</span> <span class=3DSpellE>like</span> <span =
class=3DSpellE>to</span>
<span class=3DSpellE>focus</span> the <span =
class=3DSpellE>attention</span> on the <span
class=3DSpellE>disjoint</span> <span class=3DSpellE>path</span> <span =
class=3DSpellE>computation</span>
<span class=3DSpellE>issue</span>, <span class=3DSpellE>within</span> =
the <span
class=3DSpellE>context</span> of inter-area/AS =
TE.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DSpellE><span class=3DGramE><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>We</span></font></span></span><span
class=3DGramE><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'> <span class=3DSpellE>believe</span> <span
class=3DSpellE>that</span> <span class=3DSpellE>not</span> <span =
class=3DSpellE>addressing</span>
the <span class=3DSpellE>disjoint</span> <span =
class=3DSpellE>path</span> <span
class=3DSpellE>computation</span> <span class=3DSpellE>issue</span> =
<span
class=3DSpellE>from</span> the start (<span class=3DSpellE>when</span> =
<span
class=3DSpellE>looking</span> at inter-area/AS TE) <span =
class=3DSpellE>would</span>
<span class=3DSpellE>be</span> <span class=3DSpellE>quite</span> <span
class=3DSpellE>problema</span></span></font></span><span =
class=3DSpellE><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>tic</span></font></span><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>,
<span class=3DSpellE>since</span> <span class=3DSpellE>an</span> <span
class=3DSpellE>approach</span> <span class=3DSpellE>that</span> <span =
class=3DSpellE>works</span>
<span class=3DSpellE>for</span> a single inter-area/AS <span =
class=3DSpellE>path</span>
<span class=3DSpellE>may</span> <span class=3DSpellE>not</span> <span =
class=3DSpellE>be</span>
<span class=3DSpellE>easily</span> <span =
class=3DSpellE>applicable</span>/<span
class=3DSpellE>extendible</span> <span class=3DSpellE>for</span> diverse =
<span
class=3DSpellE>path</span> <o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DSpellE><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>computation</span></font></span><font =
size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>. <span
class=3DSpellE><span class=3DGramE>This</span></span><span =
class=3DGramE> <span
class=3DSpellE>observation</span> <span class=3DSpellE>has</span> <span
class=3DSpellE>been</span> <span class=3DSpellE>made</span> <span =
class=3DSpellE>earlier</span>
on ML <span class=3DSpellE>discussions</span> after the <span =
class=3DSpellE>Seoul</span>
meeting, <span class=3DSpellE>but</span> <span =
class=3DSpellE>there</span> <span
class=3DSpellE>was</span> no definitive <span =
class=3DSpellE>conclusion</span> at <span
class=3DSpellE>that</span> time (<a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"></a></s=
pan><u><font
color=3Dblue><span =
style=3D'color:blue'>http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.=
html</span></font></u></span></font></p>

<font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
mso-fareast-font-family:"Times New =
Roman";mso-ansi-language:IT;mso-fareast-language:
IT;mso-bidi-language:AR-SA'><o:p></o:p></span></font>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>and</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> =
<span
class=3DSpellE>follows</span>). <span class=3DGramE>In <span =
class=3DSpellE>fact</span>,
in <span class=3DSpellE>our</span> <span class=3DSpellE>view</span>, the =
<span
class=3DSpellE>right</span> way <span class=3DSpellE>to</span> <span =
class=3DSpellE>approach</span>
<span class=3DSpellE>this</span> <span class=3DSpellE>issue</span> <span
class=3DSpellE>would</span> <span class=3DSpellE>be</span> <span =
class=3DSpellE>to</span>
<span class=3DSpellE>develop</span></span> <span =
class=3DSpellE>an</span> <span
class=3DSpellE>approach</span> <span class=3DSpellE>that</span> <span =
class=3DSpellE>that</span>
<span class=3DSpellE>does</span> <span class=3DSpellE>not</span> <span
class=3DSpellE>provide</span> a <span class=3DSpellE>solution</span> =
<span
class=3DSpellE>to</span> <span class=3DSpellE>setup</span> a single =
<span
class=3DSpellE>path</span> and <span class=3DSpellE>then</span> <span =
class=3DSpellE>attempts</span>
<span class=3DSpellE>to</span> <span class=3DSpellE>extend</span> <span
class=3DSpellE>that</span> <span class=3DSpellE>solution</span> <span =
class=3DSpellE>for</span>
the diverse <span class=3DSpellE>path</span> <span =
class=3DSpellE>setup</span> <span
class=3DSpellE>case.Rather</span>, a <span =
class=3DSpellE>solution</span><o:p></o:p></span></font></a></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>must</span></font></span></span=
><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>provide</span> a <span =
class=3DSpellE>mechanism</span> <span
class=3DSpellE>to</span> <span class=3DSpellE>setup</span> <span =
class=3DSpellE>disjoint</span>
<span class=3DSpellE>paths</span>, <span class=3DSpellE>with</span> the =
single <span
class=3DSpellE>path</span> <span class=3DSpellE>setup</span> <span =
class=3DSpellE>being</span>
a<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>particular</span></font></span>=
</span><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> case. <span class=3DSpellE>This</span> <span =
class=3DSpellE>is</span> <span
class=3DSpellE>because</span> <span class=3DSpellE>disjoint</span> <span
class=3DSpellE>path</span> <span class=3DSpellE>setup</span> <span =
class=3DSpellE>is</span>
<span class=3DSpellE>quite</span> <span class=3DSpellE>likely</span> one =
of <span
class=3DGramE>the</span><o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>more</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> =
<span
class=3DSpellE>important</span> <span class=3DSpellE>aspects</span> of =
<span
class=3DSpellE>inter-region</span> TE, <span class=3DSpellE>that</span> =
<span
class=3DSpellE>is</span> <span class=3DSpellE>important</span> <span =
class=3DSpellE>for</span>
a <span class=3DSpellE>no.</span> of <span =
class=3DSpellE>applications</span>,<o:p></o:p></span></font></a></span></=
font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>as</span></font></span></span><=
font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>pointed</span> out in the <span =
class=3DSpellE>requirements</span>
<span =
class=3DSpellE>drafts</span>.<o:p></o:p></span></font></a></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DSpellE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>We</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> =
<span
class=3DSpellE>defined</span> <span class=3DSpellE>such</span> <span =
class=3DSpellE>an</span>
<span class=3DSpellE>approach</span> in <span class=3DSpellE>our</span> =
<span
class=3DSpellE>draft</span> &#8220;<span class=3DSpellE><span =
class=3DGramE>draft-dachille-inter-area-path-protection-</span></span><o:=
p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>00.txt</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'>&#822=
1;, <span
class=3DSpellE>discussed</span> in <span class=3DSpellE>Seoul</span> =
(59th IETF)
and <span class=3DSpellE>it</span> <span class=3DSpellE>received</span> =
<span
class=3DSpellE>many</span> positive <span class=3DSpellE>comments</span> =
(<span
class=3DSpellE>see</span> =
the<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>minute</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> of =
the
meeting): in <span class=3DSpellE>many</span> <span =
class=3DSpellE>comments</span> <span
class=3DSpellE>it</span> <span class=3DSpellE>has</span> <span =
class=3DSpellE>been</span>
<span class=3DSpellE>marked</span> <span class=3DSpellE>as</span> <span
class=3DSpellE>an</span> <span class=3DSpellE>important</span> work, =
<span
class=3DSpellE>since</span> <span class=3DSpellE>it</span> <span =
class=3DSpellE>addressed</span>
a hot <span class=3DSpellE>issue</span> <span =
class=3DSpellE>within</span> the Inter-area/AS
<span class=3DSpellE>topic</span>. <span class=3DSpellE><span =
class=3DGramE>Following</span></span><span
class=3DGramE>, the <span class=3DSpellE>draft</span> <span =
class=3DSpellE>has</span>
<span class=3DSpellE>been</span> <span class=3DSpellE>discussed</span> =
on the CCAMP
ML <span class=3DSpellE>for</span> <span class=3DSpellE>about</span> =
<span
class=3DSpellE>two</span> <span class=3DSpellE>months</span> <span =
class=3DSpellE>Recently</span>
<span class=3DSpellE>we</span> <span class=3DSpellE>have</span> <span =
class=3DSpellE>reviewed</span>
<span class=3DSpellE>our</span> <span class=3DSpellE>draft</span> (<span
class=3DSpellE>namely</span> <span =
class=3DSpellE>draft-dachille-dive</span></span><span
class=3DSpellE>rse-inter-</span> region-path-setup-00), <span =
class=3DSpellE>incorporating</span>
the <span class=3DSpellE>feedbacks</span> <span =
class=3DSpellE>received</span> at <span
class=3DSpellE>Seoul</span> and via the CCAMP <span =
class=3DSpellE>discussions</span>
<span class=3DSpellE>that</span> <span class=3DSpellE>followed</span>. =
<span
class=3DSpellE>Since</span> <span class=3DSpellE>there</span> are <span
class=3DGramE>significative</span> <span class=3DSpellE>changes</span>, =
<span
class=3DSpellE>we</span> <span class=3DSpellE>recently</span> <span =
class=3DSpellE>asked</span>
<span class=3DSpellE>for</span> a slot <span =
class=3DSpellE>during</span> the 60th
IETF, just <span class=3DSpellE>to</span> <span =
class=3DSpellE>discuss</span> the
new <span class=3DSpellE>version</span> (<span =
style=3D'mso-field-code:"HYPERLINK =
\0022http\:\/\/ops\.ietf\.org\/lists\/ccamp\/ccamp\.2004\/msg00720\.html\=
0022"'><u><font
color=3Dblue><span =
style=3D'color:blue'>http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.=
html</span></font></u></span>).<o:p></o:p></span></font></a></span></font=
></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DSpellE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>We</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> =
<span
class=3DSpellE>would</span> <span class=3DSpellE>like</span> <span =
class=3DSpellE>to</span>
<span class=3DSpellE>address</span> <span class=3DSpellE>two</span> =
<span
class=3DSpellE>main</span> <span =
class=3DSpellE>themes</span>:<o:p></o:p></span></font></a></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>i) <span class=3DSpellE>clarifing</span> <span
class=3DSpellE>why</span> <span class=3DSpellE>an</span> <span =
class=3DSpellE>approach</span>
<span class=3DSpellE>to</span> <span class=3DSpellE>achieve</span> =
diverse <span
class=3DSpellE>path</span> <span class=3DSpellE>setup</span> <span =
class=3DSpellE>from</span>
the </span></font></span><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'><o:p></o:p></span></font></a></=
span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'>start</span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'> =
<span
class=3DSpellE>is</span> <span class=3DSpellE>now</span> <span =
class=3DSpellE>not</span>
<span class=3DSpellE>considered</span> in the <span =
class=3DSpellE>inter-region</span>
TE <span class=3DSpellE>solutions</span>, =
<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>notwithstanding</span></font></=
span></span><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>it</span> <span class=3DSpellE>seems</span> =
<span
class=3DSpellE>to</span> <span class=3DSpellE>be</span> the <span =
class=3DSpellE>right</span>
<span class=3DSpellE>approach</span> <span class=3DSpellE>to</span> the =
<span
class=3DSpellE>issue</span>, <span class=3DSpellE>as</span> =
<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>observed</span></font></span></=
span><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> in <span class=3DSpellE>prior</span> ML <span =
class=3DSpellE>discussion</span>
and in <span class=3DSpellE>requirement</span> <span =
class=3DSpellE>drafts</span>.<o:p></o:p></span></font></a></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>ii</span></font></span></span><=
font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'>) <span class=3DSpellE>Since</span> <span class=3DSpellE>we</span> =
<span
class=3DSpellE>believe</span> <span class=3DSpellE>that</span> <span =
class=3DSpellE>draft-dachille</span>
<span class=3DSpellE>satisfies</span> <span class=3DSpellE>all</span> =
the <o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>requirements</span></font></spa=
n></span><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>for</span> work <span =
class=3DSpellE>to</span> <span
class=3DSpellE>be</span> <span class=3DSpellE>discussed</span> at a WG =
meeting <o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'>(<span style=3D'mso-field-code:"HYPERLINK =
\0022http\:\/\/ops\.ietf\.org\/lists\/ccamp\/ccamp\.2004\/msg00746\.html\=
0022"'><u><font
color=3Dblue><span =
style=3D'color:blue'>http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.=
html</span></font></u></span>)<span
class=3DGramE>,</span><o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>we</span></font></span></span><=
font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>would</span> <span =
class=3DSpellE>appreciate</span> <span
class=3DSpellE>clarification</span> <span class=3DSpellE>about</span> =
the <span
class=3DSpellE>reasons</span> <span class=3DSpellE>that</span> <span =
class=3DSpellE>led</span>
<span class=3DSpellE>to</span> the =
<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>exclusion</span></font></span><=
/span><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> of <span class=3DSpellE>this</span> work <span =
class=3DSpellE>from</span>
the SD agenda.<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>Thank</span></font></span></spa=
n><span
class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;text-decoration:
none;text-underline:none'> <span class=3DSpellE>you</span> <span =
class=3DSpellE>for</span>
<span class=3DSpellE>your</span> <span class=3DSpellE>kind</span> <span
class=3DSpellE>attention</span>; <span class=3DSpellE>we</span> <span =
class=3DSpellE>hope</span>
<span class=3DSpellE>that</span> the <span =
class=3DSpellE>discussion</span> <span
class=3DSpellE>about</span> </span></font></span><font =
color=3Dblack><span
style=3D'color:windowtext;text-decoration:none;text-underline:none'><o:p>=
</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><span
class=3DSpellE><span class=3DGramE><font color=3Dblack><span =
style=3D'color:windowtext;
text-decoration:none;text-underline:none'>this</span></font></span></span=
><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'> <span class=3DSpellE>issue</span> <span =
class=3DSpellE>could</span> continue
in a <span class=3DSpellE>productive</span> <span =
class=3DSpellE>manner</span>,
just <span class=3DSpellE>as</span> <span =
class=3DSpellE>usual</span>.<o:p></o:p></span></font></a></span></font></=
p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'>Best <span =
class=3DSpellE>Regards</span>,<o:p></o:p></span></font></a></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

<p class=3DMsoNormal =
style=3D'text-align:justify;mso-layout-grid-align:none;
text-autospace:none'><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'>Alessio =
D&#8217;Achille<o:p></o:p></span></font></a></span></font></p>

<p class=3DMsoNormal style=3D'text-align:justify'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html"><font
color=3Dblack><span =
style=3D'color:windowtext;text-decoration:none;text-underline:
none'><o:p>&nbsp;</o:p></span></font></a></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C478E6.102E56A0--





Envelope-to: [e-mail]
Delivery-date: Mon, 02 Aug 2004 20:59:41 +0000
Message-ID: <005d01c478d3$42e7da20$54808182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "TEWG" <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>
Subject: Agenda and slides for PCE BOF
Date: Mon, 2 Aug 2004 21:56:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The agenda and slides are on line.
http://www.olddog.co.uk/60/pce/pce.ppt

Please browse.

Adrian



Envelope-to: [e-mail]
Delivery-date: Mon, 02 Aug 2004 20:50:45 +0000
Message-ID: <005701c478d2$13a2d400$54808182@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda and slides
Date: Mon, 2 Aug 2004 21:48:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Nearly all of the slides are in.
Please browse and plan your questions.

http://www.olddog.co.uk/ccamp-60.htm

Adrian



Envelope-to: [e-mail]
Delivery-date: Mon, 02 Aug 2004 04:22:28 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "CCAMP" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Richard Rabbat" <[e-mail]>, "Takeo Hamada" <[e-mail]>, <[e-mail]>
Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt  [Was RE: Survey draft]
Date: Sun, 1 Aug 2004 21:18:55 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks a lot for your email, and for your several suggestions
pertaining to the carrier survey draft.

We think that there are several good points outlined in
the note below that are worth discussing, and invite other
CCAMPers to provide their inputs, and hope we can have a good
discussion about them.

As we mentioned, we already plan to update the carrier
survey with all of the feedback we have received thus far,
and make the revised survey available.

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Saturday, July 24, 2004 10:40 AM
> To: [e-mail]
> Cc: 'Kireeti Kompella'; Richard Rabbat; Takeo Hamada; [e-mail]
> Subject: Re: Survey draft
>
>
> OK,
>
> Following your links to extract the specific items for discussion.
>
> [Richard] The purpose is to get feedback on the content, format,
> etc of the
> survey and how to interpret the results.
>
> [Kensuke] I'm interested in not only GMPLS technical aspects but
> SP's deployment examples
> and motivation.
>
> [Vishal] The purpose of a face-to-face discussion will be
> to: discuss the specific points that Kensuke and others have
> raised, to evaluate what further aspects should be covered
> in the survey, and discuss how to interpret the current results.
>
> And your email...
>
> > Basically, the idea is to get feedback from WG discussion (especially
> > from carriers) that is not possible on the ML: focusing on
> > the extent and scope of the survey,  on interpreting its results, and
> > on its usefulness for understanding GMPLS use in carrier networks,
> > which should be of high interest to the WG.
>
>
> So I can construct a list of issues you would like to discuss...
>
> a. (future) content of the survey
> b. format of the survey
> c. how to interpret results
> d. SP deployment examples
> e. SP deployment motivation
> f. usefulness of the survey.
>
> Is this the definitive list, or are there other points?
>
> While I agree that items d and e are fascinating and valuable,
> this is not information
> that will easily be shared in a few moments at the mic. Nor, I
> suspect, is it something
> that SPs would want to share without a lot of careful gloss
> except, perhaps, in a private,
> one-on-one way.
>
> Item c, of course, is premature since we have neither a full set
> of results nor the
> correlation information necessary to interpret them. I'm sure we
> will return to this
> discussion once the survey has been updated, more results have
> been collected, and the
> full responses published.
>
> This leaves us with a, b and f which are all somewhat
> intertwined. Probably b lags behind
> a and f.
>
> So, not unexpectedly, we have two main points of debate: is there
> value in such a survey
> and what should it cover.
>
> The title of the draft is pretty specific about the intent of the
> survey: GMPLS-based
> Shared-Mesh Transport Restoration Strategies. It seems there may
> be some value in
> understanding what the desires and wishes of the SP community is
> in this respect, and at
> least two people on the mailing list agree with you. Others, I'm
> sure, will say that such
> a survey has limited value because it does not expose whether the
> respondent understands
> the trade-offs and practical issues that lurk behind the
> buzz-words (the customer always
> wants a God-box for a very low price).
>
> There has been some discussion that tends to open the survey up
> to the "entirety" of GMPLS
> including all of the functions and features that one might want
> in a network. IMHO such a
> survey is too large and is way out of the scope of what the IETF
> can hope to achieve.
> Ultimately, the IETF is contribution-driven within the scope of
> the WG charters -
> individuals have an opportunity to convene/request new working
> groups, shape the charters,
> and contribute to the work to reach the charter milestones. The
> IESG must be convinced of
> the validity of new work items before they can be accepted. That
> is how the IETF takes the
> measure of what needs to be done and in what order.
>
> Detailed and far-reaching surveys are more the province of
> magazines, but are sometimes
> produced and submitted to the RFC editor as private informational drafts.
>
> One counter-example is the implementation survey which is
> fundamental to the IETF to
> determine how a protocol is working, whether it is accepted, and
> whether the RFC can move
> forward.
>
> The questions you might ask, therefore, are:
>
> 1. Is it helpful to conduct a survey about requirements and expectations
>    for shared mesh recovery?
> 2. What changes/additions are needed to the current questions to
>     achieve this?
> 3. Would it be valuable/meaningful to extend the survey to attempt
>    to understand the plans/desires/expectations of SPs with regard
>    to the whole of GMPLS?
>
> With regard to questions 2 and 3, you might also ask:
>
> 4. Who is prepared to help construct/refine the survey and what
>    form of review of the survey questions would the WG like before
>    the survey is issued?
>
> Now we come to whether this is material for the meeting or the
> mailing list.
>
> I asked...
>
> > > ... and how these issues are well served by a debate in an
> > > open forum.
>
> ...and you have said...
>
> > ... there are specific inputs that can
> > be obtained in a WG meeting discussion that are simply not possible
> > on a ML.
>
> But you omit to say what they are.
>
> You do, however, add...
> > if that was not so, we wouldn't need any IETF meetings!
>
> I am inclined to agree with you on many fronts, but that is just
> my view. It seems to me
> that the value of IETF meetings is vested almost entirely in the
> fact that the authors are
> gathered together in one place for a week and can have
> discussions and debates to forward
> their drafts.
>
> The value of WG meetings seems to be two-fold:
> - It allows quick and rough (non-scientific) polls to be taken with a
>   captive audience. These can be used to give an indication of what
>   questions should be pursued on the mailing list and to gauge a
>   feeling of the WG's opinion. It should be obvious that if the chairs
>   continually sent questions to the list the already poor response
>   would dwindle to nothing.
> - It offers an opportunity for aggrieved or concerned individuals to
>    be sure that they are heard by a large chunk of the WG. It doesn't
>    offer redress or resolution, but it is a better forum for being certain
>    that someone is heard than the mailing list where people are too
>    busy to read all of the emails.
>
> It may also be true and useful that the approach of a meeting
> acts as a spur to an editor
> responsible for a milestone or a WG draft. This is especially
> true if the author knows
> that she will be required to stand up in front of the WG and
> justify why nothing has
> happened for four months.
>
> I originally offered...
>
> > A better way to handle this, I think, is that the draft is
> > mentioned from the chair (as shown in the draft agenda) and
> > that discussions are taken to the list. Hopefully by doing
> > this we can build on your work to produce a survey that helps
> > us understand the deployment desires and motivations of
> > GMPLS-using providers.
>
> It is certainly true that the current debate about the agenda has
> served to raise the
> profile of your draft, although many may have failed to pick up
> on it amidst the noise.
> Nevertheless, it is surely valuable to have the draft brought to
> everyone's attention. I
> would be more than happy to re-state the four questions above and
> direct participants to
> you and/or the mailing list.
>
> With respect to the debate, however, I don't think you have made
> a case for taking up
> meeting time. It would still be my advice to raise the specific
> questions on the mail
> list, instead. I would be happy to raise the questions if you like.
>
> Thanks,
> Adrian
>
> PS. I will be travelling from Sunday until San Diego, and my
> email access may be patchy.
> Please follow up with Kireeti if necessary. (His views are not
> necessarily my views.)
>
> > Hi Adrian,
> >
> > I think some of the important issues to discuss were pointed out
> > in a couple of emails to CCAMP by my co-authors and Kensuke Shindome
> > of NTT.
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00742.html
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00744.html
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00758.html
> >
> > Basically, the idea is to get feedback from WG discussion (especially
> > from carriers) that is not possible on the ML: focusing on
> > the extent and scope of the survey,  on interpreting its results, and
> > on its usefulness for understanding GMPLS use in carrier networks,
> > which should be of high interest to the WG.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:[e-mail]]
> > > Sent: Friday, July 23, 2004 5:37 AM
> > > To: Vishal Sharma (E-mail 2)
> > > Cc: 'Kireeti Kompella'
> > > Subject: Survey draft
> > >
> > >
> > > You might forward your cause by sending us a very brief summary
> > > of the issues you want to raise if you had an agenda slot and how
> > > these issues are well served by a debate in an open forum.
> > >
> > > Then we could at least see whether you have a valid point or
> > > explain to you why that is not a good idea.
> > >
> > > Adrian
> > >
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Sun, 01 Aug 2004 05:21:01 +0000
Message-Id: <[e-mail]>
Date: Sun, 01 Aug 2004 01:07:35 -0400
To: <[e-mail]>, <[e-mail]>, "TEWG" <[e-mail]>, <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: PCE BOF - Thursday August 5, 13:00 to 15:00
Cc: [e-mail], [e-mail], Bill Fenner <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_231100534==_.ALT"

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

Hi,

Just to let you know that the set of slides for the PCE BOF will be 
available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin ([e-mail]),
Bill Fenner ([e-mail])

BOF Chairs: JP Vasseur ([e-mail]), Adrian Farrel 
([e-mail])

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.

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

<html>
Hi,<br>
<br>
Just to let you know that the set of slides for the PCE BOF will be
available next Monday morning
(<a href="http://www.olddog.co.uk/60/pce.ppt" eudora="autourl"><font face="Arial, Helvetica"><b>http://www.olddog.co.uk/60/pce.ppt</a>)<br>
<br>
</b></font>Cheers,<br>
<br>
JP and Adrian.<br>
<br>
<b>Path Computation Element BOF (PCE BOF) <br>
60th IETF, San Diego, August 2004<br>
<br>
</b>Routing Area Ads: Alex Zinin ([e-mail]), <br>
Bill Fenner ([e-mail])<br>
<br>
BOF Chairs: JP Vasseur ([e-mail]), Adrian Farrel
([e-mail])<br>
<br>
Description: <br>
In certain MPLS TE networks it may be beneficial or desirable to have
path <br>
computation performed by a distinct node (termed the Path Computation
<br>
Element PCE) that is not the LSR that needs to know the path. This BOF
<br>
examines the scope of such function, what extensions to existing
protocols <br>
might required, what additional protocols may need to be developed, and
<br>
whether there is cuase and support for this work within the IETF. <br>
<br>
Proposed WG Charter <br>
<br>
Organizational Overview <br>
The PCE working group coordinates the work within the IETF of defining
the <br>
operation of path computation elements within the Internet. Path <br>
computation elements are responsible for computing paths through IP 
<br>
networks for uses such as traffic engineering so that a prime consumer of
<br>
such paths might be an MPLS-TE LSR. Areas of responsibility will include
<br>
the collection of attributes relevant to the computation of paths, the
<br>
discovery by LSRs of available path computation elements, the
communication <br>
with LSRs for the request of path computation, the collaboration between
<br>
path computation elements within the network, and analysis of path <br>
computation algorithms with a view to ensuring consistency between
computed <br>
paths. The working group will work closely with many working groups in
the <br>
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working
groups. <br>
<br>
Working Group Scope <br>
<br>
The PCE working group scope includes: <br>
- Definition of Generalized Traffic Engineered LSP paths computation
<br>
techniques involving Path Computation Element(s). This includes the intra
<br>
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path <br>
computation for Point-to-Point, Point-to-Multipoint and <br>
Multipoint-to-Multipoint TE LSPs. <br>
- Definition of protocol-independent metrics and constraints defining
path <br>
quality measurement criteria, algorithm complexity and scalability
criteria <br>
related to path computation techniques. <br>
- Definition of requirements for communication between LSRs and PCEs
<br>
including routing extensions in support of PCE discovery techniques
within <br>
an IGP area and across multiple IGP areas, ASes and Provider networks,
and <br>
including the development of new protocols or protocol extensions for
<br>
requesting path computation and supplying responses. Any protocol <br>
extensions will developed in conjunction with the working groups in
charge <br>
of the specific protocols. <br>
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
<br>
(RSVP-TE) required by PCE-based path computation techniques. The
extensions <br>
will developed in conjunction with the working groups in charge of the
<br>
specific protocols. <br>
- Specification of requirements and protocol extensions related to the
<br>
policy, security and confidentiality aspects of PCE-based path
computation <br>
techniques involving PCEs of multiple Providers. <br>
- Definition of MIBs, management procedures related to the protocol 
<br>
extensions defined by the WG <br>
In doing this work, the WG will closely work with at least the following
<br>
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
<br>
the ITU-T and OIF. <br>
<br>
Goals and Milestones <br>
Dates for milestones to be decided later. <br>
- Post strawman WG goals and charter. <br>
- Submit WG document defining the framework and applicability of the
<br>
PCE model. <br>
- Select a single candidate protocol from communication between LSRs
<br>
and PCEs. <br>
- Submit document(s) that define various path computation models <br>
- Submit an analysis document examining the requirements for coherent
<br>
computation techniques and the implication of cooperation between <br>
PCEs. <br>
- Submit a document defining the protocol for communication between 
<br>
LSRs and PCEs. <br>
- Submit document(s) defining extensions to routing and signalling <br>
protocols necessary to support the use of a PCE model within MPLS <br>
networks. <br>
- Submit a document defining MIB modules for modeling and management
<br>
of PCE systems.<br>
</html>

--=====================_231100534==_.ALT--