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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Aug 2004 23:12:30 +0100

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

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 30 Aug 2004 16:30:13 -0400

Draft has been updated and resubmitted.

Alex,
         Thanks again for the review.

Lou

---

From: Alex Zinin <[email-masked]>
Date: Tue, 31 Aug 2004 17:47:16 -0700

IETF Last Call requested. Thanks, Lou.

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

>> > This one should be removed for the same reason.

Delivery-date: Tue, 31 Aug 2004 20:41:41 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  'John Drake' <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 13:40:11 -0700

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:[email-masked]]
Sent: Tuesday, August 31, 2004 11:08 AM
To: Ong, Lyndon; 'John Drake'
Cc: [email-masked]; Adrian Farrel; [email-masked]
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:[email-masked]]
> Sent: Tuesday, August 31, 2004 8:22 AM
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: Communication from the OIF
> 
> 
> Dimitri,
> 
> Excellent note.  You saved me a lot of typing.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Monday, August 30, 2004 11:32 AM
>>To: Adrian Farrel
>>Cc: [email-masked]
>>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, [email-masked], IETF,
>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>Routing Area Director Mr. Bill Fenner, [email-masked], 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
>>
> 
> 
> 
> .
> 

Delivery-date: Tue, 31 Aug 2004 19:34:27 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 31 Aug 2004 19:22:45 +0000
From: John Drake <[email-masked]>
To: [email-masked], [email-masked],  "Ong, Lyndon" <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 12:19:58 -0700

Snipped

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; John Drake
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> 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

Delivery-date: Tue, 31 Aug 2004 18:09:08 +0000
Date: Tue, 31 Aug 2004 20:08:16 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: "Ong, Lyndon" <[email-masked]>, 'John Drake' <[email-masked]>
CC: [email-masked],  Adrian Farrel <[email-masked]>, [email-masked]
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:[email-masked]]
> Sent: Tuesday, August 31, 2004 8:22 AM
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: Communication from the OIF
> 
> 
> Dimitri,
> 
> Excellent note.  You saved me a lot of typing.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Monday, August 30, 2004 11:32 AM
>>To: Adrian Farrel
>>Cc: [email-masked]
>>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, [email-masked], IETF,
>>>CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
>>>IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
>>>Routing Area Director Mr. Bill Fenner, [email-masked], 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
>>
> 
> 
> 
> .
> 

Delivery-date: Tue, 31 Aug 2004 17:02:56 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'John Drake' <[email-masked]>, [email-masked],  Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 10:01:29 -0700

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:[email-masked]]
Sent: Tuesday, August 31, 2004 8:22 AM
To: [email-masked]; Adrian Farrel
Cc: [email-masked]
Subject: RE: Communication from the OIF

Dimitri,

Excellent note.  You saved me a lot of typing.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, August 30, 2004 11:32 AM
> To: Adrian Farrel
> Cc: [email-masked]
> 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, [email-masked], IETF,
> > CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
> > IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
> > Routing Area Director Mr. Bill Fenner, [email-masked], 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
> 

Delivery-date: Tue, 31 Aug 2004 15:24:15 +0000
From: John Drake <[email-masked]>
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: RE: Communication from the OIF
Date: Tue, 31 Aug 2004 08:21:48 -0700

Dimitri,

Excellent note.  You saved me a lot of typing.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, August 30, 2004 11:32 AM
> To: Adrian Farrel
> Cc: [email-masked]
> 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, [email-masked], IETF,
> > CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
> > IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
> > Routing Area Director Mr. Bill Fenner, [email-masked], 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
> 

Delivery-date: Mon, 30 Aug 2004 20:32:09 +0000
Date: Mon, 30 Aug 2004 16:30:13 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Fw: AD-review comments on draft-ietf-ccamp-gmpls-egress-control
Cc: <[email-masked]>, "Alex Zinin" <[email-masked]>

Alex,

Lou

> > This one should be removed for the same reason.

Delivery-date: Mon, 30 Aug 2004 18:32:36 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
From: [email-masked]
Subject: Re: Communication from the OIF
Date: Mon, 30 Aug 2004 20:31:36 +0200

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, [email-masked], IETF,
> CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
> IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
> Routing Area Director Mr. Bill Fenner, [email-masked], 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

