Subject: I-D ACTION:draft-ietf-tewg-interas-mpls-te-req-04.txt

From: [email-masked] (by way of raymond zhang <[email-masked]>)
Date: Fri, 16 Jan 2004 10:56:06 -0800

Hi Jim and Ed,

Here is the most updated one.  Would you please initiate the WG last call 
for this draft ?

Thanks,
Raymond

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Traffic Engineering Working Group 
of the IETF.

	Title		: MPLS Inter-AS Traffic Engineering requirements
	Author(s)	: R. Zhang, J. Vasseur
	Filename	: draft-ietf-tewg-interas-mpls-te-req-04.txt
	Pages		: 26
	Date		: 2004-1-14
	
This document discusses requirements for the support of inter-AS
MPLS Traffic Engineering (MPLS TE).  The main objective of this
document is to present a set of requirements which would result in
a set of general guidelines in the definition, selection and
specification development for any technical solution(s) meeting
these requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-04.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-tewg-interas-mpls-te-req-04.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-tewg-interas-mpls-te-req-04.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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-tewg-interas-mpls-te-req-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-04.txt>

---

From: raymond zhang <[email-masked]>
Date: Mon, 19 Jan 2004 13:38:20 -0800

Hi Yakov,

At 12:59 PM 1/19/2004 -0800, Yakov Rekhter wrote:
>Raymond,
>This draft still doesn't include some of the changes you agreed to make
>in your e-mail on Jan 12 (the e-mail is attached).
>
>Specifically, it doesn't include the changes you agreed to make
>to 5.1.5, and it didn't list forwarding plane overhead in the
>list of criteria in 6.2.

[snip..]
> >3. Section 6.2 ("Performance") should include control plane overhead
> >as one of the criteria. Ditto for data plane overhead.
>
>Will do, thanks.
[snip..]

I see... I interpreted "ditto" as "ok" above, meaning no additional changes 
required regarding data plane.

Can you propose some wording which can be incorporated into the final 
version after the last call commenting period ?

Regards,
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 19 Jan 2004 12:59:03 -0800

Raymond,

Yakov.
-----------------------------------------------------------------------
Date:    Mon, 12 Jan 2004 09:23:41 PST
To:      Yakov Rekhter <[email-masked]>
cc:      Jim Boyle <[email-masked]>, Ed Kern <[email-masked]>,
	 "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
From:    raymond zhang <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-ietf-tewg-interas-mpls-te-req-03.txt 

Hi Yakov,

Thanks for the additional input...

At 08:28 AM 1/12/2004 -0800, Yakov Rekhter wrote:
>Raymond,
>
> > Hi Jim and Ed,
> >
> > Happy new year !
> >
> > The following emails were sent to both of you nearly a month ago.  I am 
> not
> > sure if you are having problem receiving email again so I am copying Bert
> > and posting to the list also.
> >
> > The -03 version of the draft
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-03.t
>xt)
> > is ready for last call as per our minutes from the Minneapolis meeting.
>
>I think that the latest version of the draft still require few
>changes/updates.
>
>1. The document should state up front the following:
>
>       This document doesn't make any claims with respect to whether
>       it is possible to have a practical solution that meets all the
>       requirements listed in this document.
>
>(That point have been discussed before, and I thought the authors
>agreed to include the above in the text, but I wasn't able to find
>it in the -03 version).

In section 6.1, I included wording "

If a solution can fulfill just a subset of those requirements in
    section 5, then it MUST be explicitly documented"

Would this reflect your point above ?

>2. From 5.1.5 ("Re-optimization"):
>
>    Once an inter-AS TE LSP has been established and should there be any
>    resource or other changes inside anyone of transiting ASes, the
>    solution MUST be able to re-optimize the LSP accordingly and
>    non-disruptively, either upon expiration of a configurable timer or
>    triggered by a network event or a manual request at the TE tunnel
>    Head-end.
>
>    The solution SHOULD provide an option for the Head-End LSRs to
>    control if re-optimizing or not should there exist a more optimal
>    path in one of the transit ASes along the inter-AS TE LSP path.
>
>The above it too restrictive, as it restricts re-optimization to
>only the case where resource changes are in the set of ASs (currently)
>transited by the LSP. To remove this restriction I'd like to propose the
>following replacement:
>
>    Once an inter-AS TE LSP has been established and should there be any
>    resource or other changes inside anyone of the ASes, the
>    solution MUST be able to re-optimize the LSP accordingly and
>    non-disruptively, either upon expiration of a configurable timer or
>    triggered by a network event or a manual request at the TE tunnel
>    Head-end.
>
>    The solution SHOULD provide an option for the Head-End LSRs to
>    control if re-optimizing or not should there exist a more optimal
>    path in one of the ASes.

"along the inter-AS TE LSP path" was left there by mistake, sorry...  As 
per our last discussion, the text should appear exactly the same as you 
proposed above.  Thanks for catching it !

Will do, thanks.

>4. In 5.1.6 replace "CSPF" with "Path computation").

You meant 5.1.8 ?  Will do...

Cheers,
Raymond
>Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Jan 2004 07:04:55 -0800

Raymond,

> version after the last call commenting period ?

Here is the proposed text, although I think that the text has to be
incorporated *prior* (and not after) the last call commenting period.

In  5.1.5 replace

with the following:

In 6.2 add the following:

    - Impact and scalability of the data/forwarding plane due to added
        overheads, etc.

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Tue, 20 Jan 2004 11:43:26 -0800

Hi Yakov,

>incorporated *prior* (and not after) the last call commenting period.

Surely.. I will post -05 for it.

>     path in one of the transit ASes along the inter-AS TE LSP path.

This was the text in -03...  In -04, I have updated the text to the following:

"
The solution SHOULD provide an option for the Head-End LSRs to
    control if re-optimizing or not should there exist a more optimal
    path in one of the transit ASes."

>     control if re-optimizing or not should there exist a more optimal

But I have not problem with proposed above either (one word difference 
"transit as")

>     - Impact and scalability of the data/forwarding plane due to added

thanks !

Cheers,
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Jan 2004 12:03:13 -0800

Raymond,

> But I have not problem with proposed above either (one word difference 

Great !!!

> >     - Impact and scalability of the data/forwarding plane due to added

Looking forward for the -05 version.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Jan 2004 07:13:15 -0800

Raymond,

[clipped..]

> >     control if re-optimizing or not should there exist a more optimal

I am quite suprprised (to say the least) that after you agreed with
the change I proposed to 5.1.5, the -05 version still has doesn't fully 
incorporate that change. Specifically, the first sentence in 5.1.5 is 
still from the old text. 

Yakov.