Delivery-date: Mon, 30 Aug 2004 18:12:18 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Adrian Farrel' <[email-masked]>, [email-masked]
Subject: RE: Communication from the OIF
Date: Mon, 30 Aug 2004 11:09:48 -0700

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:[email-masked]]
Sent: Saturday, August 28, 2004 4:52 AM
To: [email-masked]
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, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
Mr. Alex Zinin, [email-masked], IETF, Routing Area Director
Mr. Bill Fenner, [email-masked], 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

Delivery-date: Sat, 28 Aug 2004 22:25:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-egress-control
Date: Sat, 28 Aug 2004 23:12:30 +0100

Hi,

Thanks,
Adrian

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

> This one should be removed for the same reason.

Delivery-date: Sat, 28 Aug 2004 12:15:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Communication from the OIF
Date: Sat, 28 Aug 2004 12:51:34 +0100

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, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
Mr. Alex Zinin, [email-masked], IETF, Routing Area Director
Mr. Bill Fenner, [email-masked], 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

Delivery-date: Fri, 27 Aug 2004 14:42:35 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 25 Aug 2004 20:16:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 24 Aug 2004 18:53:46 +0000
Date: Tue, 24 Aug 2004 14:43:16 -0400
From: Ronald Bonica <[email-masked]>
Subject: RE: feedback on GTTP: draft-ietf-ccamp-tunproto-00
To: 'Richard Rabbat' <[email-masked]>, [email-masked]

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:[email-masked]]=20
Sent: Monday, August 23, 2004 5:51 PM
To: 'Ronald Bonica'; [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Monday, August 23, =
2004 5:51=20
  PM<BR><B>To:</B> 'Ronald Bonica'; [email-masked]<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)--

Delivery-date: Mon, 23 Aug 2004 21:54:28 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Ronald Bonica'" <[email-masked]>, <[email-masked]>
Cc: "'Richard Rabbat'" <[email-masked]>
Subject: feedback on GTTP: draft-ietf-ccamp-tunproto-00
Date: Mon, 23 Aug 2004 14:51:09 -0700

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

Delivery-date: Sat, 21 Aug 2004 00:38:06 +0000
Date: Fri, 20 Aug 2004 16:34:33 -0700 (PDT)
From: Greg Bernstein <[email-masked]>
Subject: A note on LMP/G.7714 (long)
To: ccamp IETF <[email-masked]>

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

Delivery-date: Fri, 20 Aug 2004 10:27:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>, "yuichi Ikejiri" <[email-masked]>
Subject: draft-vasseur-ccamp-loose-path-reopt-02.txt to WG status
Date: Fri, 20 Aug 2004 10:30:49 +0100

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

Delivery-date: Fri, 20 Aug 2004 10:27:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Jonathan Lang" <[email-masked]>
Subject: draft-aboulmagd-ccamp-transport-lmp-02.txt to WG status
Date: Fri, 20 Aug 2004 10:30:54 +0100

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

Delivery-date: Fri, 20 Aug 2004 10:27:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: New CCAMP WG drafts
Date: Fri, 20 Aug 2004 10:33:20 +0100

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)

Delivery-date: Fri, 20 Aug 2004 10:27:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>
Subject: draft-farrel-ccamp-inter-domain-framework-01.txt
Date: Fri, 20 Aug 2004 10:30:29 +0100

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

Delivery-date: Fri, 20 Aug 2004 10:27:00 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Tove Madsen" <[email-masked]>
Subject: Re: Draft minutes from San Diego
Date: Fri, 20 Aug 2004 10:20:36 +0100

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" <[email-masked]>
To: <[email-masked]>
Cc: "Tove Madsen" <[email-masked]>
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.
>
>
>
>

Delivery-date: Fri, 20 Aug 2004 10:26:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Lou Berger" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Reshad Rahman" <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, <[email-masked]>
Subject: draft-aruns-ccamp-rsvp-restart-ext-01.txt to WG status
Date: Fri, 20 Aug 2004 10:30:39 +0100

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

Delivery-date: Thu, 19 Aug 2004 17:53:39 +0000
From: Jon Berger <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: IPv6 GMPLS Traffic Engineering in IS-IS
Date: Thu, 19 Aug 2004 18:51:12 +0100

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:
	[email-masked]
(http://www.ietf.org/html.charters/isis-charter.html for subscription
instructions).

Jon

Jon Berger
Network Protocols Group
Data Connection Ltd
Tel:	  +44 20 8366 1177	
Fax:	  +44 20 8363 1039
Email:  mailto:[email-masked]
Web:    http://www.dataconnection.com

Delivery-date: Sat, 14 Aug 2004 09:35:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: A message to draft editors
Date: Fri, 13 Aug 2004 21:50:30 +0100

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

Delivery-date: Thu, 12 Aug 2004 20:36:57 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Don Fedyk'" <[email-masked]>, <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Thu, 12 Aug 2004 13:35:33 -0700

Thanks. This sounds good. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Don Fedyk
> Sent: Wednesday, August 11, 2004 8:53 PM
> To: Richard Rabbat; [email-masked]
> Cc: 'Adrian Farrel'; [email-masked]; 'Kireeti Kompella'; 
> 'Tove Madsen'
> Subject: RE: Soliciting comments on moving drafts to WG status
> 
> 
> Hi Richard
> 
> Inline
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] 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 
> 

Delivery-date: Thu, 12 Aug 2004 20:26:05 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Thu, 12 Aug 2004 13:24:47 -0700

Dimitri,
Some snipping, the rest inline.

> From: dimitri papadimitriou [mailto:[email-masked]] 
...
>
> 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. 

Delivery-date: Thu, 12 Aug 2004 20:03:10 +0000
Date: Thu, 12 Aug 2004 22:02:22 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Richard Rabbat <[email-masked]>
CC: [email-masked],  'Adrian Farrel' <[email-masked]>, [email-masked], 'Kireeti Kompella' <[email-masked]>,  'Tove Madsen' <[email-masked]>
Subject: Re: Soliciting comments on moving drafts to WG status

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)

Delivery-date: Thu, 12 Aug 2004 17:34:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Tove Madsen" <[email-masked]>
Subject: Craft minutes from San Diego
Date: Thu, 12 Aug 2004 18:31:26 +0100

>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: [email-masked]
Delivery-date: Thu, 12 Aug 2004 03:54:15 +0000
Message-ID: <[email-masked]>
From: "Don Fedyk" <[email-masked]>
To: Richard Rabbat <[email-masked]>, [email-masked]
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
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: [email-masked] 
> [mailto:[email-masked]] 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 

Delivery-date: Thu, 12 Aug 2004 03:04:01 +0000
Date: Wed, 11 Aug 2004 20:04:04 -0700
To: "Richard Rabbat" <[email-masked]>, [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Cc: <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>

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: [email-masked]
Delivery-date: Thu, 12 Aug 2004 02:50:44 +0000
Message-ID: <[email-masked]>
From: "Don Fedyk" <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: "'Kireeti Kompella'" <[email-masked]>, Tove Madsen <[email-masked]>
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:[email-masked]] 
> Sent: Tuesday, August 10, 2004 8:52 AM
> To: [email-masked]
> 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).
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 11 Aug 2004 22:29:10 +0000
Date: Wed, 11 Aug 2004 15:27:03 -0700 (PDT)
From: Greg Bernstein <[email-masked]>
Subject: Re: Soliciting comments on moving drafts to WG status
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: 'Kireeti Kompella' <[email-masked]>, Tove Madsen <[email-masked]>

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

Delivery-date: Wed, 11 Aug 2004 19:29:27 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 12:28:26 -0700

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.

Delivery-date: Wed, 11 Aug 2004 18:55:03 +0000
To: "Richard Rabbat" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
From: [email-masked]
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 20:54:08 +0200

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]

Delivery-date: Wed, 11 Aug 2004 18:39:02 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Dimitri Papadimitriou" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Re-opt [Was: Re: Soliciting comments on moving drafts to WG status]
Date: Wed, 11 Aug 2004 18:52:47 +0100

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

Delivery-date: Wed, 11 Aug 2004 18:22:52 +0000
From: John Drake <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: 'Kireeti Kompella' <[email-masked]>, Tove Madsen <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 11:22:05 -0700

Yes to all

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2004 5:52 AM
> To: [email-masked]
> 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).
> 
> 
> 

Delivery-date: Wed, 11 Aug 2004 18:20:57 +0000
content-class: urn:content-classes:message
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 13:19:56 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Tove Madsen" <[email-masked]>

Yes to all-
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, August 10, 2004 8:52 AM
To: [email-masked]
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).

Delivery-date: Wed, 11 Aug 2004 17:30:58 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Wed, 11 Aug 2004 10:28:14 -0700

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.

Delivery-date: Wed, 11 Aug 2004 07:40:15 +0000
Date: Wed, 11 Aug 2004 09:36:37 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked], 'Kireeti Kompella' <[email-masked]>,  Tove Madsen <[email-masked]>
Subject: Re: Soliciting comments on moving drafts to WG status

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

Delivery-date: Wed, 11 Aug 2004 04:41:56 +0000
Date: Tue, 10 Aug 2004 21:28:02 -0700
To: "Adrian Farrel" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Soliciting comments on moving drafts to WG status
Cc: <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>

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

Delivery-date: Wed, 11 Aug 2004 02:16:10 +0000
content-class: urn:content-classes:message
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 21:14:14 -0500
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>

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

Yes to all.

Jerry

Delivery-date: Tue, 10 Aug 2004 17:47:39 +0000
From: "zafar ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
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

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, August 10, 2004 1:13 PM
>To: zafar ali; [email-masked]
>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
>
>

Delivery-date: Tue, 10 Aug 2004 17:30:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "zafar ali" <[email-masked]>, <[email-masked]>
Subject: LMP transport [Was: Re: Soliciting comments on moving drafts to WG status]
Date: Tue, 10 Aug 2004 18:13:24 +0100

> 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: [email-masked]
Delivery-date: Tue, 10 Aug 2004 17:23:57 +0000
Message-ID: <[email-masked]>
From: "Don Fedyk" <[email-masked]>
To: [email-masked], [email-masked], zafar ali <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
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:[email-masked]] 
> Sent: Tuesday, August 10, 2004 1:05 PM
> To: zafar ali
> Cc: 'Adrian Farrel'; [email-masked]; '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>

Delivery-date: Tue, 10 Aug 2004 17:17:34 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 13:17:31 -0400
Organization: Cisco Systems

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: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of dimitri papadimitriou
>Sent: Tuesday, August 10, 2004 1:05 PM
>To: zafar ali
>Cc: 'Adrian Farrel'; [email-masked]; '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: [email-masked]
>>>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>>>Sent: Tuesday, August 10, 2004 8:52 AM
>>>To: [email-masked]
>>>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
>

Delivery-date: Tue, 10 Aug 2004 17:07:28 +0000
Date: Tue, 10 Aug 2004 19:05:24 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: zafar ali <[email-masked]>
CC: 'Adrian Farrel' <[email-masked]>,  [email-masked],  'Kireeti Kompella' <[email-masked]>, 'Tove Madsen' <[email-masked]>
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
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>>Sent: Tuesday, August 10, 2004 8:52 AM
>>To: [email-masked]
>>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).
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 

Delivery-date: Tue, 10 Aug 2004 15:44:06 +0000
From: "zafar ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "'Tove Madsen'" <[email-masked]>
Subject: RE: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 11:44:13 -0400
Organization: Cisco Systems

"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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, August 10, 2004 8:52 AM
>To: [email-masked]
>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).
>
>
>
>
>

Delivery-date: Tue, 10 Aug 2004 15:40:43 +0000
Content-class: urn:content-classes:message
Subject: RE : Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 17:39:07 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Tove Madsen" <[email-masked]>

Hi Adrian and all,

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

Regards,

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Adrian Farrel
>Envoy=E9 : mardi 10 ao=FBt 2004 14:52
>=C0 : [email-masked]
>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).
>
>
>
>
>
>

Delivery-date: Tue, 10 Aug 2004 15:40:28 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Re: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 11:39:00 -0400

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

Delivery-date: Tue, 10 Aug 2004 15:19:18 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Soliciting comments on moving drafts to WG status
Date: Tue, 10 Aug 2004 13:52:02 +0100

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

Delivery-date: Fri, 06 Aug 2004 19:34:44 +0000
Date: Fri, 6 Aug 2004 12:33:27 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re-chartering effort

Hi All,

Please send Adrian, Tove ([email-masked]) 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.
-------

Delivery-date: Fri, 06 Aug 2004 19:28:05 +0000
Date: Fri, 6 Aug 2004 12:24:51 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP Secretary

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

Delivery-date: Fri, 06 Aug 2004 15:26:14 +0000
From: "Yumiko kawashima" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Clarification about Link Protection Type (gmpls-routing-09.txt)
Date: Sat, 7 Aug 2004 00:19:28 +0900

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.

Delivery-date: Thu, 05 Aug 2004 18:06:14 +0000
Date: Thu, 5 Aug 2004 14:04:28 -0400 (EDT)
From: Arun Satyanarayana <[email-masked]>
Reply-To: <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: Lou Berger <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, Reshad Rahman <[email-masked]>, 'Anca Zamfir' <[email-masked]>, <[email-masked]>, <[email-masked]>, Arun Satyanarayan <[email-masked]>
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-01.txt

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.

Delivery-date: Thu, 05 Aug 2004 16:55:33 +0000
Date: Thu, 05 Aug 2004 09:53:47 -0700
To: lidefeng <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: PCE BOF - Thursday August 5, 13:00 to 15:00
Cc: [email-masked], [email-masked], TEWG <[email-masked]>, [email-masked], [email-masked], [email-masked], Bill Fenner <[email-masked]>

--=====================_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
>From: <mailto:[email-masked]>Jean Philippe Vasseur
>To: <mailto:[email-masked]>[email-masked] ; 
><mailto:[email-masked]>[email-masked] ; <mailto:[email-masked]>TEWG ; 
><mailto:[email-masked]>[email-masked]
>Cc: <mailto:[email-masked]>[email-masked] ; 
><mailto:[email-masked]>[email-masked] ; <mailto:[email-masked]>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:[email-masked]>[email-masked]),
>Bill Fenner (<mailto:[email-masked]>[email-masked])
>
>BOF Chairs: JP Vasseur (<mailto:[email-masked]>[email-masked]), 
>Adrian Farrel (<mailto:[email-masked]>[email-masked])
>
>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:[email-masked]">Jean Philippe
Vasseur</a> 
<dd>To:</b> <a href="mailto:[email-masked]">[email-masked]</a> ;
<a href="mailto:[email-masked]">[email-masked]</a> ;
<a href="mailto:[email-masked]">TEWG</a> ;
<a href="mailto:[email-masked]">[email-masked]</a> 
<dd>Cc:</b> <a href="mailto:[email-masked]">[email-masked]</a>
; <a href="mailto:[email-masked]">[email-masked]</a> ; <a href="mailto:[email-masked]">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:[email-masked]">[email-masked]</a>), 
<dd>Bill Fenner (<a href="mailto:[email-masked]">[email-masked]</a>)<br>
<br>

<dd>BOF Chairs: JP Vasseur (<a href="mailto:[email-masked]">[email-masked]</a>), Adrian Farrel (<a href="mailto:[email-masked]">[email-masked]</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--

Delivery-date: Thu, 05 Aug 2004 16:22:32 +0000
Date: Thu, 05 Aug 2004 09:20:19 -0800
To: [email-masked]
Subject: RE: Text message
From: [email-masked]

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

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

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

Delivery-date: Thu, 05 Aug 2004 00:55:10 +0000
Date: Thu, 05 Aug 2004 08:53:27 +0800
From: lidefeng <[email-masked]>
Subject: Re: PCE BOF - Thursday August 5, 13:00 to 15:00
To: Jean Philippe Vasseur <[email-masked]>, [email-masked], [email-masked], TEWG <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], Bill Fenner <[email-masked]>

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: [email-masked] ; [email-masked] ; TEWG ; [email-masked] 
  Cc: [email-masked] ; [email-masked] ; 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 ([email-masked]), 
  Bill Fenner ([email-masked])

  BOF Chairs: JP Vasseur ([email-masked]), Adrian Farrel ([email-masked])

  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=[email-masked] href="mailto:[email-masked]">Jean Philippe 
  Vasseur</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">TEWG</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">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:[email-masked]">[email-masked]</A>), <BR>Bill Fenner (<A 
  href="mailto:[email-masked]">[email-masked]</A>)<BR><BR>BOF 
  Chairs: JP Vasseur (<A 
  href="mailto:[email-masked]">[email-masked]</A>), Adrian Farrel (<A 
  href="mailto:[email-masked]">[email-masked]</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)--

Delivery-date: Wed, 04 Aug 2004 16:35:24 +0000
Date: Wed, 04 Aug 2004 23:55:40 +0900
To: [email-masked], [email-masked]
From: Nagao Ogino <[email-masked]>
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt
Cc: [email-masked]

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. 

Delivery-date: Tue, 03 Aug 2004 18:59:30 +0000
Date: Tue, 3 Aug 2004 11:57:53 -0700 (PDT)
From: Greg Bernstein <[email-masked]>
Subject: Agenda, LMP for Transport
To: Adrian Farrel <[email-masked]>, [email-masked]

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

Delivery-date: Tue, 03 Aug 2004 08:22:17 +0000
Subject: Re: Agenda and slides
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
From: [email-masked]
Date: Tue, 3 Aug 2004 10:19:40 +0200

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: [email-masked]
tel : +39 039 686 3033
fax: +39 039 686 3590

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

Delivery-date: Tue, 03 Aug 2004 01:02:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Alessio D'Achille" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Vishal Sharma" <[email-masked]>, "Ugo Monaco" <[email-masked]>, "Fabio Ricciato" <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: Re: Diverse inter-region path setup
Date: Tue, 3 Aug 2004 01:58:39 +0100

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Kireeti Kompella" <[email-masked]>; "Vishal Sharma"
<[email-masked]>; "Ugo Monaco" <[email-masked]>; "Fabio Ricciato"
<[email-masked]>; "Marco Listanti" <[email-masked]>
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>
>

Delivery-date: Mon, 02 Aug 2004 21:12:05 +0000
From: "Alessio D'Achille" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Vishal Sharma" <[email-masked]>, "Ugo Monaco" <[email-masked]>, "Fabio Ricciato" <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: Diverse inter-region path setup
Date: Mon, 2 Aug 2004 23:11:35 +0200

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

Delivery-date: Mon, 02 Aug 2004 20:59:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>
Subject: Agenda and slides for PCE BOF
Date: Mon, 2 Aug 2004 21:56:52 +0100

Hi,

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

Please browse.

Adrian

Delivery-date: Mon, 02 Aug 2004 20:50:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda and slides
Date: Mon, 2 Aug 2004 21:48:22 +0100

Hi,

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

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

Adrian

Delivery-date: Mon, 02 Aug 2004 04:22:28 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "CCAMP" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Richard Rabbat" <[email-masked]>, "Takeo Hamada" <[email-masked]>, <[email-masked]>
Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt  [Was RE: Survey draft]
Date: Sun, 1 Aug 2004 21:18:55 -0700

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:[email-masked]]
> Sent: Saturday, July 24, 2004 10:40 AM
> To: [email-masked]
> Cc: 'Kireeti Kompella'; Richard Rabbat; Takeo Hamada; [email-masked]
> 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:[email-masked]]
> > > 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
> > >
> >
> >
>

Delivery-date: Sun, 01 Aug 2004 05:21:01 +0000
Date: Sun, 01 Aug 2004 01:07:35 -0400
To: <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>, <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: PCE BOF - Thursday August 5, 13:00 to 15:00
Cc: [email-masked], [email-masked], Bill Fenner <[email-masked]>

--=====================_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 ([email-masked]),
Bill Fenner ([email-masked])

BOF Chairs: JP Vasseur ([email-masked]), Adrian Farrel 
([email-masked])

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 ([email-masked]), <br>
Bill Fenner ([email-masked])<br>
<br>
BOF Chairs: JP Vasseur ([email-masked]), Adrian Farrel
([email-masked])<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--