Subject: It turns out that although at first blush it looks like a very nice, simple mapping, care must be taken not to repeat past mistakes.

From: "Phil Rutherford" <[email-masked]>
Date: Mon, 30 Apr 2007 23:45:14 +0200

CDPN Really Warming Up!

China Datacom Corp.
Sym: CDPN
Close: $0.0675 UP 4%

Investors are taking notice of CDPN, with hot news, volume rising, and
price on a steady climb. This is is on the hot list. Get on CDPN first
thing Tuesday!

0, including a revamped editor that's faster than ever and includes
semantic highlighting.
Java 3D will fall back to D3D on Windows if OpenGL 1. "This is a
familiar theme in programming languages: a theoretical capability runs
afoul of implementation realities.
That's not very nice. In my case the terrain is specified by an
irregular set of Point3f for which I have a tesselation as a triangle
array.
We will talk more in the coming Java 3D BOF at JavaOne. I see a lot of
that from other channels, notably the weblogs, but some things have been
slipping through the cracks, so let's try to catch up with today's daily
blog.
net Poll asks  "How should JSR expert groups typically conduct their
work?
The JSR will be resubmitted when the TCK licensing terms are clarified.
In my case the terrain is specified by an irregular set of Point3f for
which I have a tesselation as a triangle array.

Delivery-date: Mon, 30 Apr 2007 17:38:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Three liaison statements received from the ITU-T Study Group 15 Question 14
Date: Mon, 30 Apr 2007 18:36:05 +0100
Organization: Old Dog Consulting

Greg,

That would be admirable.

Thanks!

Adrian
----- Original Message ----- 
From: "Greg Bernstein" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 30, 2007 5:06 PM
Subject: Re: Three liaison statements received from the ITU-T Study Group 15 
Question 14

> Hi Adrian, I see they have a slew of questions on the VCAT/LCAS draft. 
> What is the proper procedure for generating a response? Do I, as editor, 
> take a first shot and then send to the list. Then we take it from there 
> (if we get any responses).
> Regards
>
> Greg B.
>
>
>
> Adrian Farrel wrote:
>> Hi,
>>
>> At their meeting in Chicago earlier this month, Q14/15 generated three 
>> responses to our liaisons.
>>
>> You can see these at www.olddog.co.uk/ccamp.htm or on the IETF liaison 
>> page as follows:
>>
>> Liaison Statement to IETF CCAMP on Call/Connection Separation in ASON and 
>> GMPLS
>> https://datatracker.ietf.org/documents/LIAISON/file420.doc
>>
>> Liaison Statement to IETF CCAMP on Multi-Layer Networking
>> https://datatracker.ietf.org/documents/LIAISON/file419.doc
>>
>> Liaison Statement to IETF CCAMP on VCAT/LCAS Signalling
>> https://datatracker.ietf.org/documents/LIAISON/file418.doc
>>
>> The third of these is for Action and needs a response from us by 28th May 
>> 2007
>>
>> Adrian
>>
>>
>>
>>
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> 

Delivery-date: Mon, 30 Apr 2007 16:07:59 +0000
Date: Mon, 30 Apr 2007 09:06:33 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Three liaison statements received from the ITU-T Study Group 15 Question 14

Hi Adrian, I see they have a slew of questions on the VCAT/LCAS draft.  
What is the proper procedure for generating a response? Do I, as editor, 
take a first shot and then send to the list. Then we take it from there 
(if we get any responses).
Regards

Greg B.

Adrian Farrel wrote:
> Hi,
>
> At their meeting in Chicago earlier this month, Q14/15 generated three 
> responses to our liaisons.
>
> You can see these at www.olddog.co.uk/ccamp.htm or on the IETF liaison 
> page as follows:
>
> Liaison Statement to IETF CCAMP on Call/Connection Separation in ASON 
> and GMPLS
> https://datatracker.ietf.org/documents/LIAISON/file420.doc
>
> Liaison Statement to IETF CCAMP on Multi-Layer Networking
> https://datatracker.ietf.org/documents/LIAISON/file419.doc
>
> Liaison Statement to IETF CCAMP on VCAT/LCAS Signalling
> https://datatracker.ietf.org/documents/LIAISON/file418.doc
>
> The third of these is for Action and needs a response from us by 28th 
> May 2007
>
> Adrian
>
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Mon, 30 Apr 2007 15:04:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Polling for WG adoption of draft-chen-ccamp-ospf-interas-te-extension-02.txt
Date: Mon, 30 Apr 2007 16:00:08 +0100
Organization: Old Dog Consulting

Hi,

In Prague we discussed this draft and the general opinion seemed to be that 
this is a useful extension, but that some clarifications needed to be added 
to the I-D. This new revision appears to address all of the concerns as 
below.

Therefore given the interest in Prague and the relevance of this I-D to our 
inter-domain TE charter actions, we are polling the WG for adoption of this 
I-D as a CCAMP draft.

Opinions please.

Thanks
Adrian and Deborah

====
Overlap with L1VPN autodiscovery

    A question was raised as to whether there was an overlap
    with the L1VPN autodiscovery work used to distribute
    membership information (draft-ietf-l1vpn-ospf-auto-discovery)

    It appears that the mechanisms and purposes are different.

    The authors have added text to clarify that there is no overlap.

Language change for "OSPF" becomes "OSPF-TE"

    Concern was raised that the I-D talked about "OSPF" but the
    function is "OSPF-TE".

    The authors have updated the I-D accordingly.

Include reference to OSPFv3 as well

    A request was made to include OSPFv3.

    The authors have added text to explain that the same extensions
    apply to OSPF v2 and OSPF v3 TE extensions.

Make it *incredibly* clear that TE distribution between ASes is
not in scope.

    Although the I-D had plenty of this material, the authors have
    beefed it up further by including the list of things that they are
    not doing from their Prague slides.

Delivery-date: Sun, 29 Apr 2007 22:00:49 +0000
Content-class: urn:content-classes:message
Subject: Shepherd write-up for draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
Date: Sun, 29 Apr 2007 17:00:09 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Ross Callon" <[email-masked]>, "David Ward" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78AA9.C1E25625
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please publish draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt

Please progress this I-D in parallel with=20

draft-ietf-ccamp-lsp-stitching-06.txt and=20

draft-ietf-ccamp-inter-domain-rsvp-te-06.txt

Here is the Document Shepherd write-up.

(1.a) Who is the Document Shepherd for this document?

Deborah Brungard <[email-masked]>

Has the Document Shepherd personally reviewed this version

of the document and, in particular, does he or she believe

this version is ready for forwarding to the IESG for

publication?

Yes

(1.b) Has the document had adequate review both from key WG

members and from key non-WG members?

Yes

Does the Document Shepherd have any concerns about the

depth or breadth of the reviews that have been performed?

No concerns.

(1.c) Does the Document Shepherd have concerns that the document

needs more review from a particular or broader perspective,

e.g., security, operational complexity, someone familiar

with AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or

issues with this document that the Responsible Area

Director and/or the IESG should be aware of? For example,

perhaps he or she is uncomfortable with certain parts of

the document, or has concerns whether there really is a

need for it. In any event, if the WG has discussed those

issues and has indicated that it still wishes to advance

the document, detail those concerns here.

No concerns.

Has an IPR disclosure related to this document

been filed? If so, please include a reference to the

disclosure and summarize the WG discussion and conclusion

on this issue.

None has been filed.

(1.e) How solid is the WG consensus behind this document? Does

it represent the strong concurrence of a few individuals,

with others being silent, or does the WG as a whole

understand and agree with it?

WG agrees.

(1.f) Has anyone threatened an appeal or otherwise indicated

extreme discontent? If so, please summarise the areas of

conflict in separate email messages to the Responsible Area

Director. (It should be in a separate email because this

questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits? (See

http://www.ietf.org/ID-Checklist.html
<http://www.ietf.org/ID-Checklist.html>  and

http://tools.ietf.org/tools/idnits/
<http://tools.ietf.org/tools/idnits/> ). Boilerplate checks

are not enough; this check needs to be thorough.

Yes.

Has the document met all formal review criteria it needs

to, such as the MIB Doctor, media type and URI type

reviews?

Yes.

(1.h) Has the document split its references into normative and

informative?

Yes.

Are there normative references to documents that

are not ready for advancement or are otherwise in an

unclear state? If such normative references exist, what is

the strategy for their completion?

All OK.

Are there normative references that are downward

references, as described in [RFC3967]? If so, list these

downward references to support the Area Director in the

Last Call procedure for them [RFC3967].

No.

(1.i) Has the Document Shepherd verified that the document IANA

consideration section exists and is consistent with the

body of the document? If the document specifies protocol

extensions, are reservations requested in appropriate IANA

registries? Are the IANA registries clearly identified?

If the document creates a new registry, does it define the

proposed initial contents of the registry and an allocation

procedure for future registrations? Does it suggest a

reasonable name for the new registry? See [RFC2434].

Yes to all above.

If the document describes an Expert Review process has

Shepherd conferred with the Responsible Area Director so

that the IESG can appoint the needed Expert during the IESG

Evaluation?

None required.

(1.j) Has the Document Shepherd verified that sections of the

document that are written in a formal language, such as XML

code, BNF rules, MIB definitions, etc., validate correctly

in an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document

Announcement Write-Up. Please provide such a Document

Announcement Write-Up? Recent examples can be found in the

"Action" announcements for approved documents. The

approval announcement contains the following sections:

Technical Summary

This document specifies a per-domain path computation technique for

establishing inter-domain Traffic Engineering (TE) Multiprotocol

Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched

Paths (LSPs). In this document a domain refers to a collection of

network elements within a common sphere of address management or path

computational responsibility such as IGP areas and Autonomous

Systems.

Per-domain computation applies where the full path of an inter-domain

TE LSP cannot be or is not determined at the ingress node of the TE

LSP, and is not signaled across domain boundaries. This is most

likely to arise owing to TE visibility limitations. The signaling

message indicates the destination and nodes up to the next domain

boundary. It may also indicate further domain boundaries or domain

identifiers. The path through each domain, possibly including the

choice of exit point from the domain, must be determined within

the domain.

Working Group Summary

The Working Group had consensus on this document.

Document Quality

The document has been implemented and deployed.

Personnel

Who is the Document Shepherd for this document?

Deborah Brungard

Who is the Responsible Area Director(s)?

Ross Callon, David Ward.

Is an IANA expert needed?

No.

------_=_NextPart_001_01C78AA9.C1E25625
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT face=3DArial size=3D2>Please publish=20
draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt</FONT></P>
<P><FONT face=3DArial size=3D2>Please progress this I-D in parallel with =
</FONT></P>
<P><FONT face=3DArial size=3D2>draft-ietf-ccamp-lsp-stitching-06.txt and =
</FONT></P>
<P><FONT face=3DArial=20
size=3D2>draft-ietf-ccamp-inter-domain-rsvp-te-06.txt</FONT></P>
<P><FONT face=3DArial size=3D2>Here is the Document Shepherd =
write-up.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.a) Who is the Document Shepherd for =
this=20
document?</FONT></P>
<P><SPAN class=3D429025221-29042007><FONT face=3DArial size=3D2>Deborah =
Brungard=20
&lt;[email-masked]&gt;</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2>Has the Document Shepherd personally =
reviewed this=20
version</FONT></P>
<P><FONT face=3DArial size=3D2>of the document and, in particular, does =
he or she=20
believe</FONT></P>
<P><FONT face=3DArial size=3D2>this version is ready for forwarding to =
the IESG=20
for</FONT></P>
<P><FONT face=3DArial size=3D2>publication?</FONT></P>
<P><FONT face=3DArial size=3D2>Yes</FONT></P>
<P><FONT face=3DArial size=3D2>(1.b) Has the document had adequate =
review both from=20
key WG</FONT></P>
<P><FONT face=3DArial size=3D2>members and from key non-WG =
members?</FONT></P>
<P><FONT face=3DArial size=3D2>Yes</FONT></P>
<P><FONT face=3DArial size=3D2>Does the Document Shepherd have any =
concerns about=20
the</FONT></P>
<P><FONT face=3DArial size=3D2>depth or breadth of the reviews that have =
been=20
performed?</FONT></P>
<P><FONT face=3DArial size=3D2>No concerns.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.c) Does the Document Shepherd have =
concerns that=20
the document</FONT></P>
<P><FONT face=3DArial size=3D2>needs more review from a particular or =
broader=20
perspective,</FONT></P>
<P><FONT face=3DArial size=3D2>e.g., security, operational complexity, =
someone=20
familiar</FONT></P>
<P><FONT face=3DArial size=3D2>with AAA, internationalization or =
XML?</FONT></P>
<P><FONT face=3DArial size=3D2>No concerns.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.d) Does the Document Shepherd have any =
specific=20
concerns or</FONT></P>
<P><FONT face=3DArial size=3D2>issues with this document that the =
Responsible=20
Area</FONT></P>
<P><FONT face=3DArial size=3D2>Director and/or the IESG should be aware =
of? For=20
example,</FONT></P>
<P><FONT face=3DArial size=3D2>perhaps he or she is uncomfortable with =
certain parts=20
of</FONT></P>
<P><FONT face=3DArial size=3D2>the document, or has concerns whether =
there really is=20
a</FONT></P>
<P><FONT face=3DArial size=3D2>need for it. In any event, if the WG has =
discussed=20
those</FONT></P>
<P><FONT face=3DArial size=3D2>issues and has indicated that it still =
wishes to=20
advance</FONT></P>
<P><FONT face=3DArial size=3D2>the document, detail those concerns =
here.</FONT></P>
<P><FONT face=3DArial size=3D2>No concerns.</FONT></P>
<P><FONT face=3DArial size=3D2>Has an IPR disclosure related to this=20
document</FONT></P>
<P><FONT face=3DArial size=3D2>been filed? If so, please include a =
reference to=20
the</FONT></P>
<P><FONT face=3DArial size=3D2>disclosure and summarize the WG =
discussion and=20
conclusion</FONT></P>
<P><FONT face=3DArial size=3D2>on this issue.</FONT></P>
<P><FONT face=3DArial size=3D2>None has been filed.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.e) How solid is the WG consensus =
behind this=20
document? Does</FONT></P>
<P><FONT face=3DArial size=3D2>it represent the strong concurrence of a =
few=20
individuals,</FONT></P>
<P><FONT face=3DArial size=3D2>with others being silent, or does the WG =
as a=20
whole</FONT></P>
<P><FONT face=3DArial size=3D2>understand and agree with it?</FONT></P>
<P><FONT face=3DArial size=3D2>WG agrees.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.f) Has anyone threatened an appeal or =
otherwise=20
indicated</FONT></P>
<P><FONT face=3DArial size=3D2>extreme discontent? If so, please =
summarise the areas=20
of</FONT></P>
<P><FONT face=3DArial size=3D2>conflict in separate email messages to =
the=20
Responsible Area</FONT></P>
<P><FONT face=3DArial size=3D2>Director. (It should be in a separate =
email because=20
this</FONT></P>
<P><FONT face=3DArial size=3D2>questionnaire is entered into the ID=20
Tracker.)</FONT></P>
<P><FONT face=3DArial size=3D2>No.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.g) Has the Document Shepherd =
personally verified=20
that the</FONT></P>
<P><FONT face=3DArial size=3D2>document satisfies all ID nits? =
(See</FONT></P>
<P><A href=3D"http://www.ietf.org/ID-Checklist.html"><U><FONT =
color=3D#0000ff><FONT=20
face=3DArial=20
size=3D2>http://www.ietf.org/ID-Checklist.html</FONT></U></FONT></A><FONT=
=20
face=3DArial size=3D2> and</FONT></P>
<P><A href=3D"http://tools.ietf.org/tools/idnits/"><U><FONT =
color=3D#0000ff><FONT=20
face=3DArial =
size=3D2>http://tools.ietf.org/tools/idnits/</FONT></U></FONT></A><FONT=20
face=3DArial size=3D2>). Boilerplate checks</FONT></P>
<P><FONT face=3DArial size=3D2>are not enough; this check needs to be=20
thorough.</FONT></P>
<P><FONT face=3DArial size=3D2>Yes.</FONT></P>
<P><FONT face=3DArial size=3D2>Has the document met all formal review =
criteria it=20
needs</FONT></P>
<P><FONT face=3DArial size=3D2>to, such as the MIB Doctor, media type =
and URI=20
type</FONT></P>
<P><FONT face=3DArial size=3D2>reviews?</FONT></P>
<P><FONT face=3DArial size=3D2>Yes.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.h) Has the document split its =
references into=20
normative and</FONT></P>
<P><FONT face=3DArial size=3D2>informative?</FONT></P>
<P><FONT face=3DArial size=3D2>Yes.</FONT></P>
<P><FONT face=3DArial size=3D2>Are there normative references to =
documents=20
that</FONT></P>
<P><FONT face=3DArial size=3D2>are not ready for advancement or are =
otherwise in=20
an</FONT></P>
<P><FONT face=3DArial size=3D2>unclear state? If such normative =
references exist,=20
what is</FONT></P>
<P><FONT face=3DArial size=3D2>the strategy for their =
completion?</FONT></P>
<P><FONT face=3DArial size=3D2>All OK.</FONT></P>
<P><FONT face=3DArial size=3D2>Are there normative references that are=20
downward</FONT></P>
<P><FONT face=3DArial size=3D2>references, as described in [RFC3967]? If =
so, list=20
these</FONT></P>
<P><FONT face=3DArial size=3D2>downward references to support the Area =
Director in=20
the</FONT></P>
<P><FONT face=3DArial size=3D2>Last Call procedure for them =
[RFC3967].</FONT></P>
<P><FONT face=3DArial size=3D2>No.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.i) Has the Document Shepherd verified =
that the=20
document IANA</FONT></P>
<P><FONT face=3DArial size=3D2>consideration section exists and is =
consistent with=20
the</FONT></P>
<P><FONT face=3DArial size=3D2>body of the document? If the document =
specifies=20
protocol</FONT></P>
<P><FONT face=3DArial size=3D2>extensions, are reservations requested in =
appropriate=20
IANA</FONT></P>
<P><FONT face=3DArial size=3D2>registries? Are the IANA registries =
clearly=20
identified?</FONT></P>
<P><FONT face=3DArial size=3D2>If the document creates a new registry, =
does it=20
define the</FONT></P>
<P><FONT face=3DArial size=3D2>proposed initial contents of the registry =
and an=20
allocation</FONT></P>
<P><FONT face=3DArial size=3D2>procedure for future registrations? Does =
it suggest=20
a</FONT></P>
<P><FONT face=3DArial size=3D2>reasonable name for the new registry? See =

[RFC2434].</FONT></P>
<P><FONT face=3DArial size=3D2>Yes to all above.</FONT></P>
<P><FONT face=3DArial size=3D2>If the document describes an Expert =
Review process=20
has</FONT></P>
<P><FONT face=3DArial size=3D2>Shepherd conferred with the Responsible =
Area Director=20
so</FONT></P>
<P><FONT face=3DArial size=3D2>that the IESG can appoint the needed =
Expert during=20
the IESG</FONT></P>
<P><FONT face=3DArial size=3D2>Evaluation?</FONT></P>
<P><FONT face=3DArial size=3D2>None required.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.j) Has the Document Shepherd verified =
that=20
sections of the</FONT></P>
<P><FONT face=3DArial size=3D2>document that are written in a formal =
language, such=20
as XML</FONT></P>
<P><FONT face=3DArial size=3D2>code, BNF rules, MIB definitions, etc., =
validate=20
correctly</FONT></P>
<P><FONT face=3DArial size=3D2>in an automated checker?</FONT></P>
<P><FONT face=3DArial size=3D2>Not applicable.</FONT></P>
<P><FONT face=3DArial size=3D2>(1.k) The IESG approval announcement =
includes a=20
Document</FONT></P>
<P><FONT face=3DArial size=3D2>Announcement Write-Up. Please provide =
such a=20
Document</FONT></P>
<P><FONT face=3DArial size=3D2>Announcement Write-Up? Recent examples =
can be found=20
in the</FONT></P>
<P><FONT face=3DArial size=3D2>"Action" announcements for approved =
documents.=20
The</FONT></P>
<P><FONT face=3DArial size=3D2>approval announcement contains the =
following=20
sections:</FONT></P>
<P><FONT face=3DArial size=3D2>Technical Summary</FONT></P>
<P><FONT face=3DArial size=3D2>This document specifies a per-domain path =
computation=20
technique for</FONT></P>
<P><FONT face=3DArial size=3D2>establishing inter-domain Traffic =
Engineering (TE)=20
Multiprotocol</FONT></P>
<P><FONT face=3DArial size=3D2>Label Switching (MPLS) and Generalized =
MPLS (GMPLS)=20
Label Switched</FONT></P>
<P><FONT face=3DArial size=3D2>Paths (LSPs). In this document a domain =
refers to a=20
collection of</FONT></P>
<P><FONT face=3DArial size=3D2>network elements within a common sphere =
of address=20
management or path</FONT></P>
<P><FONT face=3DArial size=3D2>computational responsibility such as IGP =
areas and=20
Autonomous</FONT></P>
<P><FONT face=3DArial size=3D2>Systems.</FONT></P>
<P><FONT face=3DArial size=3D2>Per-domain computation applies where the =
full path of=20
an inter-domain</FONT></P>
<P><FONT face=3DArial size=3D2>TE LSP cannot be or is not determined at =
the ingress=20
node of the TE</FONT></P>
<P><FONT face=3DArial size=3D2>LSP, and is not signaled across domain =
boundaries.=20
This is most</FONT></P>
<P><FONT face=3DArial size=3D2>likely to arise owing to TE visibility =
limitations.=20
The signaling</FONT></P>
<P><FONT face=3DArial size=3D2>message indicates the destination and =
nodes up to the=20
next domain</FONT></P>
<P><FONT face=3DArial size=3D2>boundary. It may also indicate further =
domain=20
boundaries or domain</FONT></P>
<P><FONT face=3DArial size=3D2>identifiers. The path through each =
domain, possibly=20
including the</FONT></P>
<P><FONT face=3DArial size=3D2>choice of exit point from the domain, =
must be=20
determined within</FONT></P>
<P><FONT face=3DArial size=3D2>the domain.</FONT></P>
<P><FONT face=3DArial size=3D2>Working Group Summary</FONT></P>
<P><FONT face=3DArial size=3D2>The Working Group had consensus on this=20
document.</FONT></P>
<P><FONT face=3DArial size=3D2>Document Quality</FONT></P>
<P><FONT face=3DArial size=3D2>The document has been implemented and=20
deployed.</FONT></P>
<P><FONT face=3DArial size=3D2>Personnel</FONT></P>
<P><FONT face=3DArial size=3D2>Who is the Document Shepherd for this=20
document?</FONT></P>
<P><SPAN class=3D429025221-29042007><FONT face=3DArial size=3D2>Deborah=20
Brungard</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2>Who is the Responsible Area =
Director(s)?</FONT></P>
<P><FONT face=3DArial size=3D2>Ross Callon, David Ward.</FONT></P>
<P><FONT face=3DArial size=3D2>Is an IANA expert needed?</FONT></P>
<P><FONT face=3DArial size=3D2>No.</FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C78AA9.C1E25625--

Delivery-date: Sun, 29 Apr 2007 21:49:59 +0000
Content-class: urn:content-classes:message
Subject: Shepherd write-up for draft-ietf-ccamp-lsp-stitching-06.txt
Date: Sun, 29 Apr 2007 16:49:30 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Ross Callon" <[email-masked]>, "David Ward" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78AA8.44A2E947
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please publish draft-ietf-ccamp-lsp-stitching-06.txt
=20
Please progress this I-D in parallel with
draft-ietf-ccamp-inter-domain-rsvp-te-06.txt and
draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt

Here is the Document Shepherd write-up.

=20
   (1.a)  Who is the Document Shepherd for this document?
           Deborah Brungard ([email-masked]
<mailto:[email-masked]> )
=20
           Has the Document Shepherd personally reviewed this version of
the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
          Yes
=20
   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?
          Yes
          Does the Document Shepherd have any concerns about the depth
or breadth of the reviews that
          have been performed?
          No concerns.
=20
   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?
          No concerns.
=20
   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.
          No concerns.
          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
          None have been filed.
=20
   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
          WG agrees.
=20
   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
          No.
=20
   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html
<http://www.ietf.org/ID-Checklist.html>  and
          http://tools.ietf.org/tools/idnits/
<http://tools.ietf.org/tools/idnits/> ).  Boilerplate checks are
          not enough; this check needs to be thorough.
          Satisfies.
          Has the document met all formal review criteria it needs to,
such as the MIB
          Doctor, media type and URI type reviews?
          Yes.
=20
   (1.h)  Has the document split its references into normative and
          informative?
          Yes.
          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?
          None.
          Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
          No.
=20
   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].
          Yes to all above.
          If the document describes an Expert Review process has
Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
          None required.
=20
   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
          Not applicable.
=20
   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:
=20
Technical Summary
In certain scenarios, there may be a need to combine together several
Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
all traffic from one constituent LSP is switched onto the next LSP.
We will refer to this as "LSP stitching", the key requirement being
that a constituent LSP not be allocated to more than one e2e LSP.
The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
=20
This document describes extensions to the existing GMPLS signaling
protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs,
and describes how the LSPs can be managed using the GMPLS signaling
and routing protocols.
=20
Working Group Summary
The Working Group had consensus on this document.
=20
Document Quality
This document has been implemented.
=20
Personnel
Who is the Document Shepherd for this document? Deborah Brungard
Who is the Responsible Area Director(s)? Ross Callon, David Ward.
Is an IANA expert needed? No.

------_=_NextPart_001_01C78AA8.44A2E947
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D992500615-12042007></SPAN></FONT></DIV>
<DIV><SPAN class=3D992500615-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D697001015-12042007>Please =
publish=20
</SPAN></FONT></FONT></SPAN></SPAN></SPAN><SPAN =
class=3D992500615-12042007><SPAN=20
class=3D425084014-18102006><SPAN class=3D561394721-26042006><FONT =
face=3DArial=20
size=3D2>draft-ietf-cca<SPAN class=3D425084014-18102006>mp-<SPAN=20
class=3D992500615-12042007>lsp-stitching-06</SPAN></SPAN>.txt</FONT></SPA=
N></SPAN></SPAN></DIV>
<DIV><SPAN class=3D992500615-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D992500615-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D697001015-12042007><SPAN=20
class=3D425084014-18102006><SPAN class=3D561394721-26042006>Please =
progress this I-D=20
in parallel with </SPAN></SPAN></SPAN><SPAN =
class=3D697001015-12042007><SPAN=20
class=3D425084014-18102006><SPAN =
class=3D561394721-26042006>draft-ietf-ccamp-<SPAN=20
class=3D992500615-12042007>inter-domain-rsvp-te</SPAN>-06.txt=20
and</SPAN></SPAN></SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT size=3D2><FONT=20
face=3DArial>draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt</FONT></DI=
V>
<DIV>
<P><FONT face=3DArial>Here is the Document Shepherd=20
write-up.</FONT></P></DIV></FONT></SPAN></SPAN></SPAN></SPAN></DIV></DIV>=

<DIV>
<DIV>
<DIV><SPAN class=3D561394721-26042006><FONT size=3D2><FONT=20
size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.a)&nbsp; Who is the =
Document=20
Shepherd for this document?</FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D2><SPAN =
class=3D697001015-12042007><FONT=20
face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;Deborah=20
Brungard (</FONT><A href=3D"mailto:[email-masked]"><FONT=20
face=3DArial>[email-masked]</FONT></A><FONT=20
face=3DArial>)</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</SPAN>Has=20
the<SPAN class=3D697001015-12042007> </SPAN>Document Shepherd personally =
reviewed=20
this version of =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
document and, in particular, does he or she believe=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; version =
is ready=20
for forwarding to the IESG for =
publication?</FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yes<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.b)&nbsp; Has the =
document had=20
adequate review both from key WG=20
members<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and =
from key=20
non-WG members?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yes<=
/FONT></SPAN></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Does=20
the Document Shepherd have<SPAN class=3D697001015-12042007> </SPAN>any =
concerns=20
about the depth or breadth of the reviews=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have been =

performed?</FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20
concerns.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.c)&nbsp; Does the =
Document Shepherd=20
have concerns that the=20
document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; needs =
more=20
review from a particular or broader=20
perspective,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
e.g.,=20
security, operational complexity, someone familiar=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAA,=20
internationalization or XML?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No=20
concerns.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.d)&nbsp; Does the =
Document Shepherd=20
have any specific concerns=20
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issues with =
this=20
document that the Responsible Area=20
Director<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
and/or the=20
IESG should be aware of?&nbsp; For example, perhaps=20
he<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or she is=20
uncomfortable with certain parts of the document,=20
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; has =
concerns=20
whether there really is a need for it.&nbsp; In=20
any<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; event, if =
the WG=20
has discussed those issues and has=20
indicated<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that =
it=20
still wishes to advance the document, detail=20
those<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; concerns =

here.</FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;No=20
concerns.</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Has=20
an IPR disclosure related to this=20
document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; been=20
filed?&nbsp; If so, please include a reference to=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; disclosure =
and=20
summarize the WG discussion and conclusion=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this=20
issue.</FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;None=
 have=20
been filed.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.e)&nbsp; How solid is =
the WG=20
consensus behind this document?&nbsp; Does=20
it<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; represent =
the=20
strong concurrence of a few individuals,=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; others =
being=20
silent, or does the WG as a whole understand=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; agree with =

it?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WG=20
agrees.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.f)&nbsp; Has anyone =
threatened an=20
appeal or otherwise indicated=20
extreme<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
discontent?&nbsp; If so, please summarise the areas of conflict=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separate =
email=20
messages to the Responsible Area Director.&nbsp;=20
(It<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; should be =
in a=20
separate email because this questionnaire=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entered =
into the ID=20
Tracker.)</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No.<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.g)&nbsp; Has the =
Document Shepherd=20
personally verified that=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; document =
satisfies=20
all ID nits?&nbsp;=20
(See<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A =

href=3D"http://www.ietf.org/ID-Checklist.html"><FONT face=3DArial=20
size=3D2>http://www.ietf.org/ID-Checklist.html</FONT></A><FONT =
face=3DArial size=3D2>=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"http://tools.ietf.org/tools/idnits/"><FONT face=3DArial=20
size=3D2>http://tools.ietf.org/tools/idnits/</FONT></A><FONT =
face=3DArial=20
size=3D2>).&nbsp; Boilerplate checks=20
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not =
enough; this=20
check needs to be thorough.</FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Satisfies.</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Has=20
the document<SPAN class=3D697001015-12042007> </SPAN>met all formal =
review=20
criteria it needs to, such as the=20
MIB<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Doctor, =
media type=20
and URI type reviews<SPAN=20
class=3D697001015-12042007>?</SPAN></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.h)&nbsp; Has the =
document split its=20
references into normative=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
informative?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes.</SPAN></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Are=20
there normative references to documents=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are not =
ready for=20
advancement or are otherwise in an=20
unclear<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
state?&nbsp;=20
If such normative references exist, what is=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strategy =
for their=20
completion?</FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT=20
face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
<SPAN=20
class=3D992500615-12042007>None.</SPAN></FONT></SPAN></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT =
size=3D+0><SPAN=20
class=3D697001015-12042007></SPAN><FONT size=3D2><FONT =
face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Are=20
there normative=20
references<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that are=20
downward references, as described in [RFC3967]?&nbsp;=20
If<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; so, list =
these=20
downward references to support the=20
Area<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Director =
in the=20
Last Call procedure for them=20
[RFC3967].</FONT></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No.<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.i)&nbsp; Has the =
Document Shepherd=20
verified that the document=20
IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
consideration=20
section exists and is consistent with the=20
body<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the=20
document?&nbsp;&nbsp;If the document specifies=20
protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extensions,=20
are reservations requested in appropriate=20
IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
registries?&nbsp;=20
Are the IANA registries clearly identified?&nbsp;=20
If<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
document=20
creates a new registry, does it define=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proposed =
initial=20
contents of the registry and an=20
allocation<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
procedure=20
for future registrations?&nbsp; Does it suggest=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reasonable =
name for=20
the new registry?&nbsp; See [RFC2434].</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes=20
to all above.</SPAN></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>If=20
the<SPAN class=3D697001015-12042007> </SPAN>document describes an Expert =
Review=20
process has =
Shepherd<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
conferred with the Responsible Area Director so that the=20
IESG<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can =
appoint the=20
needed Expert during the IESG Evaluation?</FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;None=
=20
required.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.j)&nbsp; Has the =
Document Shepherd=20
verified that sections of=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; document =
that are=20
written in a formal language, such as=20
XML<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; code, BNF =
rules,=20
MIB definitions, etc., validate correctly=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an =
automated=20
checker?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Not =

applicable.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.k)&nbsp; The IESG =
approval=20
announcement includes a=20
Document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Announcement=20
Write-Up.&nbsp; Please provide such a=20
Document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Announcement=20
Write-Up?&nbsp; Recent examples can be found in=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Action"=20
announcements for approved documents.&nbsp; The=20
approval<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
announcement=20
contains the following sections:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Technical Summary<BR>In certain =
scenarios, there=20
may be a need to combine together several</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Generalized Multi-Protocol Label =
Switching (GMPLS)=20
Label Switched<BR>Paths (LSPs) such that a single end-to-end (e2e) LSP =
is=20
realized and<BR>all traffic from one constituent LSP is switched onto =
the next=20
LSP.<BR>We will refer to this as "LSP stitching", the key requirement=20
being<BR>that a constituent LSP not be allocated to more than one e2e=20
LSP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The constituent LSPs will be referred =
to as "LSP=20
segments" (S-LSPs).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This document describes extensions to =
the existing=20
GMPLS signaling<BR>protocol (RSVP-TE) to establish e2e LSPs created from =
from=20
S-LSPs,<BR>and describes how the LSPs can be managed using the GMPLS=20
signaling<BR>and routing protocols.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D+0><FONT size=3D2>Working Group=20
Summary<BR></FONT></FONT><FONT size=3D2><SPAN =
class=3D697001015-12042007>The Working=20
Group had consensus on this document.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Document Quality</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial size=3D2>This =
document has=20
been implemented.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D2><FONT face=3DArial>Personnel<BR>Who =
is the=20
Document Shepherd for this document?<SPAN class=3D697001015-12042007> =
Deborah=20
Brungard</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D2><FONT face=3DArial>Who is =
the&nbsp;Responsible=20
Area Director<SPAN class=3D697001015-12042007>(s)</SPAN>?<SPAN=20
class=3D697001015-12042007> Ross Callon, David=20
Ward.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial>Is an IANA expert needed?<SPAN=20
class=3D697001015-12042007>&nbsp;<SPAN=20
class=3D992500615-12042007>No.</SPAN></SPAN></FONT><FONT=20
size=3D+0><BR></DIV></FONT></DIV></FONT></DIV></SPAN></DIV></SPAN></DIV><=
/SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C78AA8.44A2E947--

Delivery-date: Sun, 29 Apr 2007 21:47:08 +0000
Content-class: urn:content-classes:message
Subject: Shepherd write-up for draft-ietf-ccamp-inter-domain-rsvp-te-06.txt
Date: Sun, 29 Apr 2007 16:44:04 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Ross Callon" <[email-masked]>, "David Ward" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78AA7.827218AB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please publish draft-ietf-ccamp-inter-domain-rsvp-te-06.txt
=20
Please progress this I-D in parallel with
draft-ietf-ccamp-lsp-stitching-06.txt and
draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt

Here is the Document Shepherd write-up.

=20
   (1.a)  Who is the Document Shepherd for this document?
           Deborah Brungard ([email-masked])
=20
           Has the Document Shepherd personally reviewed this version of
the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
          Yes
=20
   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?
          Yes
          Does the Document Shepherd have any concerns about the depth
or breadth of the reviews that
          have been performed?
          No concerns.
=20
   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?
          No concerns.
=20
   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.
          No concerns.
          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
          None have been filed.
=20
   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
          WG agrees.
=20
   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
          No.
=20
   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html
<http://www.ietf.org/ID-Checklist.html>  and
          http://tools.ietf.org/tools/idnits/
<http://tools.ietf.org/tools/idnits/> ).  Boilerplate checks are
          not enough; this check needs to be thorough.
          Satisfies. One reference comment (see 1.h).
          Has the document met all formal review criteria it needs to,
such as the MIB
          Doctor, media type and URI type reviews?
          Yes.
=20
   (1.h)  Has the document split its references into normative and
          informative?
          Yes.
          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?
          One reference to draft-ietf-ccamp-lsp-stitching, which should
be progressed
          with this one to ensure the RFC Ed can sort out.
draft-ietf-ccamp-lsp-stitching
          has finished WG Last Call and it is Standards Track.
          Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
          No.
=20
   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].
          Yes to all above.
          If the document describes an Expert Review process has
Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
          None required.
=20
   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
          Not applicable.
=20
   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:
=20
Technical Summary
This document describes procedures and protocol extensions for the
use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
signaling in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
non-packet networks to support the establishment and maintenance of
Label Switched Paths that cross domain boundaries.
=20
Working Group Summary
The Working Group had consensus on this document.
=20
Document Quality
This document has been implemented.
=20
Personnel
Who is the Document Shepherd for this document? Deborah Brungard
Who is the Responsible Area Director(s)? Ross Callon, David Ward.
Is an IANA expert needed? No.

------_=_NextPart_001_01C78AA7.827218AB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D697001015-12042007></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D697001015-12042007>Please =
publish=20
</SPAN></FONT><SPAN class=3D697001015-12042007><SPAN=20
class=3D425084014-18102006><SPAN class=3D561394721-26042006><FONT =
face=3DArial=20
size=3D2>draft-ietf-cca<SPAN class=3D425084014-18102006>mp<SPAN=20
class=3D697001015-12042007>-inter-domain-rsvp-te-06</SPAN></SPAN>.txt</FO=
NT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D697001015-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D697001015-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT face=3DArial size=3D2>Please progress =
this I-D in=20
parallel with </FONT></SPAN></SPAN></SPAN><SPAN =
class=3D697001015-12042007><SPAN=20
class=3D425084014-18102006><SPAN class=3D561394721-26042006><FONT =
size=3D2><FONT=20
face=3DArial>draft-ietf-ccamp-lsp-stitching-06.txt=20
and</FONT></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D697001015-12042007><SPAN =
class=3D425084014-18102006><SPAN=20
class=3D561394721-26042006><FONT size=3D2><FONT=20
face=3DArial>draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt</FONT></DI=
V>
<DIV>
<P><FONT face=3DArial>Here is the Document Shepherd=20
write-up.</FONT></P></FONT></DIV>
<DIV>
<DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.a)&nbsp; Who is the =
Document=20
Shepherd for this document?</FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;Deborah=20
Brungard (<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>)</SPAN></FONT></F=
ONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</SPAN>Has=20
the<SPAN class=3D697001015-12042007> </SPAN>Document Shepherd personally =
reviewed=20
this version of =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
document and, in particular, does he or she believe=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; version =
is ready=20
for forwarding to the IESG for =
publication?</FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yes<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.b)&nbsp; Has the =
document had=20
adequate review both from key WG=20
members<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and =
from key=20
non-WG members?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yes<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Does=20
the Document Shepherd have<SPAN class=3D697001015-12042007> </SPAN>any =
concerns=20
about the depth or breadth of the reviews=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have been =

performed?</FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20
concerns.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.c)&nbsp; Does the =
Document Shepherd=20
have concerns that the=20
document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; needs =
more=20
review from a particular or broader=20
perspective,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
e.g.,=20
security, operational complexity, someone familiar=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAA,=20
internationalization or XML?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No=20
concerns.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.d)&nbsp; Does the =
Document Shepherd=20
have any specific concerns=20
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issues with =
this=20
document that the Responsible Area=20
Director<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
and/or the=20
IESG should be aware of?&nbsp; For example, perhaps=20
he<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or she is=20
uncomfortable with certain parts of the document,=20
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; has =
concerns=20
whether there really is a need for it.&nbsp; In=20
any<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; event, if =
the WG=20
has discussed those issues and has=20
indicated<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that =
it=20
still wishes to advance the document, detail=20
those<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; concerns =

here.</FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;No=20
concerns.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Has=20
an IPR disclosure related to this=20
document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; been=20
filed?&nbsp; If so, please include a reference to=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; disclosure =
and=20
summarize the WG discussion and conclusion=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this=20
issue.</FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;None=
 have=20
been filed.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.e)&nbsp; How solid is =
the WG=20
consensus behind this document?&nbsp; Does=20
it<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; represent =
the=20
strong concurrence of a few individuals,=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; others =
being=20
silent, or does the WG as a whole understand=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; agree with =

it?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WG=20
agrees.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.f)&nbsp; Has anyone =
threatened an=20
appeal or otherwise indicated=20
extreme<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
discontent?&nbsp; If so, please summarise the areas of conflict=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separate =
email=20
messages to the Responsible Area Director.&nbsp;=20
(It<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; should be =
in a=20
separate email because this questionnaire=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entered =
into the ID=20
Tracker.)</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No.<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.g)&nbsp; Has the =
Document Shepherd=20
personally verified that=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; document =
satisfies=20
all ID nits?&nbsp;=20
(See<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A =

href=3D"http://www.ietf.org/ID-Checklist.html"><FONT face=3DArial=20
size=3D2>http://www.ietf.org/ID-Checklist.html</FONT></A><FONT =
face=3DArial size=3D2>=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"http://tools.ietf.org/tools/idnits/"><FONT face=3DArial=20
size=3D2>http://tools.ietf.org/tools/idnits/</FONT></A><FONT =
face=3DArial><FONT=20
size=3D2>).&nbsp; Boilerplate checks=20
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not =
enough; this=20
check needs to be thorough.</FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Satisfies.=20
One reference comment (see 1.h).</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><SPAN =
class=3D697001015-12042007></SPAN><FONT=20
face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Has=20
the document<SPAN class=3D697001015-12042007> </SPAN>met all formal =
review=20
criteria it needs to, such as the=20
MIB<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Doctor, =
media type=20
and URI type reviews<SPAN=20
class=3D697001015-12042007>?</SPAN></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.h)&nbsp; Has the =
document split its=20
references into normative=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
informative?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes.</SPAN></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Are=20
there normative references to documents=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are not =
ready for=20
advancement or are otherwise in an=20
unclear<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
state?&nbsp;=20
If such normative references exist, what is=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strategy =
for their=20
completion?</FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT =
face=3DArial><FONT=20
size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;One=20
reference to draft-ietf-ccamp-lsp-stitching, which should be=20
progressed</SPAN></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT =
face=3DArial><FONT=20
size=3D2><SPAN=20
class=3D697001015-12042007></SPAN></FONT></FONT></FONT></FONT></FONT><FON=
T=20
size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;with=20
this one&nbsp;to ensure the RFC Ed can sort out.=20
draft-ietf-ccamp-lsp-stitching</SPAN></FONT></FONT></FONT></FONT></FONT><=
/DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT =
face=3DArial><FONT=20
size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;has=20
finished WG Last Call and it is Standards=20
Track.</SPAN></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT =
size=3D+0><SPAN=20
class=3D697001015-12042007></SPAN><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>Are=20
there normative=20
references<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that are=20
downward references, as described in [RFC3967]?&nbsp;=20
If<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; so, list =
these=20
downward references to support the=20
Area<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Director =
in the=20
Last Call procedure for them=20
[RFC3967].</FONT></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;No.<=
/FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.i)&nbsp; Has the =
Document Shepherd=20
verified that the document=20
IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
consideration=20
section exists and is consistent with the=20
body<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the=20
document?&nbsp;&nbsp;If the document specifies=20
protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extensions,=20
are reservations requested in appropriate=20
IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
registries?&nbsp;=20
Are the IANA registries clearly identified?&nbsp;=20
If<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
document=20
creates a new registry, does it define=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proposed =
initial=20
contents of the registry and an=20
allocation<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
procedure=20
for future registrations?&nbsp; Does it suggest=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reasonable =
name for=20
the new registry?&nbsp; See [RFC2434].</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;Yes=20
to all above.</SPAN></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D697001015-12042007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</SPAN>If=20
the<SPAN class=3D697001015-12042007> </SPAN>document describes an Expert =
Review=20
process has =
Shepherd<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
conferred with the Responsible Area Director so that the=20
IESG<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can =
appoint the=20
needed Expert during the IESG Evaluation?</FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;None=
=20
required.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.j)&nbsp; Has the =
Document Shepherd=20
verified that sections of=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; document =
that are=20
written in a formal language, such as=20
XML<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; code, BNF =
rules,=20
MIB definitions, etc., validate correctly=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an =
automated=20
checker?</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Not =

applicable.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; (1.k)&nbsp; The IESG =
approval=20
announcement includes a=20
Document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Announcement=20
Write-Up.&nbsp; Please provide such a=20
Document<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Announcement=20
Write-Up?&nbsp; Recent examples can be found in=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Action"=20
announcements for approved documents.&nbsp; The=20
approval<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
announcement=20
contains the following sections:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Technical Summary<BR></FONT><FONT =
face=3DArial=20
size=3D2>This document describes procedures and protocol extensions for =
the<BR>use=20
of Resource ReserVation Protocol Traffic Engineering =
(RSVP-TE)<BR>signaling in=20
Multiprotocol Label Switching Traffic Engineering<BR>(MPLS-TE) packet =
networks=20
and Generalized MPLS (GMPLS) packet and<BR>non-packet networks to =
support the=20
establishment and maintenance of<BR>Label Switched Paths that cross =
domain=20
boundaries.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2>Working Group=20
Summary<BR></FONT></FONT></FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D697001015-12042007>The Working Group had consensus on this=20
document.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Document Quality</FONT></DIV>
<DIV><SPAN class=3D697001015-12042007><FONT face=3DArial size=3D2>This =
document has=20
been implemented.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2>Personnel<BR>Who =
is the=20
Document Shepherd for this document?<SPAN class=3D697001015-12042007> =
Deborah=20
Brungard</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2>Who is =
the&nbsp;Responsible=20
Area Director<SPAN class=3D697001015-12042007>(s)</SPAN>?<SPAN=20
class=3D697001015-12042007> Ross Callon, David=20
Ward.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial><FONT size=3D2>Is an IANA expert =
needed?<SPAN=20
class=3D697001015-12042007> No.</SPAN></FONT></FONT></FONT><FONT=20
size=3D+0><BR></DIV></FONT></SPAN></DIV></SPAN></DIV></SPAN></DIV></BODY>=
</HTML>

------_=_NextPart_001_01C78AA7.827218AB--

Delivery-date: Sat, 28 Apr 2007 18:10:54 +0000
To: Greg Jones <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Hiroshi Ohta <[email-masked]>, Scott Bradner <[email-masked]>, Dave Ward <[email-masked]>, Ross Callon <[email-masked]>, Loa Andersson <[email-masked]>, JP Vasseur <[email-masked]>, CCAMP Working Group <[email-masked]>, PCE Working Group <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>
From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "SG15 OTNT Standardisation Work Plan" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Sat, 28 Apr 2007 14:07:55 -0400

Title: SG15 OTNT Standardisation Work Plan
Submission Date: 2007-04-28
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=322 

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T Study Group 15 Question 3(Greg Jones <[email-masked]>)
Cc: Stephen Trowbridge <[email-masked]>
Hiroshi Ohta <[email-masked]>
Scott Bradner <[email-masked]>
Dave Ward <[email-masked]>
Ross Callon <[email-masked]>
Loa Andersson <[email-masked]>
JP Vasseur <[email-masked]>
CCAMP Working Group <[email-masked]>
PCE Working Group <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For information 
Body: The CCAMP Working Group of the IETF thanks you for sharing
your OTNT Work Plan and for soliciting our comments.

We have the following two points that you may want to use
to update your document.

1. Table 5-1

  This table lists standardisation activities for carrier-
  class Ethernet in various SDOs.

  The CCAMP working group has the responsibility within the
  IETF for developing common control plane and measurement 
  plane solutions for use within transport networks, and 
  layer 2 (for example, Ethernet) is within scope for our
  work. The working group has been discussing the 
  application of GMPLS protocols to the dynamic control of 
  Ethernet networks with the following results:

  a. draft-ietf-ccamp-ethernet-traffic-parameters-01.txt

    This Internet-Draft documents extensions to the RSVP-TE 
    signaling protocol to express Ethernet traffic
    parameters so that GMPLS can be used to set up Ethernet 
    LSPs and to request Ethernet services at a GMPLS UNI.
    The draft can be found at 
    http://www.ietf.org/internet-drafts/
    draft-ietf-ccamp-ethernet-traffic-parameters-01.txt

  b. GMPLS Ethernet Label Switching (GELS)

    The GELS effort is intended to develop a single set of 
    protocol extensions that are applicable to the 
    establishment of LSPs through an Ethernet network.

    Currently there are several proposals of what type of
    Ethernet network may benefit from this type of control
    plane, and the appropriateness of each proposed data 
    plane will be verified with the IEEE before CCAMP 
    attempts to apply a control plane.

    Currently there are several individual submission
    Internet-Drafts that have started to lay out the 
    requirements and potential solutions for the GMPLS 
    protocol extensions.

2. Table 7-1

  Table 7-1 provides a long list of related OTNT industry 
  standards and specifications.

  a. GMPLS and Optical-Related RFCs

    We would like to suggest some additions to this list
    from the IETF as follows:

    RFC 3471 : Generalized Multi-Protocol Label Switching 
               (GMPLS) Signaling Functional Description

    RFC 3473 : Generalized Multi-Protocol Label Switching 
               (GMPLS)Signaling Resource ReserVation 
               Protocol-Traffic Engineering (RSVP-TE) 
               Extensions

    RFC 4652 : Evaluation of Existing Routing Protocols
               against Automatic Switched Optical Network 
               (ASON) Routing Requirements

    RFC 4726 : A Framework for Inter-Domain Multiprotocol
               Label Switching Traffic Engineering

    RFC 4736 : Reoptimization of Multiprotocol Label 
               Switching (MPLS) Traffic Engineering (TE)
               Loosely Routed Label Switch Path (LSP)

    RFC 4783 : GMPLS - Communication of Alarm Information

    RFC 4801 : Definitions of Textual Conventions for 
               Generalized Multiprotocol Label Switching
               (GMPLS) Management

    RFC 4802 : Generalized Multiprotocol Label Switching 
               (GMPLS) Traffic Engineering Management 
               Information Base

    RFC 4803 : Generalized Multiprotocol Label Switching
               (GMPLS)Label Switching Router (LSR)
               Management Information Base

    RFC 4874 : Exclude Routes - Extension to Resource 
               ReserVation Protocol-Traffic Engineering
               (RSVP-TE)

    The latest list of CCAMP RFCs can be found at the CCAMP
    Charter page, 
    http://www.ietf.org/html.charters/ccamp-charter.html

    A further short list of RFCs have been assigned numbers
    and will be published in the next few days:

    RFC 4872 : RSVP-TE Extensions in Support of End-to-End 
               Generalized Multi-Protocol Label Switching
               (GMPLS) Recovery

    RFC 4873 : GMPLS Segment Recovery

  b. GMPLS and Optical-Related Internet-Drafts

    We welcome your listing of Internet-Drafts for related
    work. We make the following observations:

    i.  All Internet-Drafts should be identified as "work 
        in progress". This request is made, as standard, by
        the IETF in the following boilerplate text at the
        head of every Internet-Draft...

          Internet-Drafts are draft documents valid for a 
          maximum of six months and may be updated, 
          replaced, or obsoleted by other documents at any
          time.  It is inappropriate to use Internet-Drafts
          as reference material or to cite them other than 
          as "work in progress."

    ii. The following Internet-Drafts in Table 7-1 have
        been replaced with RFCs as listed above:

        draft-ietf-ccamp-gmpls-tc-mib
        draft-ietf-ccamp-gmpls-te-mib
        draft-ietf-ccamp-gmpls-lsr-mib
        draft-ietf-ccamp-rsvp-te-exclude-route
        draft-ietf-ccamp-gmpls-alarm-spec
        draft-ietf-ccamp-inter-domain-framework
        draft-ietf-ccamp-loose-path-reopt
        draft-ietf-ccamp-gmpls-ason-routing-eval

    iii. Additional Internet-Drafts

        You may wish to list the following CCAMP Internet-
        Drafts as relevant to your work:

        draft-ietf-ccamp-inter-domain-rsvp-te-05.txt
          Inter domain Multiprotocol Label Switching (MPLS) 
          and Generalized MPLS (GMPLS) Traffic Engineering 
          - RSVP-TE extensions

        draft-ietf-ccamp-lsp-stitching-05.txt
          Label Switched Path Stitching with Generalized
          Multiprotocol Label Switching Traffic Engineering
          (GMPLS TE)

        draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt
          Generalized MPLS (GMPLS) RSVP-TE Signaling 
          Extensions in support of Calls

        draft-ietf-ccamp-lsp-hierarchy-bis-01.txt
          Procedures for Dynamically Signaled Hierarchical
          Label Switched Paths

        draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt
          Framework for MPLS-TE to GMPLS migration

        draft-ietf-ccamp-ethernet-traffic-parameters-01.txt
          MEF Ethernet Traffic Parameters

        draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt
          OSPFv2 Routing Protocols Extensions for ASON 
          Routing

        draft-ietf-ccamp-mpls-graceful-shutdown-02.txt
          Graceful Shutdown in GMPLS Traffic Engineering
          Networks

        draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
          Operating Virtual Concatenation (VCAT) and the 
          Link Capacity Adjustment Scheme (LCAS) with 
          Generalized Multi-Protocol Label Switching 
          (GMPLS)

        draft-ietf-ccamp-gmpls-ted-mib-01.txt
          Traffic Engineering Database Management 
          Information Base in support of GMPLS

        draft-ietf-ccamp-pc-and-sc-reqs-00.txt
          Requirements for the Conversion Between Permanent
          Connections and Switched Connections in a 
          Generalized Multiprotocol Label Switching (GMPLS)
          Network

        draft-ietf-ccamp-mpls-gmpls-interwork-reqts-00.txt
          Interworking Requirements to Support operation of
          MPLS-TE over GMPLS networks

        draft-ietf-ccamp-inter-domain-recovery-analysis-00.txt
          Analysis of Inter-domain Label Switched Path
          (LSP) Recovery

        The latest list of CCAMP Internet-Drafts can be 
        found at the CCAMP Charter page, 
        http://www.ietf.org/html.charters/ccamp-charter.html

    iv. Expired Internet-Drafts

        The following Internet-Drafts listed in table 7-1 
        have expired and are not being pursued.

        draft-ietf-ipo-impairments
        draft-ietf-ipo-framework

  c. Path Computation-related RFCs and Internet-Drafts

    In the light of G.7715.2, you may also be interested in 
    including the Path Computation Element (PCE) RFCs and 
    Internet-Drafts within table 7-1 as follows:

    RFC 4655 : A Path Computation Element (PCE) Based
               Architecture

    RFC 4657 : Path Computation Element (PCE) Communication
               Protocol Generic Requirements

    RFC 4674 : Requirements for Path Computation Element 
               (PCE) Discovery

    draft-ietf-pce-pcep-07.txt
      Path Computation Element (PCE) communication Protocol 
      (PCEP)

    draft-ietf-pce-inter-layer-req-04.txt
      PCC-PCE Communication Requirements for Inter-Layer
      Traffic Engineering

    draft-ietf-pce-pcecp-interarea-reqs-05.txt
      PCE Communication Protocol (PCECP) Specific
      Requirements for Inter-Area Multi Protocol Label 
      Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
      Engineering

    draft-ietf-pce-inter-layer-frwk-03.txt
      Framework for PCE-Based Inter-Layer MPLS and GMPLS 
      Traffic Engineering

    draft-ietf-pce-policy-enabled-path-comp-01.txt
      Policy-Enabled Path Computation Framework

    draft-ietf-pce-interas-pcecp-reqs-01.txt
      Inter-AS Requirements for the Path Computation
      Element Communication Protocol (PCECP)

    draft-ietf-pce-brpc-04.txt
      A Backward Recursive PCE-based Computation (BRPC) 
      procedure to compute shortest inter-domain Traffic
      Engineering Label Switched Paths

    draft-ietf-pce-disco-proto-ospf-03.txt
      OSPF protocol extensions for Path Computation Element
      (PCE) Discovery

    draft-ietf-pce-disco-proto-isis-03.txt
      IS-IS protocol extensions for Path Computation
      Element (PCE) Discovery

    draft-ietf-pce-disc-mib-01.txt
      Definitions of Managed Objects for Path Computation 
      Element Discovery

    draft-ietf-pce-tc-mib-01.txt
      Definitions of Textual Conventions for Path 
      Computation Element

    draft-ietf-pce-pcep-xro-00.txt
      Extensions to the Path Computation Element 
      Communication Protocol (PCEP) for Route Exclusions

    The latest list of PCE RFCs and Internet-Drafts can be
    found at the PCE Charter page,
    http://www.ietf.org/html.charters/pce-charter.html

  d. Obsoleted specification

    Please note that RFC 4327 has been obsoleted by RFC 
    4631 and should no longer be listed in its own right.

  e. MPLS and Packet-related RFCs and Internet-Drafts

    We suggest that in the light of the recent work within 
    the ITU-T related to packet transport networks
    including, but not limited to, pseudowires and T-MPLS, 
    you may wish to contact Mr. Loa Andersson who is IETF 
    liaison to the ITU-T on MPLS to see what new and 
    relevant MPLS RFCs and Internet-Drafts have been
    published.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs
Attachment(s):
No document has been attached

Delivery-date: Fri, 27 Apr 2007 11:03:52 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: RFC 4859 on Codepoint Registry for the Flags Field in the ResourceReservation Protocol-Traffic Engineering (RSVP-TE) SessionAttribute Object
Date: Fri, 27 Apr 2007 11:57:36 +0100
Organization: Old Dog Consulting

FYI
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 27, 2007 2:39 AM
Subject: RFC 4859 on Codepoint Registry for the Flags Field in the 
ResourceReservation Protocol-Traffic Engineering (RSVP-TE) SessionAttribute 
Object

>
> A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 4859
>
>        Title:      Codepoint Registry for the Flags
>                    Field in the Resource Reservation Protocol-Traffic
>                    Engineering (RSVP-TE) Session Attribute Object
>        Author:     A. Farrel
>        Status:     Informational
>        Date:       April 2007
>        Mailbox:    [email-masked]
>        Pages:      5
>        Characters: 7511
>        Updates/Obsoletes/SeeAlso:   None
>
>        I-D Tag:    draft-ietf-mpls-iana-rsvp-session-flags-01.txt
>
>        URL:        http://www.rfc-editor.org/rfc/rfc4859.txt
>
> This document provides instructions to IANA for the creation of a new
> codepoint registry for the flags field in the Session Attribute
> object of the Resource Reservation Protocol Traffic Engineering
> (RSVP-TE) signaling messages used in Multiprotocol Label Switching
> (MPLS) and Generalized MPLS (GMPLS) signaling.  This memo provides
> information for the Internet community.
>
> This document is a product of the Multiprotocol Label Switching
> Working Group of the IETF.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution
> of this memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
>
> help: ways_to_get_rfcs. For example:
>
>        To: [email-masked]
>        Subject: getting rfcs
>
>        help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
>
>
> The RFC Editor Team
> USC/Information Sciences Institute
>
> ...
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
> 

Delivery-date: Thu, 26 Apr 2007 16:26:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-addressing-06.txt 
Date: Thu, 26 Apr 2007 17:25:58 +0100
Organization: Old Dog Consulting

Good comments. Thanks.

> In the abstract and the introduction, the phrase "facilitate
> better interworking" reads weird to me. I'm not a native
> English speaker, but wouldn't "facilitate interworking" be
> more appropriate?

OK

> About the IGP terminology, in OSPF and IS-IS RFCs,
> "OSPF-TE" and "IS-IS-TE" terms are reserved for
> MPLS-TE extensions (RFC 3630 and 3784) while
> GMPLS ones (RFC 4203 and 4205) are rather named
> "GMPLS OSPF" and "GMPLS IS-IS". I believe the ID
> should follow this terminology more closely.

No objection.

> In section 5.1.1:
>   "An unnumbered TE
>   link end network-wide identifier is comprised of a TE Router ID
>   associated with the link local end, followed by the link local
>   identifier"
>
> The intent on (TE Router ID, link local ID) is clear to anyone
> familiar with the context, but I also feel -- due to my mother
> tongue? -- that this might also be misread as (TE Router ID,
> link local end, link local ID), which does not make any sense.
> However, considering this is a clarification document, maybe
> replacing "associated with" by "corresponding to" or just
> recalling it's a pair would do the trick.

Try...

An unnumbered TE link end network-wide identifier is comprised
of two elements:
- a TE Router ID that is associated with the link local end
- the link local identifier.

> In section 6.1.2:
>   "If the interface was intended to be used as an outgoing
>   interface, the path will be broken an may be impossible to
>   resolve."
>
> s/an/and/

OK

> "The path will be broken" looks like a postulate and needs a 
> clarification.

Yes, the sentence and the path are broken :-)

Try...

If the interface was intended to be used as an outgoing
interface, the computed path may be unsatisfactory and
the explicit route in the ERO may be impossible to resolve.

>"This a loose hop that identifies an interface should always
> identify the incoming TE link in the data plane."
>
> Something's missing or "This" should be removed.

s/This/Thus,/

Cheers,
Adrian

Delivery-date: Thu, 26 Apr 2007 15:56:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-addressing-06.txt 
Date: Thu, 26 Apr 2007 17:54:15 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi all.

Just a few comments about the ID.

In the abstract and the introduction, the phrase "facilitate better =
interworking" reads weird to me. I'm not a native English speaker, but =
wouldn't "facilitate interworking" be more appropriate?

About the IGP terminology, in OSPF and IS-IS RFCs, "OSPF-TE" and =
"IS-IS-TE" terms are reserved for MPLS-TE extensions (RFC 3630 and 3784) =
while GMPLS ones (RFC 4203 and 4205) are rather named "GMPLS OSPF" and =
"GMPLS IS-IS". I believe the ID should follow this terminology more =
closely.

In section 5.1.1:
   "An unnumbered TE
   link end network-wide identifier is comprised of a TE Router ID
   associated with the link local end, followed by the link local
   identifier"
-> The intent on (TE Router ID, link local ID) is clear to anyone =
familiar with the context, but I also feel -- due to my mother tongue? =
-- that this might also be misread as (TE Router ID, link local end, =
link local ID), which does not make any sense. However, considering this =
is a clarification document, maybe replacing "associated with" by =
"corresponding to" or just recalling it's a pair would do the trick.

In section 6.1.2:
   "If the interface was intended to be used as an outgoing
   interface, the path will be broken an may be impossible to resolve."
-> s/an/and/
-> "The path will be broken" looks like a postulate and needs a =
clarification.

   "This a loose hop that identifies an interface should always identify
   the incoming TE link in the data plane."
-> Something's missing or "This" should be removed.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel

Hi,

After some delay, this I-D has been updated as requested by the working=20
group to move it on to the Informational track.

As well as the obvious change to the front page, all of the 2119 =
language=20
has been removed and references have been inserted to the definitive=20
material in other RFCs.

The Abstract now clearly states "This document does not define new=20
procedures of processes."

And the Introduction contains...

   This document does not define new procedures of processes and the
   protocol specifications listed above should be treated as definitive.

I think this should be compatible with the working group's wishes, and I =

think that the I-D is now in relatively good shape to be taken to the =
IESG,=20
so...

This begins a two week working group last call. Please send your =
comments to=20
the mailing list.

The last call will end at 6pm GMT on Sunday 6th May 2007.

Thanks,
Adrian=20

Delivery-date: Wed, 25 Apr 2007 19:51:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-03.txt 
Date: Wed, 25 Apr 2007 15:50:02 -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		: Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-mln-reqs-03.txt
	Pages		: 22
	Date		: 2007-4-25
	
Most of the initial efforts to utilize Generalized MPLS (GMPLS) 
     have been related to environments hosting devices with a single 
     switching capability. The complexity raised by the control of such 
     data planes is similar to that seen in classical IP/MPLS networks. 
      
     By extending MPLS to support multiple switching technologies, GMPLS 
     provides a comprehensive framework for the control of a multi-
     layered network of either a single switching technology or multiple 
     switching technologies.  
     In GMPLS, a switching technology domain defines a region, and a 
     network of multiple switching types is referred to in this document 
     as a Multi-Region Network (MRN). When referring in general to a 
     layered network, which may consist of either a single or multiple 
     regions, this document uses the term, Multi-Layer Network (MLN). 
     This document defines a framework for GMPLS based multi-
     region/multi-layer networks and lists a set of functional 
     requirements.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mln-reqs-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: Wed, 25 Apr 2007 16:57:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [David Ward <[email-masked]>]   
Date: Wed, 25 Apr 2007 17:54:12 +0100
Organization: Old Dog Consulting

> Adrian -
>
> There is certainly no reason to *require OSPF to use the same mechanism as
> IS-IS to prevent looping of advertisements. If the OSPF folks are 
> convinced
> this works (seems like it should) I don't have any objection. As for the
> pragmatics of having multiple solutions, I don't quite get it but that is
> another conversation.
>
> My only quibble is the use of the term "level 2 area", which indicates it
> was written by on OSPF person! It should of course say "level 2 domain".
> Tsk, tsk.
>
> -DWard
>
>
> On 4/24/07 12:21 PM, "Adrian Farrel" <[email-masked]> wrote:
>
>> Hi,
>>
>> CCAMP asked us a specific question with regard to loop prevention in OSPF
>> ASON Routing and why we had chosen not to use the mechanisms provided for
>> loop prevention in IS-IS for IP and MPLS-TE.
>>
>> Here is a draft response. (Thanks to Deborah, Dimitri, Acee, and Abhay 
>> for
>> help in preparing it.)
>>
>> Please let me have your comments by Saturday 5th April.
>>
>> Thanks,
>> Adrian
>>
>>  ===
>>
>> To: ITU-T Q14/15
>> From: IETF CCAMP Working Group
>> Cc: Stephen Trowbridge, Kam Lam, Dave Ward, Ross Callon, Acee
>> Lindem, Rohit Dube, CCAMP Working Group, OSPF Working Group
>> Subject: Loop Prevention Mechanisms in OSPF for ASON Networks
>> For Action
>>
>> The CCAMP Working Group thanks you for your liaison "Liaison
>> Statement to CCAMP responding to ccamp liaison of 21 February 2007"
>> generated at your Darmstadt interim meeting and dated March 2007.
>>
>> This liaison continues an exchange about the loop prevention
>> mechanisms introduced to in draft-ietf-ccamp-gmpls-ason-routing-
>> ospf-03.txt "OSPFv2 Routing Protocols Extensions for ASON Routing".
>> In your liaison "Response to IETF CCAMP WG LS (TD314/3) on
>> "Notification of work in the IETF CCAMP working group"" dated
>> November 2006 you said:
>>
>>     As discussed within Section 6 on routing information dissemination,
>>     and per the ASON link state routing requirements in G.7715.1, it
>>     is essential to avoid feedback loops that may arise when both
>>     upward and downward communication interfaces contain endpoint
>>     reachability information.  Thus, we fully agree that providing
>>     associated import/export rules is an essential element of OSPF
>>     routing protocol design.  In reviewing Sections 6.1 - 6.5 of the
>>     draft, we observed that several new mechanisms are being
>>     proposed to address this important problem.  It was observed
>>     that RFC 2966, which has already considered and addressed
>>     such issues, appears to contain an applicable, relatively simple
>>     solution mechanism (within Section 3.1) that is not specific to the
>>     IS-IS protocol.  Given RFC 2966 offers a solution that has been
>>     proven and implemented by multiple vendors, yielding the potential
>>     opportunity for reuse, we wondered whether you had identified
>>     any drawbacks in pursuing such an approach.
>>
>>     Please provide us with your thoughts on the usage of this alternative
>>     method.
>>
>> In our response liaison "Response to your liaison on current ASON
>> work in CCAMP" dated 21st February 2007 we replied:
>>
>>      We are glad that you agree with our assessment that it
>>      is an essential element of OSPF routing protocol design
>>      to provide import/export rules to prevent feedback
>>      loops.
>>
>>      RFC2966 presents a solution to this problem specific to
>>      the ISIS protocol, although, as you say, this mechanism
>>      could be adapted to other protocols.
>>
>>      But other mechanisms also exist, and the ultimate
>>      solution that we choose must be agreed not by the ISIS
>>      community, but by the OSPF community. In this case, the
>>      choice was made after careful evaluation in cooperation
>>      with IETF's OSPF Working Group.
>>
>>      Please let us know whether you have any technical
>>      issues with the approach we have chosen, and if so,
>>      what the issues are.
>>
>> In your most recent liaison, you say:
>>
>>     On the selection of a loop prevention mechanism the liaison
>>     statement indicates that  "the choice was made after careful
>>     evaluation in cooperation with IETF's OSPF Working Group."
>>     We would appreciate further details of these considerations to
>>     allow us to fully understand the thought going into this decision
>>     and evaluate any impacts on the transport network.
>>
>> We are happy to provide a summary of the decision.
>>
>> RFC 2966 is titled "Domain-wide Prefix Distribution with Two-Level
>> IS-IS", and the Abstract reads:
>>
>>     This document describes extensions to the Intermediate System to
>>     Intermediate System (IS-IS) protocol to support optimal routing
>>     within a two-level domain.  The IS-IS protocol is specified in ISO
>>     10589, with extensions for supporting IPv4 (Internet Protocol)
>>     specified in RFC 1195 [2].
>>
>>     This document extends the semantics presented in RFC 1195 so that a
>>     routing domain running with both level 1 and level 2 Intermediate
>>     Systems (IS) [routers] can distribute IP prefixes between level 1 and
>>     level 2 and vice versa.  This distribution requires certain
>>     restrictions to insure that persistent forwarding loops do not  form.
>>     The goal of this domain-wide prefix distribution is to increase the
>>     granularity of the routing information within the domain.
>>
>> The problem that RFC 2966 addresses is for a two level domain. The
>> problem is that, because of the way IS-IS is defined to exchange IP
>> prefixes between levels, it is possible that a routing loop could
>> be formed. The issue arises when an IS-IS layer 1 area is dual
>> homed to the IS-IS layer 2 area and the prefixes advertised from
>> one layer into the other at one L1L2 router (Ra) are re-advertised
>> back into the originating IS-IS layer at another L1L2 router (Rb)
>> making it appear that the shortest path to a prefix from Rb is
>> through Ra. The fix in RFC 2966 uses the up/down bit to make sure
>> that advertisements do not continually circulate between layers.
>> RFC 3784 "Intermediate System to Intermediate System (IS-IS)
>> Extensions for Traffic Engineering (TE)" defines traffic
>> engineering information distribution mechanisms using IS-IS. This
>> work is further extended by RFC 4205 "Intermediate System to
>> Intermediate System (IS-IS) Extensions in Support of Generalized
>> Multi-Protocol Label Switching (GMPLS)". RFC 3784 allows the
>> extended reachability TLV to be exchanged between IS-IS layers.
>> This means that TE information can be exchanged between IS-IS
>> layers, and the up/down bit is necessary to stop the advertisements
>> circulating for ever.
>>
>> But, it is important to note that since the TE information is used
>> to build a topology representation in the Traffic Engineering
>> Database, there is no risk of data looping. Contrast this with the
>> problem addressed in RFC 2966 where shortest path first
>> computations provided per IS-IS layer might cause data looping.
>> Thus, the only problem addressed by the use of the up/down bit in
>> RFC 3784 is that of endlessly circulating information.
>>
>> Now, OSPF addresses the original looping problem in a different
>> way. It restricts the advertisement of prefixes between areas by
>> using different LSA types and flooding scopes. Thus, information
>> leaked from Area 0 into some other subtended area is never leaked
>> back into Area 0.
>>
>> Further in OSPF-TE, there is no danger of endlessly looping
>> information between Area 0 and the subtended areas because RFC 3630
>> "Traffic Engineering (TE) Extensions to OSPF Version 2" instructs
>> us to use the type 10 opaque LSA for distributing TE information.
>> And, as defined in RFC 2370 "The OSPF Opaque LSA Option" a type 10
>> opaque LSA is not distributed outside the area in which it was
>> generated.
>>
>> The problem that must be addressed in draft-dimitri-ccamp-gmpls-
>> ason-routing-ospf is caused because of a deliberate change in
>> information leakage processing. That is, in the ASON network,
>> selected upward and downward redistribution of TE information is
>> allowed. Thus, OSPF-TE is opened up to the possibility of
>> information distribution looping (although still not of looping of
>> computed data paths).
>>
>> As section 6.3 of draft-dimitri-ccamp-gmpls-ason-routing-
>> ospf-03.txt says:
>>
>>    When more than one RC are bound to adjacent levels of the hierarchy,
>>    configured and selected to redistribute upward and downward the
>>    routing information, a specific mechanism is required to avoid
>>    looping/re-introduction of routing information back to the upper
>>    level. This specific case occurs e.g. when the RC advertising
>>    routing information downward the hierarchy is not the one
>>    advertising routing upward the hierarchy (or vice-versa).
>>
>>    When these conditions are met, it is necessary to have a means by
>>    which an RC receiving an Opaque TE LSA imported/exported
>>    downward by an RC associated with the same area, suppresses the
>>    import/export back of the content of this LSA upward into the
>>    (same) upper level.
>>
>> Clearly it is necessary to add some indication of the origin of the
>> data into the advertisement. The mechanism proposed in draft-
>> dimitri-ccamp-gmpls-ason-routing-ospf-03.txt is to add the Area ID
>> of the OSPF area containing the originating RC. This provides more
>> information than the simple up/down bit of RFC 2966 and allows an
>> easy distinction to be made between advertising information
>> received from a lower layer area down into a different lower layer
>> area, and back into the same lower layer area.
>>
>> We hope this clarifies the similarities and differences with RFC
>> 2966, and hope that you will ask if you have further specific
>> questions. As before, we encourage you to examine the resulting
>> functionality and to provide us with technical arguments if you
>> believe the function is inappropriate for a transport network, or
>> if you see any specific issues with the proposed approach.
>>
>> Best regards,
>> Adrian Farrel and Deborah Brungard
>> IETF CCAMP Working Group Co-Chairs
>
>
>
>
> 

Delivery-date: Tue, 24 Apr 2007 17:27:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>, "Scott Bradner" <[email-masked]>, "Acee Lindem" <[email-masked]>, "Abhay Roy" <[email-masked]>
Subject: Draft liaison to ITU on Loop Prevention in ASON Routing
Date: Tue, 24 Apr 2007 18:21:54 +0100
Organization: Old Dog Consulting

Hi,

CCAMP asked us a specific question with regard to loop prevention in OSPF 
ASON Routing and why we had chosen not to use the mechanisms provided for 
loop prevention in IS-IS for IP and MPLS-TE.

Here is a draft response. (Thanks to Deborah, Dimitri, Acee, and Abhay for 
help in preparing it.)

Please let me have your comments by Saturday 5th April.

Thanks,
Adrian

 ===

To: ITU-T Q14/15
From: IETF CCAMP Working Group
Cc: Stephen Trowbridge, Kam Lam, Dave Ward, Ross Callon, Acee
Lindem, Rohit Dube, CCAMP Working Group, OSPF Working Group
Subject: Loop Prevention Mechanisms in OSPF for ASON Networks
For Action

The CCAMP Working Group thanks you for your liaison "Liaison
Statement to CCAMP responding to ccamp liaison of 21 February 2007"
generated at your Darmstadt interim meeting and dated March 2007.

This liaison continues an exchange about the loop prevention
mechanisms introduced to in draft-ietf-ccamp-gmpls-ason-routing-
ospf-03.txt "OSPFv2 Routing Protocols Extensions for ASON Routing".
In your liaison "Response to IETF CCAMP WG LS (TD314/3) on
"Notification of work in the IETF CCAMP working group"" dated
November 2006 you said:

    As discussed within Section 6 on routing information dissemination,
    and per the ASON link state routing requirements in G.7715.1, it
    is essential to avoid feedback loops that may arise when both
    upward and downward communication interfaces contain endpoint
    reachability information.  Thus, we fully agree that providing
    associated import/export rules is an essential element of OSPF
    routing protocol design.  In reviewing Sections 6.1 - 6.5 of the
    draft, we observed that several new mechanisms are being
    proposed to address this important problem.  It was observed
    that RFC 2966, which has already considered and addressed
    such issues, appears to contain an applicable, relatively simple
    solution mechanism (within Section 3.1) that is not specific to the
    IS-IS protocol.  Given RFC 2966 offers a solution that has been
    proven and implemented by multiple vendors, yielding the potential
    opportunity for reuse, we wondered whether you had identified
    any drawbacks in pursuing such an approach.

    Please provide us with your thoughts on the usage of this alternative
    method.

In our response liaison "Response to your liaison on current ASON
work in CCAMP" dated 21st February 2007 we replied:

     We are glad that you agree with our assessment that it
     is an essential element of OSPF routing protocol design
     to provide import/export rules to prevent feedback
     loops.

     RFC2966 presents a solution to this problem specific to
     the ISIS protocol, although, as you say, this mechanism
     could be adapted to other protocols.

     But other mechanisms also exist, and the ultimate
     solution that we choose must be agreed not by the ISIS
     community, but by the OSPF community. In this case, the
     choice was made after careful evaluation in cooperation
     with IETF's OSPF Working Group.

     Please let us know whether you have any technical
     issues with the approach we have chosen, and if so,
     what the issues are.

In your most recent liaison, you say:

    On the selection of a loop prevention mechanism the liaison
    statement indicates that  "the choice was made after careful
    evaluation in cooperation with IETF's OSPF Working Group."
    We would appreciate further details of these considerations to
    allow us to fully understand the thought going into this decision
    and evaluate any impacts on the transport network.

We are happy to provide a summary of the decision.

RFC 2966 is titled "Domain-wide Prefix Distribution with Two-Level
IS-IS", and the Abstract reads:

    This document describes extensions to the Intermediate System to
    Intermediate System (IS-IS) protocol to support optimal routing
    within a two-level domain.  The IS-IS protocol is specified in ISO
    10589, with extensions for supporting IPv4 (Internet Protocol)
    specified in RFC 1195 [2].

    This document extends the semantics presented in RFC 1195 so that a
    routing domain running with both level 1 and level 2 Intermediate
    Systems (IS) [routers] can distribute IP prefixes between level 1 and
    level 2 and vice versa.  This distribution requires certain
    restrictions to insure that persistent forwarding loops do not  form.
    The goal of this domain-wide prefix distribution is to increase the
    granularity of the routing information within the domain.

The problem that RFC 2966 addresses is for a two level domain. The
problem is that, because of the way IS-IS is defined to exchange IP
prefixes between levels, it is possible that a routing loop could
be formed. The issue arises when an IS-IS layer 1 area is dual
homed to the IS-IS layer 2 area and the prefixes advertised from
one layer into the other at one L1L2 router (Ra) are re-advertised
back into the originating IS-IS layer at another L1L2 router (Rb)
making it appear that the shortest path to a prefix from Rb is
through Ra. The fix in RFC 2966 uses the up/down bit to make sure
that advertisements do not continually circulate between layers.
RFC 3784 "Intermediate System to Intermediate System (IS-IS)
Extensions for Traffic Engineering (TE)" defines traffic
engineering information distribution mechanisms using IS-IS. This
work is further extended by RFC 4205 "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)". RFC 3784 allows the
extended reachability TLV to be exchanged between IS-IS layers.
This means that TE information can be exchanged between IS-IS
layers, and the up/down bit is necessary to stop the advertisements
circulating for ever.

But, it is important to note that since the TE information is used
to build a topology representation in the Traffic Engineering
Database, there is no risk of data looping. Contrast this with the
problem addressed in RFC 2966 where shortest path first
computations provided per IS-IS layer might cause data looping.
Thus, the only problem addressed by the use of the up/down bit in
RFC 3784 is that of endlessly circulating information.

Now, OSPF addresses the original looping problem in a different
way. It restricts the advertisement of prefixes between areas by
using different LSA types and flooding scopes. Thus, information
leaked from Area 0 into some other subtended area is never leaked
back into Area 0.

Further in OSPF-TE, there is no danger of endlessly looping
information between Area 0 and the subtended areas because RFC 3630
"Traffic Engineering (TE) Extensions to OSPF Version 2" instructs
us to use the type 10 opaque LSA for distributing TE information.
And, as defined in RFC 2370 "The OSPF Opaque LSA Option" a type 10
opaque LSA is not distributed outside the area in which it was
generated.

The problem that must be addressed in draft-dimitri-ccamp-gmpls-
ason-routing-ospf is caused because of a deliberate change in
information leakage processing. That is, in the ASON network,
selected upward and downward redistribution of TE information is
allowed. Thus, OSPF-TE is opened up to the possibility of
information distribution looping (although still not of looping of
computed data paths).

As section 6.3 of draft-dimitri-ccamp-gmpls-ason-routing-
ospf-03.txt says:

   When more than one RC are bound to adjacent levels of the hierarchy,
   configured and selected to redistribute upward and downward the
   routing information, a specific mechanism is required to avoid
   looping/re-introduction of routing information back to the upper
   level. This specific case occurs e.g. when the RC advertising
   routing information downward the hierarchy is not the one
   advertising routing upward the hierarchy (or vice-versa).

   When these conditions are met, it is necessary to have a means by
   which an RC receiving an Opaque TE LSA imported/exported
   downward by an RC associated with the same area, suppresses the
   import/export back of the content of this LSA upward into the
   (same) upper level.

Clearly it is necessary to add some indication of the origin of the
data into the advertisement. The mechanism proposed in draft-
dimitri-ccamp-gmpls-ason-routing-ospf-03.txt is to add the Area ID
of the OSPF area containing the originating RC. This provides more
information than the simple up/down bit of RFC 2966 and allows an
easy distinction to be made between advertising information
received from a lower layer area down into a different lower layer
area, and back into the same lower layer area.

We hope this clarifies the similarities and differences with RFC
2966, and hope that you will ask if you have further specific
questions. As before, we encourage you to examine the resulting
functionality and to provide us with technical arguments if you
believe the function is inappropriate for a transport network, or
if you see any specific issues with the proposed approach.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

Delivery-date: Tue, 24 Apr 2007 17:09:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft liaison to ITU-T on their OTNT Work Plan
Date: Tue, 24 Apr 2007 18:01:54 +0100
Organization: Old Dog Consulting

CCAMP,

In we received a copy of ITU-T Study Group 15's work plan for Optical
Transport Networking, with a request that we review and comment by 30th
April.

We touched on this in Prague, and subsequently on the mailing list a
little.

Attached is a proposed response. Please comment by 27th April so that I
can send the liaison on time.

Thanks,
Adrian.
===
To: ITU-T Question 3/15
From: IETF CCAMP Working Group
Cc: Stephen Trowbridge, Hiroshi Ohta, Scott Bradner, Dave Ward, Ross
Callon, Loa Andersson, JP Vasseur, CCAMP Working Group,
PCE Working Group
Subject: SG15 OTNT Standardisation Work Plan
For Information

The CCAMP Working Group of the IETF thanks you for sharing your OTNT
Work Plan and for soliciting our comments.

We have the following two points that you may want to use to update your
document.

1. Table 5-1

This table lists standardisation activities for carrier-class Ethernet
in various SDOs.

The CCAMP working group has the responsibility within the IETF for
developing common control plane and measurement plane solutions for use
within transport networks, and layer 2 (for example, Ethernet) is within
scope for our work. The working group has been discussing the
application of GMPLS protocols to the dynamic control of Ethernet
networks with the following results:

a. draft-ietf-ccamp-ethernet-traffic-parameters-01.txt

This Internet-Draft documents extensions to the RSVP-TE signaling
protocol to express Ethernet traffic parameters so that GMPLS can
be used to set up Ethernet LSPs and to request Ethernet services at a
GMPLS UNI. The draft can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-01.txt

b. GMPLS Ethernet Label Switching (GELS)

The GELS effort is intended to develop a single set of protocol
extensions that are applicable to the establishment of LSPs through an
Ethernet network.

Currently there are several proposals of what type of Ethernet network
may benefit from this type of control plane, and the appropriateness of each
proposed data plane will be verified with the IEEE before CCAMP attempts
to apply a control plane.

Currently there are several individual submission Internet-Drafts that
have started to lay out the requirements and potential solutions for the
GMPLS protocol extensions.

2. Table 7-1

Table 7-1 provides a long list of related OTNT industry standards and
specifications.

a. GMPLS and Optical-related RFCs

We would like to suggest some additions to this list from the IETF as
follows:

RFC 3471 : Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description
RFC 3473 : Generalized Multi-Protocol Label Switching (GMPLS)Signaling
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
RFC 4652 : Evaluation of Existing Routing Protocols against Automatic
Switched Optical Network (ASON) Routing Requirements
RFC 4726 : A Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering
RFC 4736 : Reoptimization of Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Loosely Routed Label Switch Path (LSP)
RFC 4783 : GMPLS - Communication of Alarm Information
RFC 4801 : Definitions of Textual Conventions for Generalized
Multiprotocol Label Switching (GMPLS) Management
RFC 4802 : Generalized Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base
RFC 4803 : Generalized Multiprotocol Label Switching (GMPLS)Label
Switching Router (LSR) Management Information Base
RFC 4874 : Exclude Routes - Extension to Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)

The latest list of CCAMP RFCs can be found at the CCAMP Charter page,
http://www.ietf.org/html.charters/ccamp-charter.html

b. GMPLS and Optical-related Internet-Drafts

We welcome your listing of Internet-Drafts for related work. We make the
following observations:

i.  All Internet-Drafts should be identified as "work in progress". This
request is made, as standard, by the IETF in the following boilerplate
text at the head of every Internet-Draft...

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

ii. The following Internet-Drafts in Table 7-1 have been replaced with
RFCs as listed above:

draft-ietf-ccamp-gmpls-tc-mib
draft-ietf-ccamp-gmpls-te-mib
draft-ietf-ccamp-gmpls-lsr-mib
draft-ietf-ccamp-rsvp-te-exclude-route
draft-ietf-ccamp-gmpls-alarm-spec
draft-ietf-ccamp-inter-domain-framework
draft-ietf-ccamp-loose-path-reopt
draft-ietf-ccamp-gmpls-ason-routing-eval

iii. Additional Internet-Drafts

You may wish to list the following CCAMP Internet-Drafts as relevant to
your work:

draft-ietf-ccamp-inter-domain-rsvp-te-05.txt
Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering - RSVP-TE extensions

draft-ietf-ccamp-lsp-stitching-05.txt
Label Switched Path Stitching with Generalized Multiprotocol Label
Switching Traffic Engineering (GMPLS TE)

draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
Calls

draft-ietf-ccamp-lsp-hierarchy-bis-01.txt
Procedures for Dynamically Signaled Hierarchical Label Switched Paths

draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt
Framework for MPLS-TE to GMPLS migration

draft-ietf-ccamp-ethernet-traffic-parameters-01.txt
MEF Ethernet Traffic Parameters

draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt
OSPFv2 Routing Protocols Extensions for ASON Routing

draft-ietf-ccamp-mpls-graceful-shutdown-02.txt
Graceful Shutdown in GMPLS Traffic Engineering Networks

draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment
Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)

draft-ietf-ccamp-gmpls-ted-mib-01.txt
Traffic Engineering Database Management Information Base in support of
GMPLS

draft-ietf-ccamp-pc-and-sc-reqs-00.txt
Requirements for the Conversion Between Permanent Connections and
Switched Connections in a Generalized Multiprotocol Label Switching
(GMPLS) Network

draft-ietf-ccamp-mpls-gmpls-interwork-reqts-00.txt
Interworking Requirements to Support operation of MPLS-TE over GMPLS
networks

draft-ietf-ccamp-inter-domain-recovery-analysis-00.txt
Analysis of Inter-domain Label Switched Path (LSP) Recovery

The latest list of CCAMP Internet-Drafts can be found at the CCAMP
Charter page, http://www.ietf.org/html.charters/ccamp-charter.html

iv. Expired Internet-Drafts

The following Internet-Drafts listed in table 7-1 have expired and are
not being pursued.

draft-ietf-ipo-impairments
draft-ietf-ipo-framework

c. Path Computation-related RFCs and Internet-Drafts

In the light of G.7715.2 you may also be interested in including the
Path Computation Element (PCE) RFCs and Internet-Drafts within
table 7-1 as follows:

RFC 4655 : A Path Computation Element (PCE) Based Architecture
RFC 4657 : Path Computation Element (PCE) Communication Protocol Generic
Requirements
RFC 4674 : Requirements for Path Computation Element (PCE) Discovery

draft-ietf-pce-pcep-07.txt
Path Computation Element (PCE) communication Protocol (PCEP)

draft-ietf-pce-inter-layer-req-04.txt
PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering

draft-ietf-pce-pcecp-interarea-reqs-05.txt
PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area
Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering

draft-ietf-pce-inter-layer-frwk-03.txt
Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering

draft-ietf-pce-policy-enabled-path-comp-01.txt
Policy-Enabled Path Computation Framework

draft-ietf-pce-interas-pcecp-reqs-01.txt
Inter-AS Requirements for the Path Computation Element Communication
Protocol (PCECP)

draft-ietf-pce-brpc-04.txt
A Backward Recursive PCE-based Computation (BRPC) procedure to compute
shortest inter-domain Traffic Engineering Label Switched Paths

draft-ietf-pce-disco-proto-ospf-03.txt
OSPF protocol extensions for Path Computation Element (PCE) Discovery

draft-ietf-pce-disco-proto-isis-03.txt
IS-IS protocol extensions for Path Computation Element (PCE) Discovery

draft-ietf-pce-disc-mib-01.txt
Definitions of Managed Objects for Path Computation Element Discovery

draft-ietf-pce-tc-mib-01.txt
Definitions of Textual Conventions for Path Computation Element

draft-ietf-pce-pcep-xro-00.txt
Extensions to the Path Computation Element Communication Protocol (PCEP)
for Route Exclusions

The latest list of PCE RFCs and Internet-Drafts can be found at the PCE
Charter page, http://www.ietf.org/html.charters/pce-charter.html

d. Obsoleted specification

Please note that RFC 4327 has been obsoleted by RFC 4631 and should no
longer be listed in its own right.

e. MPLS and Packet-related RFCs and Internet-Drafts

We suggest that in the light of the recent work within the ITU-T related
to packet transport networks including, but not limited to, pseudowires and
T-MPLS, you may wish to contact Mr. Loa Andersson who is IETF liaison to
the ITU-T on MPLS to see what new and relevant MPLS RFCs and Internet-
Drafts have been published.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

Delivery-date: Tue, 24 Apr 2007 10:26:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>, "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>
Subject: Draft Liaison to ITU-T Q14/15 on GMPLS Calls
Date: Tue, 24 Apr 2007 11:25:09 +0100
Organization: Old Dog Consulting

Hi,

Here is the first of the draft liaisons for your review.

Comments (positive or constructive) by 1st May, please.

Thanks,
Adrian and Deborah

===
To: ITU-T Q14/15
From: IETF CCAMP Working Group
Cc: Stephen Trowbridge, Kam Lam, Scott Bradner, Dave Ward, 
    Ross Callon, 
CCAMP Working Group
Subject: GMPLS Calls
For Information

The IETF's CCAMP Working Group thanks you for your liaison
entitled "Liaison Statement to CCAMP regarding work on 
calls and Vcat/LCAS" issued from your Darmstadt interim
meeting in March 2007.

Our liaison to you and copied to Q11/15 "VCAT/LCAS Work in
CCAMP" dated 4th April 2007 responded to the points raised
with respect to VCAT and LCAS. This liaison is to respond
to the remaining points with respect to GMPLS Calls.

At the time of your liaison, our Internet-Draft, 
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt "Generalized
MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
Calls", was already well advanced through the approval 
process to become an RFC. The draft has subsequently been 
approved for publication as an RFC and is awaiting formal
publication by the RFC Editor. It was, therefore, too late
at the time of your request for us to liaise this document
to you for review prior to publication.

Although your review is always valuable, in this instance, 
it was not a necessity. draft-ietf-ccamp-gmpls-rsvp-te-call
defines mechanisms for use in GMPLS networks to establish 
and maintain calls, and to associate LSPs (connections) 
with those calls. These call mechanisms are general, 
and no ASON application specific procedures are specified.
It is anticipated that new Internet-Drafts will be written
by interested parties to define application-specific call
procedures and protocol extensions (if needed). A first
example of this can be seen in draft-ietf-ccamp-gmpls-vcat-
lcas "Operating Virtual Concatenation (VCAT) and  the Link 
Capacity Adjustment Scheme (LCAS) with Generalized Multi-
Protocol Label Switching (GMPLS)".

You note that section 2.1 of the draft says:

   [RFC4139] details the requirements on GMPLS signaling to
   satisfy the ASON architecture described in [G.8080]. The
   mechanisms described in this document meet the
   requirements for Calls as described in Sections 4.2 and
   4.3 of [RFC4139] and the additional Call-related
   requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139].

   [ASON-APPL] describes the applicability of GMPLS 
   protocols to the ASON architecture."

We consider that it will be essential to get your review of
this referenced draft ([ASON-APPL]) that will set out the 
applicability, procedures, and any protocol extensions 
necessary for the use of these generic GMPLS Call
mechanisms in the ASON environment.

The referenced draft is currently in abeyance. A new
version describing how to meet the requirements of ASON
signaling using GMPLS protocols and mechanisms will be 
produced if there is interest from within the community. If
such a draft is produced, you may be sure that we will 
liaise it to you for your comments and opinions.

We would, nevertheless, welcome any comments or questions
that you have after reading the approved document. 
Questions may be sent directly to the CCAMP mailing list or
raised through a formal liaison.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs 

Delivery-date: Tue, 24 Apr 2007 10:21:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updates to three inter-domain I-Ds
Date: Tue, 24 Apr 2007 11:17:03 +0100
Organization: Old Dog Consulting

Hi,

The latest revisions of the three I-Ds...

-  draft-ietf-ccamp-lsp-stitching-06.txt
-  draft-ietf-ccamp-inter-domain-rsvp-te-06.txt
-  draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt

just fix ID-nits issues (mainly references) that needed to be sorted out 
before we can pass the I-Ds to the AD.

Adrian 

Delivery-date: Tue, 24 Apr 2007 10:19:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Next steps with ITU-T Liaison Responses
Date: Tue, 24 Apr 2007 11:13:31 +0100
Organization: Old Dog Consulting

Hi,

Deborah and I are in the process of preparing the next set of liaison 
response to the ITU-T.

1. GMPLS Calls
     Response to request to review this work.
     Current status report
     Explanation of relationship to ASON work

2. OTNT Work Plan
     Review of their Optical Transport Networks work plan
     Suggestions of more cross-references to include

3. Loop Prevention in OSPF ASON Routing
    Discussion of why we chose the techniques in our draft
    compared with the mechanisms in RFC 2966

4. OSPF ASON Detailed Response
    Response to the detailed questions raised in review of
    v02 of our draft.

As these pop up on the mailing list, please let us know your thoughts.

Thanks,
Adrian 

Delivery-date: Mon, 23 Apr 2007 19:52:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-06.txt 
Date: Mon, 23 Apr 2007 15:50:02 -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		: Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
	Author(s)	: A. Ayyangar, et al.
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-06.txt
	Pages		: 21
	Date		: 2007-4-23
	
This document describes procedures and protocol extensions for the
   use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
   signaling in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
   non-packet networks to support the establishment and maintenance of
   Label Switched Paths that cross domain boundaries.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP routing areas, and GMPLS overlay networks.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 23 Apr 2007 19:52:43 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-06.txt 
Date: Mon, 23 Apr 2007 15:50:02 -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		: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
	Author(s)	: A. Ayyangar, et al.
	Filename	: draft-ietf-ccamp-lsp-stitching-06.txt
	Pages		: 19
	Date		: 2007-4-23
	
In certain scenarios, there may be a need to combine together several
   Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
   Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
   all traffic from one constituent LSP is switched onto the next LSP.
   We will refer to this as "LSP stitching", the key requirement being
   that a constituent LSP not be allocated to more than one e2e LSP.
   The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

   This document describes extensions to the existing GMPLS signaling
   protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs,
   and describes how the LSPs can be managed using the GMPLS signaling
   and routing protocols.

   It may be possible to configure a GMPLS node to switch the traffic
   from an LSP for which it is the egress, to another LSP for which it
   is the ingress, without requiring any signaling or routing extensions
   whatsoever, completely transparent to other nodes.  This will also
   result in LSP stitching in the data plane.  However, this document
   does not cover this scenario of LSP stitching.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lsp-stitching-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 23 Apr 2007 19:52:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt 
Date: Mon, 23 Apr 2007 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
	Pages		: 21
	Date		: 2007-4-23
	
This document specifies a per-domain path computation technique for
   establishing inter-domain Traffic Engineering (TE) Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
   Paths (LSPs).  In this document a domain refers to a collection of
   network elements within a common sphere of address management or path
   computational responsibility such as IGP areas and Autonomous
   Systems.

   Per-domain computation applies where the full path of an inter-domain
   TE LSP cannot be or is not determined at the ingress node of the TE
   LSP, and is not signaled across domain boundaries.  This is most
   likely to arise owing to TE visibility limitations.  The signaling
   message indicates the destination and nodes up to the next domain
   boundary.  It may also indicate further domain boundaries or domain
   identifiers.  The path through each domain, possibly including the
   choice of exit point from the domain, must be determined within
   the domain.

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Sun, 22 Apr 2007 16:03:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-addressing-06.txt 
Date: Sun, 22 Apr 2007 17:00:29 +0100
Organization: Old Dog Consulting

Hi,

After some delay, this I-D has been updated as requested by the working 
group to move it on to the Informational track.

As well as the obvious change to the front page, all of the 2119 language 
has been removed and references have been inserted to the definitive 
material in other RFCs.

The Abstract now clearly states "This document does not define new 
procedures of processes."

And the Introduction contains...

   This document does not define new procedures of processes and the
   protocol specifications listed above should be treated as definitive.

I think this should be compatible with the working group's wishes, and I 
think that the I-D is now in relatively good shape to be taken to the IESG, 
so...

This begins a two week working group last call. Please send your comments to 
the mailing list.

The last call will end at 6pm GMT on Sunday 6th May 2007.

Thanks,
Adrian 

Delivery-date: Sat, 21 Apr 2007 12:33:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Three liaison statements received from the ITU-T Study Group 15 Question 14
Date: Sat, 21 Apr 2007 13:27:55 +0100
Organization: Old Dog Consulting

Hi,

At their meeting in Chicago earlier this month, Q14/15 generated three 
responses to our liaisons.

You can see these at www.olddog.co.uk/ccamp.htm or on the IETF liaison page 
as follows:

Liaison Statement to IETF CCAMP on Call/Connection Separation in ASON and 
GMPLS
https://datatracker.ietf.org/documents/LIAISON/file420.doc

Liaison Statement to IETF CCAMP on Multi-Layer Networking
https://datatracker.ietf.org/documents/LIAISON/file419.doc

Liaison Statement to IETF CCAMP on VCAT/LCAS Signalling
https://datatracker.ietf.org/documents/LIAISON/file418.doc

The third of these is for Action and needs a response from us by 28th May 
2007

Adrian

Delivery-date: Fri, 20 Apr 2007 16:26:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Fri, 20 Apr 2007 18:23:15 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi all.

I agree with you, Attila. The needs will come from higher network layers =
near the edge. All the same, there is no intend to modify the existing =
solution for symmetrical lower layer applications in the core, but only =
a wish to extend the tools to encompass the bidirectionnal symmetrical =
case to be used where needed. I would say the most typical use (and =
current requirement) is Ethernet, but at least any packet-based =
technology handled by GMPLS could benefit from it.

Have a nice week-end,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs (IJ/ETH)

Hi Igor, Neil, and all,

I think it is quite useful to have this discussion on networking modes, =
topology builder services and the relations to GMPLS LSPs.=20

I agree with Neil that the answer is context sensitive.
One can have Ethernet LSPs operating in different modes: co-ps and cl-ps =
irrespective to what these are used for, i.e, being a server layer and =
building a client layer topology, or being at the top of the layers and =
directly supporting services. However, while the former requires co-ps =
mode to operate properly, as pointed out by Neil, the latter can be =
build on co-ps and cl-ps modes primarily depending on the requirements =
of the service. Hence, I think (and I assume this is referred to as =
context sensitive by Neil) asymmetry may be useful for LSPs residing =
higher in the layer stack regardless of co-ps or cl-ps mode of =
operation.=20

Additionally, very much related to the layering/hierarchy, LSPs nearer =
to the edges of the network will likely experience asymmetry imho, =
compared to LSP in the core.

Regards,
Attila

Ps.: well it seems I have just repeated what has been said already, =
sorry!=20

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]=20
>=20
> Neil,
>=20
> Let's assume you've got clean co-ps connections(e.g. Ethernet=20
> connections). My understanding is that you believe that the=20
> bandwidth asymmetricity is useful for p2mp such connections,=20
> but not for p2p connections. Is that correct?
>=20
> Thanks,
> Igor
> =20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of [email-masked]
>=20
> Lou Berger asked 19 April 2007 15:05
>=20
> >=20
> >=20
> > Neil,
> >          I agree with Igor, much thanks for your input.
> >=20
> > In reading your response, it's clear that you see a place for=20
> > bidirectional asymmetric-bandwidth *service*.  I think=20
> there is (and=20
> > has been) general agreement on this.
> >=20
> > What's not clear to me is if you think there is any requirement for=20
> > bidirectional asymmetric **LSPs**.  Do you have an opinion on this?
> NH=3D> Well, it depends what you mean by an LSP.  As I've tried=20
> to point out in the past there are very good scientific=20
> reasons why we are forced to deal with 3 network=20
> modes...cl-ps, co-ps and co-cs...and why all technologies map=20
> to one of these.  Moreover the modes are fundamentally=20
> different...and you cannot apply the same treatment to them=20
> all.  We've done lots of work in explaining this within SG15=20
> unified modelling based on Information Theory considerations=20
> of how both the labelling AND resource assignment work in=20
> space, freq and time dimensions.  The space and freq=20
> dimensions always force a co-cs mode behaviour.  However, it=20
> is how one slices up the time dimension that generates either=20
> the (TDM spin of the) co-cs mode or the co-ps mode.  Without=20
> getting into too much detail, when the time slices are=20
> regular (ie fixed in BOTH start datum AND duration) then=20
> labelling (which is also implicit) and resource assignment=20
> are coupled/fixed and the co-cs mode results.  However, when=20
> the time slices are irregular then labelling (which now has=20
> to be explicit) and resource assignment are decoupled the=20
> co-ps mode results.
>=20
> The co-cs mode is extremely robust to arch misuse.  For=20
> example, one cannot violate the rules of a connection (ie=20
> single source, no internal routing) in the co-cs mode...and a=20
> connection is a crucial pre-requiste for all manner of things=20
> that one oftens wants determinsism on, like OAM and resource=20
> assignment per se for SLAs. The co-cs mode also has other=20
> desirable properties (like must have OOB control/management,=20
> no QoS classes, etc) which are highly beneficial and make=20
> networking simple...esp for network builder services (ie=20
> constructing the topology of other layer networks).
>=20
> Now the co-ps is not so robust to arch misuse.  One can=20
> create mp2p merging constructs for example, as we find in=20
> MPLS.  These cannot have simple OAM nor can they provide=20
> deterministic resource assignment/management.
>=20
> So, when you says LSPs you have to (i) be clear on the=20
> network mode you are referring to and (ii) if the co-ps mode=20
> whether or not the LSP respects the requirements of a=20
> connection...as not all LSPs do here.  Aside =3D> One can=20
> clearly not construct client layer topoplogy from mp2p server=20
> layer constructs!
>=20
> If I am providing (or indeed procuring) a network builder=20
> service (ie I want to construct the topology of some higher=20
> client layer network....be this a public service network or=20
> indeed a private (VPN) network) then I would want 'LSPs' that=20
> respect the requirements of a connection...because I want to=20
> see some strong SLAs associated with that service.  In the=20
> general case these would be based on p2p BW symmetric=20
> constructs.  However, in the case of end-system applications=20
> supporting specific services like the ones I referred to in=20
> my response to Igor then the requirement may not indeed be=20
> symmetric....the p2mp *connection* being a case in point for=20
> say TV dist (residential) or financial data distribution=20
> (business/private).
>=20
> Not sure if that helps Lou, but its the best I can offer for now.
>=20
> regards, Neil
>=20
> =20
> >=20
> > (if you already stated this, my apologies that I didn't=20
> understand you=20
> > ...)
> >=20
> > Thanks,
> > Lou
> >=20
> > At 09:18 AM 4/19/2007, [email-masked] wrote:
> >=20
> > >Thanks Igor....I think the answer is context sensitive. =20
> For example:
> > >
> > >-    are we dealing with a client/server network=20
> > >builder private service?...which may contain a large number of=20
> > >aggregate end-system client application traffic flows
> > >-    are we dealing with a single 'end system to=20
> > >1st layer network adaptation' service?...which may be a public or=20
> > >private service
> > >
> > >In the former case, and increasingly so as one moves towards the=20
> > >duct, there is (of necessity) a lack of detailed information of=20
> > >higher client BW requirements.  So here there is a natural case to=20
> > >want to provide symmetric BW resources....and the atomic building=20
> > >block for such services are p2p constructs.
> > >
> > >However, when we look towards specific end-system services=20
> there is=20
> > >more scope for BW resource asymmetry.......a video=20
> streaming service=20
> > >would probably be like this.  Further, it may not be=20
> simply p2p but=20
> > >p2mp.  I can also imagine some creative thinking wrt to=20
> using a co-ps=20
> > >mode with proper p2mp *connections* providing the service in one=20
> > >direction (ie root to leaves) ....because we want some strong=20
> > >resource assignment and SLA guarantees, eg distributing financial=20
> > >information to traders.....but a cl-ps mode return network=20
> (leaves to=20
> > >root) providing 'control signals'
> > >(where strong resource assignment may not be so important).  The=20
> > >return direction could however be a set of N p2p connections=20
> > >(probably congruently routed wrt to the other direction) if strong=20
> > >resource assignment and SLAs were also required in the return=20
> > >direction.  The former case here could be considered quite=20
> novel as=20
> > >the overall service is using 2 network modes and, by definition, 2=20
> > >different layer networks....so here there is large degree of=20
> > >asymmetry here.
> > >
> > >So, as one moves towards the duct (and in general for=20
> network builder=20
> > >services) there is, IMO, a strong requirement for symmetry in all=20
> > >aspects, but as one moves towards the application there are cases=20
> > >where asymmetry is more appropriate.
> > >
> > >regards, Neil
> > >
> > >
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]]
> > >
> > >Neil,
> > >
> > >I consider your input very important to this discussion.
> > >
> > >My question is: Do you see use cases for bidirectional p2p=20
> services=20
> > >which are asymmetrical from the bandwidth reservation=20
> point of view=20
> > >(that is, in S=3D>D direction you need bandwidth B1, while in =
D=3D>S=20
> > >direction you need bandwidth B2, and B1 is significantly different=20
> > >from B2), but fully symmetrical in all other aspects (i.e. routes,=20
> > >protection capability, etc.)
> > >
> > >Thanks,
> > >Igor
> > >
> > >[email-masked] wrote:
> > >Thanks Martin,
> > >
> > >Most applications generate asymmetric (wrt time)=20
> information flows in=20
> > >each direction, ie the rate of information flow in each=20
> direction is=20
> > >neither constant nor directly proportional to the rate of=20
> information=20
> > >flow in the other direction....just think about a voice=20
> conversation=20
> > >if not obvious....or even a file transfer.
> > >
> > >However, for an arbitrarily meshed network we generally require=20
> > >symmetric routings of traffic flows, ie if one direction=20
> passes the=20
> > >nodes
> > >a->b->c->d in one direction then the other
> > >direction should follow d->c->b->a in both this and lower layer=20
> > >networks (to the duct).
> > >Moreover, we usually require (under failure free
> > >conditions) that such routings do not change over the=20
> lifetime of a=20
> > >traffic flow.......this is particularly important for=20
> connections (ie=20
> > >co-ps and co-cs modes), and especially when they are supporting a=20
> > >network builder service (a VPN if you like), which may be a large=20
> > >aggregate of all kinds of end-system application traffic=20
> flows, for=20
> > >some other party. Note that if we add nodes/links to a co=20
> mode layer=20
> > >network we should not change existing connection routings. This is=20
> > >not always the case with a cl-ps mode network, ie because=20
> we do not=20
> > >have connections adding new nodes/links can allow traffic flows to=20
> > >change routing.
> > >
> > >Is that more clear now wrt what I meant?
> > >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Martin Vigoureux=20
> [mailto:[email-masked]]
> > > >
> > > > Neil,
> > > >
> > > > for clarification purposes, the asymmetry I was referring
> > to was in
> > > > terms of bandwidth not path/route or other TE parameter,
> > but maybe I
> > > > did not catch what you meant by *routings*.
> > > >
> > > > regards,
> > > >
> > > > martin
> > > >
> > > > [email-masked] a =E9crit :
> > > > > I would caution against the observation that because
> > traffic flows
> > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > consumed at any
> > > > > epoch) their *routings* can also be asymmetric....this does
> > > > not follow
> > > > > at all. This observation applies to all layer networks (any=20
> > > > > mode/technology).
> > > > >
> > > > > regards, Neil
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: [email-masked]
> > [mailto:[email-masked]]
> > > > >>
> > > > >> All,
> > > > >>
> > > > >> I do believe in the need for asymmetric bidirectional LSPs.=20
> > > > >> Traffic is by nature asymmetric (for the vast majority
> > of it at
> > > > >> least). We may argue that the sum of asymmetric=20
> traffic could=20
> > > > >> lead to symmetric traffic or that the above statement is=20
> > > > >> dependent on the network segment we are considering,
> > but it will
> > > > >> remain true and we should definitely capitalize on=20
> CCAMP prior=20
> > > > >> work by taking benefit from the advantages of
> > bidirectional LSP
> > > > >> setup.
> > > > >>
> > > > >> Furthermore, I believe we should not restrict the work and=20
> > > > >> solution to Ethernet technology only.
> > > > >>
> > > > >> martin
> > > > >>
> > > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > > >>> Hi all,
> > > > >>> please see inline [at]
> > > > >>> Regards,
> > > > >>> Attila
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> *From:* [email-masked]
> > > > >> [mailto:[email-masked]]
> > > > >>>
> > > > >>> Adrian, Lou
> > > > >>>
> > > > >>> Please,see in line.
> > > > >>>
> > > > >>> */Adrian Farrel /* wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> I'm a bit surprised that there was no follow-up to
> > Lou's email.
> > > > >>>
> > > > >>> Does silence indicate that this was put to bed in
> > > > Prague and
> > > > >>> no-one is
> > > > >>> interested in these LSPs?
> > > > >>>
> > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > continue an
> > > > >>> offline discussion on the topic.
> > > > >>>
> > > > >>> > So a few of us have been having been discussing the
> > > > >>> asymmetric work
> > > > >>> > presented in Prague and it seems to me we have an open
> > > > >>> question on
> > > > >>> > requirements.
> > > > >>> >
> > > > >>> > It's clear that at least one switching
> > > > technology (i.e.,
> > > > >>> ethernet/PBB-TE)
> > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > >>>
> > > > >>> Is this clear? I continue to hear talk of service
> > > > >> requirements,
> > > > >>> but not so
> > > > >>> much of how those services are required to be supported.
> > > > >>>
> > > > >>> The benefits I have heard are:
> > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of=20
> > > > >>> fate-sharing
> > > > >>>
> > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > >> bidirectional
> > > > >>> LSPs, and BTW you forgot to mention the most
> > > > important one.
> > > > >>> Ethernet OAM is designed, as I understand, on
> > > > >> assumption that
> > > > >>> the trafic takes the same paths in both
> > > > >> directions. So, if we
> > > > >>> want to preserve the Ethernet native OAM (which we
> > > > >> certainly do
> > > > >>> , because this is half of Ethernet functionality)
> > > > >> we must map a
> > > > >>> bidiretcional service on either a single
> > > > >> bidirectional LSP or
> > > > >>> two unidirectional LSPs using the same path. This
> > > > >> is different
> > > > >>> form MPLS where there are no such OAM requirements.
> > > > >>> Lou is talking about asymetrical bi-directional
> > > > >> LSPs, and what
> > > > >>> is not clear (at least for me) whether we need
> > > > >> asymetrical p2p
> > > > >>> Ethernet services.
> > > > >>>
> > > > >>> [at] Adrian's points are related to the single session vs.=20
> > > > >>> multiple session discussions we had, which is
> > > > >> generally true for
> > > > >>> any bidirectional LSP.
> > > > >>> The bidirectionality of Ethernet comes basically from two=20
> > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > >> most of the
> > > > >>> CFM functions will only operate properly if there are=20
> > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > GMPLS LPS is
> > > > >>> essentially a VLAN within which MAC learning is
> > > > >> operating one
> > > > >>> will need symmetric paths in order the learning functions=20
> > > > >>> properly.
> > > > >>>
> > > > >>> I had the impression that we already converged
> > > > >> before Prague to
> > > > >>> a single remaining question: do we need the
> > > > >>>> asymmetric bw<<
> > > > >>> extension for a single session bidirectional LSP.
> > > > There were
> > > > >>> some possible cases for asymmetric bw LSPs
> > > > mentioned by Don,
> > > > >>> Diego and myself but these seemed not to convince=20
> everybody.=20
> > > > >>> Imho we should focus on this question
> > > > not to loop
> > > > >>> into the discussion we had already.
> > > > >>>
> > > > >>> If we agree on that bidirectional services over
> > > > >> Ethernet need
> > > > >>> symmetrical paths than we could conclude that
> > > > using a single
> > > > >>> session to setup the bidirectional LSP would be the
> > > > >> preferred
> > > > >>> way at least over Ethernet. In this case, imho it is quite=20
> > > > >>> reasonable to assume that asymmetrical services
> > > > >> that require a
> > > > >>> dedicated LSP would also use a single signaling
> > > > exchange to
> > > > >>> setup the LSP, hence there would be a need for the
> > > > >> asymmetric bw
> > > > >>> extension. Following this thinking, the question
> > > > >> turns into the
> > > > >>> aggregation/hierarchy discussion that was bought up
> > > > >> by Dimitri
> > > > >>> earlier. That is, do we have the need of LSPs per
> > > > >> service. My
> > > > >>> two cents: generally not but there are certain
> > > > >> services where it
> > > > >>> is indeed a reasonable assumption, e.g., IPTV or private=20
> > > > >>> services.
> > > > >>>
> > > > >>> These are significant, but not dramatic, requirements.
> > > > >>>
> > > > >>> > The question is:
> > > > >>> >
> > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > >>> > (a) a technology specific requirement, or
> > > > >>> > (b) one that is common (this is CCAMP after
> > > > >> all!) to multiple
> > > > >>> switching
> > > > >>> > technologies?
> > > > >>>
> > > > >>> CCAMP deals in transport networks. As far as I can
> > > > >> see the service
> > > > >>> requirements would be pretty much the same all transport=20
> > > > >>> networks and would certainly be applicable to=20
> packet, L2, and=20
> > > > >>> TDM (the latter because TDM will be called on to=20
> support L2).
> > > > >>>
> > > > >>> IB>> See my comment above: there is a differnce
> > > > >> between MPLS and
> > > > >>> Ethernet services. Also there are certainly
> > > > >> differences between
> > > > >>> MPLS and lambda services (use of the same lambda in both=20
> > > > >>> directions, for example). So each transport
> > > > >> technology may have
> > > > >>> distinct requirements WRT bidirectional services
> > > > >> and connections
> > > > >>> on which the services are mapped.
> > > > >>>
> > > > >>> > Please keep in mind that service requirements
> > > > are not the
> > > > >>> same thing as
> > > > >>> > switching technology requirements. For example,
> > > > >> we have long
> > > > >>> built
> > > > >>> > bidirectional asymmetric services on
> > > > unidirectional MPLS
> > > > >>> LSPs.
> > > > >>>
> > > > >>> Well, exactly!
> > > > >>> Perhaps someone can explain why the Ethernet
> > > > >> hardware is forced
> > > > >>> to require
> > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > >>>
> > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > >>> Ethernet OAM.
> > > > >>>
> > > > >>> Igor
> > > > >>>
> > > > >>> > The answer to this question will help determine
> > > > >> if we should
> > > > >>> have a
> > > > >>> > technology specific solution or a generic CCAMP
> > > > >> solution (as
> > > > >>> well as the
> > > > >>> > complexity of the solution.)
> > > > >>>
> > > > >>> We should not take any action that deliberately
> > > > precludes or
> > > > >>> makes more
> > > > >>> complex the genericisation (is that an American
> > > > >> word?) of the
> > > > >>> solution
> > > > >>> unless there is a significant difference in simplicity of=20
> > > > >>> solutions.
> > > > >>>
> > > > >>> But we should take no action at all unless there is
> > > > >> some more
> > > > >>> evidence of
> > > > >>> support for this work!
> > > > >>>
> > > > >>> Adrian
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> Ahhh...imagining that irresistible "new car" smell?=20
> Check out=20
> > > > >>> new cars at Yahoo! Autos.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > >>
> > > >=20
> > =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > WN
> > > > >>> hcnM->
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > >Ahhh...imagining that irresistible "new car" smell?
> > >Check out
> > ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
> _cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
FncwRzbGsDbmV3LWNhcnM->new=20
> >cars at Yahoo! Autos.
>=20
>=20
>=20
>=20

Delivery-date: Fri, 20 Apr 2007 10:26:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Fri, 20 Apr 2007 11:24:42 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Good point Alan.  I've also managed to discuss this topic briefly this =
morning with Andy Reid.  He largely agrees with what I have already =
said, and thinks the signalling should be able to cater for the majority =
case of symmetric BW/routing as a bi-directional set-up/tear-down =
operation.....which is the general case for client/server network =
builder situations, ie construction of a client layer topology.  =
However, the signalling should also be able to cater for unidirectional =
set-up when we need to provide asymmetry in BW and/or routing....usually =
a non-network builder situation, ie no higher layer network topology =
being constructed.

Hope that helps.

regards, Neil

> -----Original Message-----
> From: Mcguire,A,Alan,XGH51 R=20
> Sent: 20 April 2007 10:51
> To: [email-masked]; [email-masked];=20
> Harrison,N,Neil,JCGA1 R; [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
>=20
> Attila,
> PONs are a good example of asymmetry at the edge
> Alan=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Attila Takacs (IJ/ETH)
> Sent: 20 April 2007 10:33
> To: Igor Bryskin; Harrison,N,Neil,JCGA1 R; [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
> Hi Igor, Neil, and all,
>=20
> I think it is quite useful to have this discussion on=20
> networking modes, topology builder services and the relations=20
> to GMPLS LSPs.=20
>=20
> I agree with Neil that the answer is context sensitive.
> One can have Ethernet LSPs operating in different modes:=20
> co-ps and cl-ps irrespective to what these are used for, i.e,=20
> being a server layer and building a client layer topology, or=20
> being at the top of the layers and directly supporting=20
> services. However, while the former requires co-ps mode to=20
> operate properly, as pointed out by Neil, the latter can be=20
> build on co-ps and cl-ps modes primarily depending on the=20
> requirements of the service. Hence, I think (and I assume=20
> this is referred to as context sensitive by Neil) asymmetry=20
> may be useful for LSPs residing higher in the layer stack=20
> regardless of co-ps or cl-ps mode of operation.=20
>=20
> Additionally, very much related to the layering/hierarchy,=20
> LSPs nearer to the edges of the network will likely=20
> experience asymmetry imho, compared to LSP in the core.
>=20
> Regards,
> Attila
>=20
> Ps.: well it seems I have just repeated what has been said=20
> already, sorry!=20
>=20
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[email-masked]]
> > Sent: Thursday, April 19, 2007 10:51 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked];
> > Attila Takacs (IJ/ETH); [email-masked]; [email-masked]
> > Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric
> > LSPs?
> >=20
> > Neil,
> >=20
> > Let's assume you've got clean co-ps connections(e.g. Ethernet
> > connections). My understanding is that you believe that the=20
> bandwidth=20
> > asymmetricity is useful for p2mp such connections, but not for p2p=20
> > connections. Is that correct?
> >=20
> > Thanks,
> > Igor
> > =20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of [email-masked]
> > Sent: Thursday, April 19, 2007 12:28 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric
> > LSPs?
> >=20
> > Lou Berger asked 19 April 2007 15:05
> >=20
> > >=20
> > >=20
> > > Neil,
> > >          I agree with Igor, much thanks for your input.
> > >=20
> > > In reading your response, it's clear that you see a place for
> > > bidirectional asymmetric-bandwidth *service*.  I think
> > there is (and
> > > has been) general agreement on this.
> > >=20
> > > What's not clear to me is if you think there is any=20
> requirement for
> > > bidirectional asymmetric **LSPs**.  Do you have an=20
> opinion on this?
> > NH=3D> Well, it depends what you mean by an LSP.  As I've=20
> tried to point
> > out in the past there are very good scientific reasons why we are=20
> > forced to deal with 3 network modes...cl-ps, co-ps and=20
> co-cs...and why=20
> > all technologies map to one of these.  Moreover the modes are=20
> > fundamentally different...and you cannot apply the same=20
> treatment to=20
> > them all.  We've done lots of work in explaining this within SG15=20
> > unified modelling based on Information Theory considerations of how=20
> > both the labelling AND resource assignment work in space, freq and=20
> > time dimensions.  The space and freq dimensions always=20
> force a co-cs=20
> > mode behaviour.  However, it is how one slices up the time=20
> dimension=20
> > that generates either the (TDM spin of the) co-cs mode or the co-ps=20
> > mode.  Without getting into too much detail, when the time=20
> slices are=20
> > regular (ie fixed in BOTH start datum AND duration) then labelling=20
> > (which is also implicit) and resource assignment are=20
> coupled/fixed and=20
> > the co-cs mode results.  However, when the time slices are=20
> irregular=20
> > then labelling (which now has to be explicit) and resource=20
> assignment=20
> > are decoupled the co-ps mode results.
> >=20
> > The co-cs mode is extremely robust to arch misuse.  For example, one
> > cannot violate the rules of a connection (ie single source, no=20
> > internal routing) in the co-cs mode...and a connection is a crucial=20
> > pre-requiste for all manner of things that one oftens wants=20
> > determinsism on, like OAM and resource assignment per se=20
> for SLAs. The=20
> > co-cs mode also has other desirable properties (like must have OOB=20
> > control/management, no QoS classes, etc) which are highly=20
> beneficial=20
> > and make networking simple...esp for network builder services (ie=20
> > constructing the topology of other layer networks).
> >=20
> > Now the co-ps is not so robust to arch misuse.  One can create mp2p
> > merging constructs for example, as we find in MPLS.  These=20
> cannot have=20
> > simple OAM nor can they provide deterministic resource=20
> > assignment/management.
> >=20
> > So, when you says LSPs you have to (i) be clear on the network mode
> > you are referring to and (ii) if the co-ps mode whether or=20
> not the LSP=20
> > respects the requirements of a connection...as not all LSPs=20
> do here. =20
> > Aside =3D> One can clearly not construct client layer topoplogy from =

> > mp2p server layer constructs!
> >=20
> > If I am providing (or indeed procuring) a network builder=20
> service (ie
> > I want to construct the topology of some higher client layer=20
> > network....be this a public service network or indeed a=20
> private (VPN)=20
> > network) then I would want 'LSPs' that respect the=20
> requirements of a=20
> > connection...because I want to see some strong SLAs associated with=20
> > that service.  In the general case these would be based on p2p BW=20
> > symmetric constructs.  However, in the case of end-system=20
> applications=20
> > supporting specific services like the ones I referred to in my=20
> > response to Igor then the requirement may not indeed be=20
> > symmetric....the p2mp *connection* being a case in point for say TV=20
> > dist (residential) or financial data distribution=20
> (business/private).
> >=20
> > Not sure if that helps Lou, but its the best I can offer for now.
> >=20
> > regards, Neil
> >=20
> > =20
> > >=20
> > > (if you already stated this, my apologies that I didn't
> > understand you
> > > ...)
> > >=20
> > > Thanks,
> > > Lou
> > >=20
> > > At 09:18 AM 4/19/2007, [email-masked] wrote:
> > >=20
> > > >Thanks Igor....I think the answer is context sensitive.
> > For example:
> > > >
> > > >-    are we dealing with a client/server network=20
> > > >builder private service?...which may contain a large number of
> > > >aggregate end-system client application traffic flows
> > > >-    are we dealing with a single 'end system to=20
> > > >1st layer network adaptation' service?...which may be a=20
> public or=20
> > > >private service
> > > >
> > > >In the former case, and increasingly so as one moves towards the
> > > >duct, there is (of necessity) a lack of detailed information of=20
> > > >higher client BW requirements.  So here there is a=20
> natural case to=20
> > > >want to provide symmetric BW resources....and the atomic=20
> building=20
> > > >block for such services are p2p constructs.
> > > >
> > > >However, when we look towards specific end-system services
> > there is
> > > >more scope for BW resource asymmetry.......a video
> > streaming service
> > > >would probably be like this.  Further, it may not be
> > simply p2p but
> > > >p2mp.  I can also imagine some creative thinking wrt to
> > using a co-ps
> > > >mode with proper p2mp *connections* providing the service in one
> > > >direction (ie root to leaves) ....because we want some strong=20
> > > >resource assignment and SLA guarantees, eg distributing=20
> financial=20
> > > >information to traders.....but a cl-ps mode return network
> > (leaves to
> > > >root) providing 'control signals'
> > > >(where strong resource assignment may not be so important).  The
> > > >return direction could however be a set of N p2p connections=20
> > > >(probably congruently routed wrt to the other direction)=20
> if strong=20
> > > >resource assignment and SLAs were also required in the return=20
> > > >direction.  The former case here could be considered quite
> > novel as
> > > >the overall service is using 2 network modes and, by=20
> definition, 2
> > > >different layer networks....so here there is large degree of=20
> > > >asymmetry here.
> > > >
> > > >So, as one moves towards the duct (and in general for
> > network builder
> > > >services) there is, IMO, a strong requirement for symmetry in all
> > > >aspects, but as one moves towards the application there=20
> are cases=20
> > > >where asymmetry is more appropriate.
> > > >
> > > >regards, Neil
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Igor Bryskin [mailto:[email-masked]]
> > > >Sent: 19 April 2007 13:36
> > > >To: Harrison,N,Neil,JCGA1 R; [email-masked];
> > > >[email-masked]; [email-masked]; [email-masked]
> > > >Cc: [email-masked]
> > > >Subject: RE: Switching technologies requiring bidirectional
> > > asymmetric LSPs?
> > > >
> > > >Neil,
> > > >
> > > >I consider your input very important to this discussion.
> > > >
> > > >My question is: Do you see use cases for bidirectional p2p
> > services
> > > >which are asymmetrical from the bandwidth reservation
> > point of view
> > > >(that is, in S=3D>D direction you need bandwidth B1, while in =
D=3D>S
> > > >direction you need bandwidth B2, and B1 is significantly=20
> different=20
> > > >from B2), but fully symmetrical in all other aspects=20
> (i.e. routes,=20
> > > >protection capability, etc.)
> > > >
> > > >Thanks,
> > > >Igor
> > > >
> > > >[email-masked] wrote:
> > > >Thanks Martin,
> > > >
> > > >Most applications generate asymmetric (wrt time)
> > information flows in
> > > >each direction, ie the rate of information flow in each
> > direction is
> > > >neither constant nor directly proportional to the rate of
> > information
> > > >flow in the other direction....just think about a voice
> > conversation
> > > >if not obvious....or even a file transfer.
> > > >
> > > >However, for an arbitrarily meshed network we generally require
> > > >symmetric routings of traffic flows, ie if one direction
> > passes the
> > > >nodes
> > > >a->b->c->d in one direction then the other
> > > >direction should follow d->c->b->a in both this and lower layer
> > > >networks (to the duct).
> > > >Moreover, we usually require (under failure free
> > > >conditions) that such routings do not change over the
> > lifetime of a
> > > >traffic flow.......this is particularly important for
> > connections (ie
> > > >co-ps and co-cs modes), and especially when they are supporting a
> > > >network builder service (a VPN if you like), which may=20
> be a large=20
> > > >aggregate of all kinds of end-system application traffic
> > flows, for
> > > >some other party. Note that if we add nodes/links to a co
> > mode layer
> > > >network we should not change existing connection=20
> routings. This is
> > > >not always the case with a cl-ps mode network, ie because
> > we do not
> > > >have connections adding new nodes/links can allow=20
> traffic flows to
> > > >change routing.
> > > >
> > > >Is that more clear now wrt what I meant?
> > > >
> > > >regards, Neil
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin Vigoureux
> > [mailto:[email-masked]]
> > > > > Sent: 19 April 2007 09:37
> > > > > To: Harrison,N,Neil,JCGA1 R; [email-masked];
> > > > > [email-masked]; [email-masked]; [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Switching technologies requiring bidirectional=20
> > > > > asymmetric LSPs?
> > > > >
> > > > >
> > > > > Neil,
> > > > >
> > > > > for clarification purposes, the asymmetry I was referring
> > > to was in
> > > > > terms of bandwidth not path/route or other TE parameter,
> > > but maybe I
> > > > > did not catch what you meant by *routings*.
> > > > >
> > > > > regards,
> > > > >
> > > > > martin
> > > > >
> > > > > [email-masked] a =E9crit :
> > > > > > I would caution against the observation that because
> > > traffic flows
> > > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > > consumed at any
> > > > > > epoch) their *routings* can also be asymmetric....this does
> > > > > not follow
> > > > > > at all. This observation applies to all layer networks (any
> > > > > > mode/technology).
> > > > > >
> > > > > > regards, Neil
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: [email-masked]
> > > [mailto:[email-masked]]
> > > > > >> On Behalf Of Martin Vigoureux
> > > > > >> Sent: 19 April 2007 08:34
> > > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian=20
> Farrel; Lou
> > > > > >> Berger
> > > > > >> Cc: [email-masked]
> > > > > >> Subject: Re: Switching technologies requiring=20
> bidirectional=20
> > > > > >> asymmetric LSPs?
> > > > > >>
> > > > > >>
> > > > > >> All,
> > > > > >>
> > > > > >> I do believe in the need for asymmetric bidirectional LSPs.
> > > > > >> Traffic is by nature asymmetric (for the vast majority
> > > of it at
> > > > > >> least). We may argue that the sum of asymmetric
> > traffic could
> > > > > >> lead to symmetric traffic or that the above statement is
> > > > > >> dependent on the network segment we are considering,
> > > but it will
> > > > > >> remain true and we should definitely capitalize on
> > CCAMP prior
> > > > > >> work by taking benefit from the advantages of
> > > bidirectional LSP
> > > > > >> setup.
> > > > > >>
> > > > > >> Furthermore, I believe we should not restrict the work and
> > > > > >> solution to Ethernet technology only.
> > > > > >>
> > > > > >> martin
> > > > > >>
> > > > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > > > >>> Hi all,
> > > > > >>> please see inline [at]
> > > > > >>> Regards,
> > > > > >>> Attila
> > > > > >>>
> > > > > >>>
> > > > > >>=20
> > --------------------------------------------------------------
> > > > > >> ----------
> > > > > >>> *From:* [email-masked]
> > > > > >> [mailto:[email-masked]]
> > > > > >>> *On Behalf Of *Igor Bryskin
> > > > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > > > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > > > > >>> *Subject:* Re: Switching technologies requiring
> > bidirectional
> > > > > >>> asymmetric LSPs?
> > > > > >>>
> > > > > >>> Adrian, Lou
> > > > > >>>
> > > > > >>> Please,see in line.
> > > > > >>>
> > > > > >>> */Adrian Farrel /* wrote:
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> I'm a bit surprised that there was no follow-up to
> > > Lou's email.
> > > > > >>>
> > > > > >>> Does silence indicate that this was put to bed in
> > > > > Prague and
> > > > > >>> no-one is
> > > > > >>> interested in these LSPs?
> > > > > >>>
> > > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > > continue an
> > > > > >>> offline discussion on the topic.
> > > > > >>>
> > > > > >>> > So a few of us have been having been discussing the
> > > > > >>> asymmetric work
> > > > > >>> > presented in Prague and it seems to me we have an open
> > > > > >>> question on
> > > > > >>> > requirements.
> > > > > >>> >
> > > > > >>> > It's clear that at least one switching
> > > > > technology (i.e.,
> > > > > >>> ethernet/PBB-TE)
> > > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > > >>>
> > > > > >>> Is this clear? I continue to hear talk of service
> > > > > >> requirements,
> > > > > >>> but not so
> > > > > >>> much of how those services are required to be supported.
> > > > > >>>
> > > > > >>> The benefits I have heard are:
> > > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of
> > > > > >>> fate-sharing
> > > > > >>>
> > > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > > >> bidirectional
> > > > > >>> LSPs, and BTW you forgot to mention the most
> > > > > important one.
> > > > > >>> Ethernet OAM is designed, as I understand, on
> > > > > >> assumption that
> > > > > >>> the trafic takes the same paths in both
> > > > > >> directions. So, if we
> > > > > >>> want to preserve the Ethernet native OAM (which we
> > > > > >> certainly do
> > > > > >>> , because this is half of Ethernet functionality)
> > > > > >> we must map a
> > > > > >>> bidiretcional service on either a single
> > > > > >> bidirectional LSP or
> > > > > >>> two unidirectional LSPs using the same path. This
> > > > > >> is different
> > > > > >>> form MPLS where there are no such OAM=20
> requirements. Lou is=20
> > > > > >>> talking about asymetrical bi-directional
> > > > > >> LSPs, and what
> > > > > >>> is not clear (at least for me) whether we need
> > > > > >> asymetrical p2p
> > > > > >>> Ethernet services.
> > > > > >>>
> > > > > >>> [at] Adrian's points are related to the single session vs.
> > > > > >>> multiple session discussions we had, which is
> > > > > >> generally true for
> > > > > >>> any bidirectional LSP.
> > > > > >>> The bidirectionality of Ethernet comes basically from two
> > > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > > >> most of the
> > > > > >>> CFM functions will only operate properly if there are
> > > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > > GMPLS LPS is
> > > > > >>> essentially a VLAN within which MAC learning is
> > > > > >> operating one
> > > > > >>> will need symmetric paths in order the learning functions
> > > > > >>> properly.
> > > > > >>>
> > > > > >>> I had the impression that we already converged
> > > > > >> before Prague to
> > > > > >>> a single remaining question: do we need the
> > > > > >>>> asymmetric bw<<
> > > > > >>> extension for a single session bidirectional LSP.
> > > > > There were
> > > > > >>> some possible cases for asymmetric bw LSPs
> > > > > mentioned by Don,
> > > > > >>> Diego and myself but these seemed not to convince
> > everybody.
> > > > > >>> Imho we should focus on this question
> > > > > not to loop
> > > > > >>> into the discussion we had already.
> > > > > >>>
> > > > > >>> If we agree on that bidirectional services over
> > > > > >> Ethernet need
> > > > > >>> symmetrical paths than we could conclude that
> > > > > using a single
> > > > > >>> session to setup the bidirectional LSP would be the
> > > > > >> preferred
> > > > > >>> way at least over Ethernet. In this case, imho it is quite
> > > > > >>> reasonable to assume that asymmetrical services
> > > > > >> that require a
> > > > > >>> dedicated LSP would also use a single signaling
> > > > > exchange to
> > > > > >>> setup the LSP, hence there would be a need for the
> > > > > >> asymmetric bw
> > > > > >>> extension. Following this thinking, the question
> > > > > >> turns into the
> > > > > >>> aggregation/hierarchy discussion that was bought up
> > > > > >> by Dimitri
> > > > > >>> earlier. That is, do we have the need of LSPs per
> > > > > >> service. My
> > > > > >>> two cents: generally not but there are certain
> > > > > >> services where it
> > > > > >>> is indeed a reasonable assumption, e.g., IPTV or private
> > > > > >>> services.
> > > > > >>>
> > > > > >>> These are significant, but not dramatic, requirements.
> > > > > >>>
> > > > > >>> > The question is:
> > > > > >>> >
> > > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > > >>> > (a) a technology specific requirement, or
> > > > > >>> > (b) one that is common (this is CCAMP after
> > > > > >> all!) to multiple
> > > > > >>> switching
> > > > > >>> > technologies?
> > > > > >>>
> > > > > >>> CCAMP deals in transport networks. As far as I can
> > > > > >> see the service
> > > > > >>> requirements would be pretty much the same all transport
> > > > > >>> networks and would certainly be applicable to
> > packet, L2, and
> > > > > >>> TDM (the latter because TDM will be called on to
> > support L2).
> > > > > >>>
> > > > > >>> IB>> See my comment above: there is a differnce
> > > > > >> between MPLS and
> > > > > >>> Ethernet services. Also there are certainly
> > > > > >> differences between
> > > > > >>> MPLS and lambda services (use of the same lambda in both
> > > > > >>> directions, for example). So each transport
> > > > > >> technology may have
> > > > > >>> distinct requirements WRT bidirectional services
> > > > > >> and connections
> > > > > >>> on which the services are mapped.
> > > > > >>>
> > > > > >>> > Please keep in mind that service requirements
> > > > > are not the
> > > > > >>> same thing as
> > > > > >>> > switching technology requirements. For example,
> > > > > >> we have long
> > > > > >>> built
> > > > > >>> > bidirectional asymmetric services on
> > > > > unidirectional MPLS
> > > > > >>> LSPs.
> > > > > >>>
> > > > > >>> Well, exactly!
> > > > > >>> Perhaps someone can explain why the Ethernet
> > > > > >> hardware is forced
> > > > > >>> to require
> > > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > > >>>
> > > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > > >>> Ethernet OAM.
> > > > > >>>
> > > > > >>> Igor
> > > > > >>>
> > > > > >>> > The answer to this question will help determine
> > > > > >> if we should
> > > > > >>> have a
> > > > > >>> > technology specific solution or a generic CCAMP
> > > > > >> solution (as
> > > > > >>> well as the
> > > > > >>> > complexity of the solution.)
> > > > > >>>
> > > > > >>> We should not take any action that deliberately
> > > > > precludes or
> > > > > >>> makes more
> > > > > >>> complex the genericisation (is that an American
> > > > > >> word?) of the
> > > > > >>> solution
> > > > > >>> unless there is a significant difference in simplicity of
> > > > > >>> solutions.
> > > > > >>>
> > > > > >>> But we should take no action at all unless there is
> > > > > >> some more
> > > > > >>> evidence of
> > > > > >>> support for this work!
> > > > > >>>
> > > > > >>> Adrian
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>=20
> > --------------------------------------------------------------
> > > > > >> ----------
> > > > > >>> Ahhh...imagining that irresistible "new car" smell?
> > Check out
> > > > > >>> new cars at Yahoo! Autos.
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > > >>
> > > > >=20
> > >=20
> l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > > WN
> > > > > >>> hcnM->
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >Ahhh...imagining that irresistible "new car" smell?
> > > >Check out=20
> > > ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
> > _cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
> FncwRzbGsDbmV3LWNhcnM->new
> > >cars at Yahoo! Autos.
> >=20
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Fri, 20 Apr 2007 09:51:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Fri, 20 Apr 2007 10:50:53 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Attila,
PONs are a good example of asymmetry at the edge
Alan=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs (IJ/ETH)
Sent: 20 April 2007 10:33
To: Igor Bryskin; Harrison,N,Neil,JCGA1 R; [email-masked]
Cc: [email-masked]; [email-masked]; =
[email-masked]; [email-masked]
Subject: RE: Switching technologies requiring bidirectional asymmetric =
LSPs?

Hi Igor, Neil, and all,

I think it is quite useful to have this discussion on networking modes, =
topology builder services and the relations to GMPLS LSPs.=20

I agree with Neil that the answer is context sensitive.
One can have Ethernet LSPs operating in different modes: co-ps and cl-ps =
irrespective to what these are used for, i.e, being a server layer and =
building a client layer topology, or being at the top of the layers and =
directly supporting services. However, while the former requires co-ps =
mode to operate properly, as pointed out by Neil, the latter can be =
build on co-ps and cl-ps modes primarily depending on the requirements =
of the service. Hence, I think (and I assume this is referred to as =
context sensitive by Neil) asymmetry may be useful for LSPs residing =
higher in the layer stack regardless of co-ps or cl-ps mode of =
operation.=20

Additionally, very much related to the layering/hierarchy, LSPs nearer =
to the edges of the network will likely experience asymmetry imho, =
compared to LSP in the core.

Regards,
Attila

Ps.: well it seems I have just repeated what has been said already, =
sorry!=20

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 10:51 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> Attila Takacs (IJ/ETH); [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional asymmetric =

> LSPs?
>=20
> Neil,
>=20
> Let's assume you've got clean co-ps connections(e.g. Ethernet=20
> connections). My understanding is that you believe that the bandwidth=20
> asymmetricity is useful for p2mp such connections, but not for p2p=20
> connections. Is that correct?
>=20
> Thanks,
> Igor
> =20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 19, 2007 12:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional asymmetric =

> LSPs?
>=20
> Lou Berger asked 19 April 2007 15:05
>=20
> >=20
> >=20
> > Neil,
> >          I agree with Igor, much thanks for your input.
> >=20
> > In reading your response, it's clear that you see a place for=20
> > bidirectional asymmetric-bandwidth *service*.  I think
> there is (and
> > has been) general agreement on this.
> >=20
> > What's not clear to me is if you think there is any requirement for=20
> > bidirectional asymmetric **LSPs**.  Do you have an opinion on this?
> NH=3D> Well, it depends what you mean by an LSP.  As I've tried to =
point=20
> out in the past there are very good scientific reasons why we are=20
> forced to deal with 3 network modes...cl-ps, co-ps and co-cs...and why =

> all technologies map to one of these.  Moreover the modes are=20
> fundamentally different...and you cannot apply the same treatment to=20
> them all.  We've done lots of work in explaining this within SG15=20
> unified modelling based on Information Theory considerations of how=20
> both the labelling AND resource assignment work in space, freq and=20
> time dimensions.  The space and freq dimensions always force a co-cs=20
> mode behaviour.  However, it is how one slices up the time dimension=20
> that generates either the (TDM spin of the) co-cs mode or the co-ps=20
> mode.  Without getting into too much detail, when the time slices are=20
> regular (ie fixed in BOTH start datum AND duration) then labelling=20
> (which is also implicit) and resource assignment are coupled/fixed and =

> the co-cs mode results.  However, when the time slices are irregular=20
> then labelling (which now has to be explicit) and resource assignment=20
> are decoupled the co-ps mode results.
>=20
> The co-cs mode is extremely robust to arch misuse.  For example, one=20
> cannot violate the rules of a connection (ie single source, no=20
> internal routing) in the co-cs mode...and a connection is a crucial=20
> pre-requiste for all manner of things that one oftens wants=20
> determinsism on, like OAM and resource assignment per se for SLAs. The =

> co-cs mode also has other desirable properties (like must have OOB=20
> control/management, no QoS classes, etc) which are highly beneficial=20
> and make networking simple...esp for network builder services (ie=20
> constructing the topology of other layer networks).
>=20
> Now the co-ps is not so robust to arch misuse.  One can create mp2p=20
> merging constructs for example, as we find in MPLS.  These cannot have =

> simple OAM nor can they provide deterministic resource=20
> assignment/management.
>=20
> So, when you says LSPs you have to (i) be clear on the network mode=20
> you are referring to and (ii) if the co-ps mode whether or not the LSP =

> respects the requirements of a connection...as not all LSPs do here. =20
> Aside =3D> One can clearly not construct client layer topoplogy from=20
> mp2p server layer constructs!
>=20
> If I am providing (or indeed procuring) a network builder service (ie=20
> I want to construct the topology of some higher client layer=20
> network....be this a public service network or indeed a private (VPN)=20
> network) then I would want 'LSPs' that respect the requirements of a=20
> connection...because I want to see some strong SLAs associated with=20
> that service.  In the general case these would be based on p2p BW=20
> symmetric constructs.  However, in the case of end-system applications =

> supporting specific services like the ones I referred to in my=20
> response to Igor then the requirement may not indeed be=20
> symmetric....the p2mp *connection* being a case in point for say TV=20
> dist (residential) or financial data distribution (business/private).
>=20
> Not sure if that helps Lou, but its the best I can offer for now.
>=20
> regards, Neil
>=20
> =20
> >=20
> > (if you already stated this, my apologies that I didn't
> understand you
> > ...)
> >=20
> > Thanks,
> > Lou
> >=20
> > At 09:18 AM 4/19/2007, [email-masked] wrote:
> >=20
> > >Thanks Igor....I think the answer is context sensitive. =20
> For example:
> > >
> > >-    are we dealing with a client/server network=20
> > >builder private service?...which may contain a large number of=20
> > >aggregate end-system client application traffic flows
> > >-    are we dealing with a single 'end system to=20
> > >1st layer network adaptation' service?...which may be a public or=20
> > >private service
> > >
> > >In the former case, and increasingly so as one moves towards the=20
> > >duct, there is (of necessity) a lack of detailed information of=20
> > >higher client BW requirements.  So here there is a natural case to=20
> > >want to provide symmetric BW resources....and the atomic building=20
> > >block for such services are p2p constructs.
> > >
> > >However, when we look towards specific end-system services
> there is
> > >more scope for BW resource asymmetry.......a video
> streaming service
> > >would probably be like this.  Further, it may not be
> simply p2p but
> > >p2mp.  I can also imagine some creative thinking wrt to
> using a co-ps
> > >mode with proper p2mp *connections* providing the service in one=20
> > >direction (ie root to leaves) ....because we want some strong=20
> > >resource assignment and SLA guarantees, eg distributing financial=20
> > >information to traders.....but a cl-ps mode return network
> (leaves to
> > >root) providing 'control signals'
> > >(where strong resource assignment may not be so important).  The=20
> > >return direction could however be a set of N p2p connections=20
> > >(probably congruently routed wrt to the other direction) if strong=20
> > >resource assignment and SLAs were also required in the return=20
> > >direction.  The former case here could be considered quite
> novel as
> > >the overall service is using 2 network modes and, by definition, 2=20
> > >different layer networks....so here there is large degree of=20
> > >asymmetry here.
> > >
> > >So, as one moves towards the duct (and in general for
> network builder
> > >services) there is, IMO, a strong requirement for symmetry in all=20
> > >aspects, but as one moves towards the application there are cases=20
> > >where asymmetry is more appropriate.
> > >
> > >regards, Neil
> > >
> > >
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]]
> > >Sent: 19 April 2007 13:36
> > >To: Harrison,N,Neil,JCGA1 R;
> > >[email-masked];
> > >[email-masked]; [email-masked]; [email-masked]
> > >Cc: [email-masked]
> > >Subject: RE: Switching technologies requiring bidirectional
> > asymmetric LSPs?
> > >
> > >Neil,
> > >
> > >I consider your input very important to this discussion.
> > >
> > >My question is: Do you see use cases for bidirectional p2p
> services
> > >which are asymmetrical from the bandwidth reservation
> point of view
> > >(that is, in S=3D>D direction you need bandwidth B1, while in =
D=3D>S=20
> > >direction you need bandwidth B2, and B1 is significantly different=20
> > >from B2), but fully symmetrical in all other aspects (i.e. routes,=20
> > >protection capability, etc.)
> > >
> > >Thanks,
> > >Igor
> > >
> > >[email-masked] wrote:
> > >Thanks Martin,
> > >
> > >Most applications generate asymmetric (wrt time)
> information flows in
> > >each direction, ie the rate of information flow in each
> direction is
> > >neither constant nor directly proportional to the rate of
> information
> > >flow in the other direction....just think about a voice
> conversation
> > >if not obvious....or even a file transfer.
> > >
> > >However, for an arbitrarily meshed network we generally require=20
> > >symmetric routings of traffic flows, ie if one direction
> passes the
> > >nodes
> > >a->b->c->d in one direction then the other
> > >direction should follow d->c->b->a in both this and lower layer=20
> > >networks (to the duct).
> > >Moreover, we usually require (under failure free
> > >conditions) that such routings do not change over the
> lifetime of a
> > >traffic flow.......this is particularly important for
> connections (ie
> > >co-ps and co-cs modes), and especially when they are supporting a=20
> > >network builder service (a VPN if you like), which may be a large=20
> > >aggregate of all kinds of end-system application traffic
> flows, for
> > >some other party. Note that if we add nodes/links to a co
> mode layer
> > >network we should not change existing connection routings. This is=20
> > >not always the case with a cl-ps mode network, ie because
> we do not
> > >have connections adding new nodes/links can allow traffic flows to=20
> > >change routing.
> > >
> > >Is that more clear now wrt what I meant?
> > >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Martin Vigoureux
> [mailto:[email-masked]]
> > > > Sent: 19 April 2007 09:37
> > > > To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> > > > [email-masked]; [email-masked]; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Re: Switching technologies requiring bidirectional=20
> > > > asymmetric LSPs?
> > > >
> > > >
> > > > Neil,
> > > >
> > > > for clarification purposes, the asymmetry I was referring
> > to was in
> > > > terms of bandwidth not path/route or other TE parameter,
> > but maybe I
> > > > did not catch what you meant by *routings*.
> > > >
> > > > regards,
> > > >
> > > > martin
> > > >
> > > > [email-masked] a =E9crit :
> > > > > I would caution against the observation that because
> > traffic flows
> > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > consumed at any
> > > > > epoch) their *routings* can also be asymmetric....this does
> > > > not follow
> > > > > at all. This observation applies to all layer networks (any=20
> > > > > mode/technology).
> > > > >
> > > > > regards, Neil
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: [email-masked]
> > [mailto:[email-masked]]
> > > > >> On Behalf Of Martin Vigoureux
> > > > >> Sent: 19 April 2007 08:34
> > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou=20
> > > > >> Berger
> > > > >> Cc: [email-masked]
> > > > >> Subject: Re: Switching technologies requiring bidirectional=20
> > > > >> asymmetric LSPs?
> > > > >>
> > > > >>
> > > > >> All,
> > > > >>
> > > > >> I do believe in the need for asymmetric bidirectional LSPs.=20
> > > > >> Traffic is by nature asymmetric (for the vast majority
> > of it at
> > > > >> least). We may argue that the sum of asymmetric
> traffic could
> > > > >> lead to symmetric traffic or that the above statement is=20
> > > > >> dependent on the network segment we are considering,
> > but it will
> > > > >> remain true and we should definitely capitalize on
> CCAMP prior
> > > > >> work by taking benefit from the advantages of
> > bidirectional LSP
> > > > >> setup.
> > > > >>
> > > > >> Furthermore, I believe we should not restrict the work and=20
> > > > >> solution to Ethernet technology only.
> > > > >>
> > > > >> martin
> > > > >>
> > > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > > >>> Hi all,
> > > > >>> please see inline [at]
> > > > >>> Regards,
> > > > >>> Attila
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> *From:* [email-masked]
> > > > >> [mailto:[email-masked]]
> > > > >>> *On Behalf Of *Igor Bryskin
> > > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > > > >>> *Subject:* Re: Switching technologies requiring
> bidirectional
> > > > >>> asymmetric LSPs?
> > > > >>>
> > > > >>> Adrian, Lou
> > > > >>>
> > > > >>> Please,see in line.
> > > > >>>
> > > > >>> */Adrian Farrel /* wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> I'm a bit surprised that there was no follow-up to
> > Lou's email.
> > > > >>>
> > > > >>> Does silence indicate that this was put to bed in
> > > > Prague and
> > > > >>> no-one is
> > > > >>> interested in these LSPs?
> > > > >>>
> > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > continue an
> > > > >>> offline discussion on the topic.
> > > > >>>
> > > > >>> > So a few of us have been having been discussing the
> > > > >>> asymmetric work
> > > > >>> > presented in Prague and it seems to me we have an open
> > > > >>> question on
> > > > >>> > requirements.
> > > > >>> >
> > > > >>> > It's clear that at least one switching
> > > > technology (i.e.,
> > > > >>> ethernet/PBB-TE)
> > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > >>>
> > > > >>> Is this clear? I continue to hear talk of service
> > > > >> requirements,
> > > > >>> but not so
> > > > >>> much of how those services are required to be supported.
> > > > >>>
> > > > >>> The benefits I have heard are:
> > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of=20
> > > > >>> fate-sharing
> > > > >>>
> > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > >> bidirectional
> > > > >>> LSPs, and BTW you forgot to mention the most
> > > > important one.
> > > > >>> Ethernet OAM is designed, as I understand, on
> > > > >> assumption that
> > > > >>> the trafic takes the same paths in both
> > > > >> directions. So, if we
> > > > >>> want to preserve the Ethernet native OAM (which we
> > > > >> certainly do
> > > > >>> , because this is half of Ethernet functionality)
> > > > >> we must map a
> > > > >>> bidiretcional service on either a single
> > > > >> bidirectional LSP or
> > > > >>> two unidirectional LSPs using the same path. This
> > > > >> is different
> > > > >>> form MPLS where there are no such OAM requirements.
> > > > >>> Lou is talking about asymetrical bi-directional
> > > > >> LSPs, and what
> > > > >>> is not clear (at least for me) whether we need
> > > > >> asymetrical p2p
> > > > >>> Ethernet services.
> > > > >>>
> > > > >>> [at] Adrian's points are related to the single session vs.=20
> > > > >>> multiple session discussions we had, which is
> > > > >> generally true for
> > > > >>> any bidirectional LSP.
> > > > >>> The bidirectionality of Ethernet comes basically from two=20
> > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > >> most of the
> > > > >>> CFM functions will only operate properly if there are=20
> > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > GMPLS LPS is
> > > > >>> essentially a VLAN within which MAC learning is
> > > > >> operating one
> > > > >>> will need symmetric paths in order the learning functions=20
> > > > >>> properly.
> > > > >>>
> > > > >>> I had the impression that we already converged
> > > > >> before Prague to
> > > > >>> a single remaining question: do we need the
> > > > >>>> asymmetric bw<<
> > > > >>> extension for a single session bidirectional LSP.
> > > > There were
> > > > >>> some possible cases for asymmetric bw LSPs
> > > > mentioned by Don,
> > > > >>> Diego and myself but these seemed not to convince
> everybody.=20
> > > > >>> Imho we should focus on this question
> > > > not to loop
> > > > >>> into the discussion we had already.
> > > > >>>
> > > > >>> If we agree on that bidirectional services over
> > > > >> Ethernet need
> > > > >>> symmetrical paths than we could conclude that
> > > > using a single
> > > > >>> session to setup the bidirectional LSP would be the
> > > > >> preferred
> > > > >>> way at least over Ethernet. In this case, imho it is quite=20
> > > > >>> reasonable to assume that asymmetrical services
> > > > >> that require a
> > > > >>> dedicated LSP would also use a single signaling
> > > > exchange to
> > > > >>> setup the LSP, hence there would be a need for the
> > > > >> asymmetric bw
> > > > >>> extension. Following this thinking, the question
> > > > >> turns into the
> > > > >>> aggregation/hierarchy discussion that was bought up
> > > > >> by Dimitri
> > > > >>> earlier. That is, do we have the need of LSPs per
> > > > >> service. My
> > > > >>> two cents: generally not but there are certain
> > > > >> services where it
> > > > >>> is indeed a reasonable assumption, e.g., IPTV or private=20
> > > > >>> services.
> > > > >>>
> > > > >>> These are significant, but not dramatic, requirements.
> > > > >>>
> > > > >>> > The question is:
> > > > >>> >
> > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > >>> > (a) a technology specific requirement, or
> > > > >>> > (b) one that is common (this is CCAMP after
> > > > >> all!) to multiple
> > > > >>> switching
> > > > >>> > technologies?
> > > > >>>
> > > > >>> CCAMP deals in transport networks. As far as I can
> > > > >> see the service
> > > > >>> requirements would be pretty much the same all transport=20
> > > > >>> networks and would certainly be applicable to
> packet, L2, and
> > > > >>> TDM (the latter because TDM will be called on to
> support L2).
> > > > >>>
> > > > >>> IB>> See my comment above: there is a differnce
> > > > >> between MPLS and
> > > > >>> Ethernet services. Also there are certainly
> > > > >> differences between
> > > > >>> MPLS and lambda services (use of the same lambda in both=20
> > > > >>> directions, for example). So each transport
> > > > >> technology may have
> > > > >>> distinct requirements WRT bidirectional services
> > > > >> and connections
> > > > >>> on which the services are mapped.
> > > > >>>
> > > > >>> > Please keep in mind that service requirements
> > > > are not the
> > > > >>> same thing as
> > > > >>> > switching technology requirements. For example,
> > > > >> we have long
> > > > >>> built
> > > > >>> > bidirectional asymmetric services on
> > > > unidirectional MPLS
> > > > >>> LSPs.
> > > > >>>
> > > > >>> Well, exactly!
> > > > >>> Perhaps someone can explain why the Ethernet
> > > > >> hardware is forced
> > > > >>> to require
> > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > >>>
> > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > >>> Ethernet OAM.
> > > > >>>
> > > > >>> Igor
> > > > >>>
> > > > >>> > The answer to this question will help determine
> > > > >> if we should
> > > > >>> have a
> > > > >>> > technology specific solution or a generic CCAMP
> > > > >> solution (as
> > > > >>> well as the
> > > > >>> > complexity of the solution.)
> > > > >>>
> > > > >>> We should not take any action that deliberately
> > > > precludes or
> > > > >>> makes more
> > > > >>> complex the genericisation (is that an American
> > > > >> word?) of the
> > > > >>> solution
> > > > >>> unless there is a significant difference in simplicity of=20
> > > > >>> solutions.
> > > > >>>
> > > > >>> But we should take no action at all unless there is
> > > > >> some more
> > > > >>> evidence of
> > > > >>> support for this work!
> > > > >>>
> > > > >>> Adrian
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> Ahhh...imagining that irresistible "new car" smell?=20
> Check out
> > > > >>> new cars at Yahoo! Autos.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > >>
> > > >=20
> > =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > WN
> > > > >>> hcnM->
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > >Ahhh...imagining that irresistible "new car" smell?
> > >Check out
> > ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
> _cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
FncwRzbGsDbmV3LWNhcnM->new
> >cars at Yahoo! Autos.
>=20
>=20
>=20
>=20

Delivery-date: Fri, 20 Apr 2007 09:36:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Fri, 20 Apr 2007 11:32:58 +0200
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Igor, Neil, and all,

I think it is quite useful to have this discussion on networking modes, =
topology builder services and the relations to GMPLS LSPs.=20

I agree with Neil that the answer is context sensitive.
One can have Ethernet LSPs operating in different modes: co-ps and cl-ps =
irrespective to what these are used for, i.e, being a server layer and =
building a client layer topology, or being at the top of the layers and =
directly supporting services. However, while the former requires co-ps =
mode to operate properly, as pointed out by Neil, the latter can be =
build on co-ps and cl-ps modes primarily depending on the requirements =
of the service. Hence, I think (and I assume this is referred to as =
context sensitive by Neil) asymmetry may be useful for LSPs residing =
higher in the layer stack regardless of co-ps or cl-ps mode of =
operation.=20

Additionally, very much related to the layering/hierarchy, LSPs nearer =
to the edges of the network will likely experience asymmetry imho, =
compared to LSP in the core.

Regards,
Attila

Ps.: well it seems I have just repeated what has been said already, =
sorry!=20

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]=20
> Sent: Thursday, April 19, 2007 10:51 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];=20
> Attila Takacs (IJ/ETH); [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
> Neil,
>=20
> Let's assume you've got clean co-ps connections(e.g. Ethernet=20
> connections). My understanding is that you believe that the=20
> bandwidth asymmetricity is useful for p2mp such connections,=20
> but not for p2p connections. Is that correct?
>=20
> Thanks,
> Igor
> =20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 19, 2007 12:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
> Lou Berger asked 19 April 2007 15:05
>=20
> >=20
> >=20
> > Neil,
> >          I agree with Igor, much thanks for your input.
> >=20
> > In reading your response, it's clear that you see a place for=20
> > bidirectional asymmetric-bandwidth *service*.  I think=20
> there is (and=20
> > has been) general agreement on this.
> >=20
> > What's not clear to me is if you think there is any requirement for=20
> > bidirectional asymmetric **LSPs**.  Do you have an opinion on this?
> NH=3D> Well, it depends what you mean by an LSP.  As I've tried=20
> to point out in the past there are very good scientific=20
> reasons why we are forced to deal with 3 network=20
> modes...cl-ps, co-ps and co-cs...and why all technologies map=20
> to one of these.  Moreover the modes are fundamentally=20
> different...and you cannot apply the same treatment to them=20
> all.  We've done lots of work in explaining this within SG15=20
> unified modelling based on Information Theory considerations=20
> of how both the labelling AND resource assignment work in=20
> space, freq and time dimensions.  The space and freq=20
> dimensions always force a co-cs mode behaviour.  However, it=20
> is how one slices up the time dimension that generates either=20
> the (TDM spin of the) co-cs mode or the co-ps mode.  Without=20
> getting into too much detail, when the time slices are=20
> regular (ie fixed in BOTH start datum AND duration) then=20
> labelling (which is also implicit) and resource assignment=20
> are coupled/fixed and the co-cs mode results.  However, when=20
> the time slices are irregular then labelling (which now has=20
> to be explicit) and resource assignment are decoupled the=20
> co-ps mode results.
>=20
> The co-cs mode is extremely robust to arch misuse.  For=20
> example, one cannot violate the rules of a connection (ie=20
> single source, no internal routing) in the co-cs mode...and a=20
> connection is a crucial pre-requiste for all manner of things=20
> that one oftens wants determinsism on, like OAM and resource=20
> assignment per se for SLAs. The co-cs mode also has other=20
> desirable properties (like must have OOB control/management,=20
> no QoS classes, etc) which are highly beneficial and make=20
> networking simple...esp for network builder services (ie=20
> constructing the topology of other layer networks).
>=20
> Now the co-ps is not so robust to arch misuse.  One can=20
> create mp2p merging constructs for example, as we find in=20
> MPLS.  These cannot have simple OAM nor can they provide=20
> deterministic resource assignment/management.
>=20
> So, when you says LSPs you have to (i) be clear on the=20
> network mode you are referring to and (ii) if the co-ps mode=20
> whether or not the LSP respects the requirements of a=20
> connection...as not all LSPs do here.  Aside =3D> One can=20
> clearly not construct client layer topoplogy from mp2p server=20
> layer constructs!
>=20
> If I am providing (or indeed procuring) a network builder=20
> service (ie I want to construct the topology of some higher=20
> client layer network....be this a public service network or=20
> indeed a private (VPN) network) then I would want 'LSPs' that=20
> respect the requirements of a connection...because I want to=20
> see some strong SLAs associated with that service.  In the=20
> general case these would be based on p2p BW symmetric=20
> constructs.  However, in the case of end-system applications=20
> supporting specific services like the ones I referred to in=20
> my response to Igor then the requirement may not indeed be=20
> symmetric....the p2mp *connection* being a case in point for=20
> say TV dist (residential) or financial data distribution=20
> (business/private).
>=20
> Not sure if that helps Lou, but its the best I can offer for now.
>=20
> regards, Neil
>=20
> =20
> >=20
> > (if you already stated this, my apologies that I didn't=20
> understand you=20
> > ...)
> >=20
> > Thanks,
> > Lou
> >=20
> > At 09:18 AM 4/19/2007, [email-masked] wrote:
> >=20
> > >Thanks Igor....I think the answer is context sensitive. =20
> For example:
> > >
> > >-    are we dealing with a client/server network=20
> > >builder private service?...which may contain a large number of=20
> > >aggregate end-system client application traffic flows
> > >-    are we dealing with a single 'end system to=20
> > >1st layer network adaptation' service?...which may be a public or=20
> > >private service
> > >
> > >In the former case, and increasingly so as one moves towards the=20
> > >duct, there is (of necessity) a lack of detailed information of=20
> > >higher client BW requirements.  So here there is a natural case to=20
> > >want to provide symmetric BW resources....and the atomic building=20
> > >block for such services are p2p constructs.
> > >
> > >However, when we look towards specific end-system services=20
> there is=20
> > >more scope for BW resource asymmetry.......a video=20
> streaming service=20
> > >would probably be like this.  Further, it may not be=20
> simply p2p but=20
> > >p2mp.  I can also imagine some creative thinking wrt to=20
> using a co-ps=20
> > >mode with proper p2mp *connections* providing the service in one=20
> > >direction (ie root to leaves) ....because we want some strong=20
> > >resource assignment and SLA guarantees, eg distributing financial=20
> > >information to traders.....but a cl-ps mode return network=20
> (leaves to=20
> > >root) providing 'control signals'
> > >(where strong resource assignment may not be so important).  The=20
> > >return direction could however be a set of N p2p connections=20
> > >(probably congruently routed wrt to the other direction) if strong=20
> > >resource assignment and SLAs were also required in the return=20
> > >direction.  The former case here could be considered quite=20
> novel as=20
> > >the overall service is using 2 network modes and, by definition, 2=20
> > >different layer networks....so here there is large degree of=20
> > >asymmetry here.
> > >
> > >So, as one moves towards the duct (and in general for=20
> network builder=20
> > >services) there is, IMO, a strong requirement for symmetry in all=20
> > >aspects, but as one moves towards the application there are cases=20
> > >where asymmetry is more appropriate.
> > >
> > >regards, Neil
> > >
> > >
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]]
> > >Sent: 19 April 2007 13:36
> > >To: Harrison,N,Neil,JCGA1 R;
> > >[email-masked];
> > >[email-masked]; [email-masked]; [email-masked]
> > >Cc: [email-masked]
> > >Subject: RE: Switching technologies requiring bidirectional
> > asymmetric LSPs?
> > >
> > >Neil,
> > >
> > >I consider your input very important to this discussion.
> > >
> > >My question is: Do you see use cases for bidirectional p2p=20
> services=20
> > >which are asymmetrical from the bandwidth reservation=20
> point of view=20
> > >(that is, in S=3D>D direction you need bandwidth B1, while in =
D=3D>S=20
> > >direction you need bandwidth B2, and B1 is significantly different=20
> > >from B2), but fully symmetrical in all other aspects (i.e. routes,=20
> > >protection capability, etc.)
> > >
> > >Thanks,
> > >Igor
> > >
> > >[email-masked] wrote:
> > >Thanks Martin,
> > >
> > >Most applications generate asymmetric (wrt time)=20
> information flows in=20
> > >each direction, ie the rate of information flow in each=20
> direction is=20
> > >neither constant nor directly proportional to the rate of=20
> information=20
> > >flow in the other direction....just think about a voice=20
> conversation=20
> > >if not obvious....or even a file transfer.
> > >
> > >However, for an arbitrarily meshed network we generally require=20
> > >symmetric routings of traffic flows, ie if one direction=20
> passes the=20
> > >nodes
> > >a->b->c->d in one direction then the other
> > >direction should follow d->c->b->a in both this and lower layer=20
> > >networks (to the duct).
> > >Moreover, we usually require (under failure free
> > >conditions) that such routings do not change over the=20
> lifetime of a=20
> > >traffic flow.......this is particularly important for=20
> connections (ie=20
> > >co-ps and co-cs modes), and especially when they are supporting a=20
> > >network builder service (a VPN if you like), which may be a large=20
> > >aggregate of all kinds of end-system application traffic=20
> flows, for=20
> > >some other party. Note that if we add nodes/links to a co=20
> mode layer=20
> > >network we should not change existing connection routings. This is=20
> > >not always the case with a cl-ps mode network, ie because=20
> we do not=20
> > >have connections adding new nodes/links can allow traffic flows to=20
> > >change routing.
> > >
> > >Is that more clear now wrt what I meant?
> > >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Martin Vigoureux=20
> [mailto:[email-masked]]
> > > > Sent: 19 April 2007 09:37
> > > > To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> > > > [email-masked]; [email-masked]; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Re: Switching technologies requiring bidirectional=20
> > > > asymmetric LSPs?
> > > >
> > > >
> > > > Neil,
> > > >
> > > > for clarification purposes, the asymmetry I was referring
> > to was in
> > > > terms of bandwidth not path/route or other TE parameter,
> > but maybe I
> > > > did not catch what you meant by *routings*.
> > > >
> > > > regards,
> > > >
> > > > martin
> > > >
> > > > [email-masked] a =E9crit :
> > > > > I would caution against the observation that because
> > traffic flows
> > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > consumed at any
> > > > > epoch) their *routings* can also be asymmetric....this does
> > > > not follow
> > > > > at all. This observation applies to all layer networks (any=20
> > > > > mode/technology).
> > > > >
> > > > > regards, Neil
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: [email-masked]
> > [mailto:[email-masked]]
> > > > >> On Behalf Of Martin Vigoureux
> > > > >> Sent: 19 April 2007 08:34
> > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou=20
> > > > >> Berger
> > > > >> Cc: [email-masked]
> > > > >> Subject: Re: Switching technologies requiring bidirectional=20
> > > > >> asymmetric LSPs?
> > > > >>
> > > > >>
> > > > >> All,
> > > > >>
> > > > >> I do believe in the need for asymmetric bidirectional LSPs.=20
> > > > >> Traffic is by nature asymmetric (for the vast majority
> > of it at
> > > > >> least). We may argue that the sum of asymmetric=20
> traffic could=20
> > > > >> lead to symmetric traffic or that the above statement is=20
> > > > >> dependent on the network segment we are considering,
> > but it will
> > > > >> remain true and we should definitely capitalize on=20
> CCAMP prior=20
> > > > >> work by taking benefit from the advantages of
> > bidirectional LSP
> > > > >> setup.
> > > > >>
> > > > >> Furthermore, I believe we should not restrict the work and=20
> > > > >> solution to Ethernet technology only.
> > > > >>
> > > > >> martin
> > > > >>
> > > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > > >>> Hi all,
> > > > >>> please see inline [at]
> > > > >>> Regards,
> > > > >>> Attila
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> *From:* [email-masked]
> > > > >> [mailto:[email-masked]]
> > > > >>> *On Behalf Of *Igor Bryskin
> > > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > > > >>> *Subject:* Re: Switching technologies requiring=20
> bidirectional=20
> > > > >>> asymmetric LSPs?
> > > > >>>
> > > > >>> Adrian, Lou
> > > > >>>
> > > > >>> Please,see in line.
> > > > >>>
> > > > >>> */Adrian Farrel /* wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> I'm a bit surprised that there was no follow-up to
> > Lou's email.
> > > > >>>
> > > > >>> Does silence indicate that this was put to bed in
> > > > Prague and
> > > > >>> no-one is
> > > > >>> interested in these LSPs?
> > > > >>>
> > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > continue an
> > > > >>> offline discussion on the topic.
> > > > >>>
> > > > >>> > So a few of us have been having been discussing the
> > > > >>> asymmetric work
> > > > >>> > presented in Prague and it seems to me we have an open
> > > > >>> question on
> > > > >>> > requirements.
> > > > >>> >
> > > > >>> > It's clear that at least one switching
> > > > technology (i.e.,
> > > > >>> ethernet/PBB-TE)
> > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > >>>
> > > > >>> Is this clear? I continue to hear talk of service
> > > > >> requirements,
> > > > >>> but not so
> > > > >>> much of how those services are required to be supported.
> > > > >>>
> > > > >>> The benefits I have heard are:
> > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of=20
> > > > >>> fate-sharing
> > > > >>>
> > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > >> bidirectional
> > > > >>> LSPs, and BTW you forgot to mention the most
> > > > important one.
> > > > >>> Ethernet OAM is designed, as I understand, on
> > > > >> assumption that
> > > > >>> the trafic takes the same paths in both
> > > > >> directions. So, if we
> > > > >>> want to preserve the Ethernet native OAM (which we
> > > > >> certainly do
> > > > >>> , because this is half of Ethernet functionality)
> > > > >> we must map a
> > > > >>> bidiretcional service on either a single
> > > > >> bidirectional LSP or
> > > > >>> two unidirectional LSPs using the same path. This
> > > > >> is different
> > > > >>> form MPLS where there are no such OAM requirements.
> > > > >>> Lou is talking about asymetrical bi-directional
> > > > >> LSPs, and what
> > > > >>> is not clear (at least for me) whether we need
> > > > >> asymetrical p2p
> > > > >>> Ethernet services.
> > > > >>>
> > > > >>> [at] Adrian's points are related to the single session vs.=20
> > > > >>> multiple session discussions we had, which is
> > > > >> generally true for
> > > > >>> any bidirectional LSP.
> > > > >>> The bidirectionality of Ethernet comes basically from two=20
> > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > >> most of the
> > > > >>> CFM functions will only operate properly if there are=20
> > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > GMPLS LPS is
> > > > >>> essentially a VLAN within which MAC learning is
> > > > >> operating one
> > > > >>> will need symmetric paths in order the learning functions=20
> > > > >>> properly.
> > > > >>>
> > > > >>> I had the impression that we already converged
> > > > >> before Prague to
> > > > >>> a single remaining question: do we need the
> > > > >>>> asymmetric bw<<
> > > > >>> extension for a single session bidirectional LSP.
> > > > There were
> > > > >>> some possible cases for asymmetric bw LSPs
> > > > mentioned by Don,
> > > > >>> Diego and myself but these seemed not to convince=20
> everybody.=20
> > > > >>> Imho we should focus on this question
> > > > not to loop
> > > > >>> into the discussion we had already.
> > > > >>>
> > > > >>> If we agree on that bidirectional services over
> > > > >> Ethernet need
> > > > >>> symmetrical paths than we could conclude that
> > > > using a single
> > > > >>> session to setup the bidirectional LSP would be the
> > > > >> preferred
> > > > >>> way at least over Ethernet. In this case, imho it is quite=20
> > > > >>> reasonable to assume that asymmetrical services
> > > > >> that require a
> > > > >>> dedicated LSP would also use a single signaling
> > > > exchange to
> > > > >>> setup the LSP, hence there would be a need for the
> > > > >> asymmetric bw
> > > > >>> extension. Following this thinking, the question
> > > > >> turns into the
> > > > >>> aggregation/hierarchy discussion that was bought up
> > > > >> by Dimitri
> > > > >>> earlier. That is, do we have the need of LSPs per
> > > > >> service. My
> > > > >>> two cents: generally not but there are certain
> > > > >> services where it
> > > > >>> is indeed a reasonable assumption, e.g., IPTV or private=20
> > > > >>> services.
> > > > >>>
> > > > >>> These are significant, but not dramatic, requirements.
> > > > >>>
> > > > >>> > The question is:
> > > > >>> >
> > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > >>> > (a) a technology specific requirement, or
> > > > >>> > (b) one that is common (this is CCAMP after
> > > > >> all!) to multiple
> > > > >>> switching
> > > > >>> > technologies?
> > > > >>>
> > > > >>> CCAMP deals in transport networks. As far as I can
> > > > >> see the service
> > > > >>> requirements would be pretty much the same all transport=20
> > > > >>> networks and would certainly be applicable to=20
> packet, L2, and=20
> > > > >>> TDM (the latter because TDM will be called on to=20
> support L2).
> > > > >>>
> > > > >>> IB>> See my comment above: there is a differnce
> > > > >> between MPLS and
> > > > >>> Ethernet services. Also there are certainly
> > > > >> differences between
> > > > >>> MPLS and lambda services (use of the same lambda in both=20
> > > > >>> directions, for example). So each transport
> > > > >> technology may have
> > > > >>> distinct requirements WRT bidirectional services
> > > > >> and connections
> > > > >>> on which the services are mapped.
> > > > >>>
> > > > >>> > Please keep in mind that service requirements
> > > > are not the
> > > > >>> same thing as
> > > > >>> > switching technology requirements. For example,
> > > > >> we have long
> > > > >>> built
> > > > >>> > bidirectional asymmetric services on
> > > > unidirectional MPLS
> > > > >>> LSPs.
> > > > >>>
> > > > >>> Well, exactly!
> > > > >>> Perhaps someone can explain why the Ethernet
> > > > >> hardware is forced
> > > > >>> to require
> > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > >>>
> > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > >>> Ethernet OAM.
> > > > >>>
> > > > >>> Igor
> > > > >>>
> > > > >>> > The answer to this question will help determine
> > > > >> if we should
> > > > >>> have a
> > > > >>> > technology specific solution or a generic CCAMP
> > > > >> solution (as
> > > > >>> well as the
> > > > >>> > complexity of the solution.)
> > > > >>>
> > > > >>> We should not take any action that deliberately
> > > > precludes or
> > > > >>> makes more
> > > > >>> complex the genericisation (is that an American
> > > > >> word?) of the
> > > > >>> solution
> > > > >>> unless there is a significant difference in simplicity of=20
> > > > >>> solutions.
> > > > >>>
> > > > >>> But we should take no action at all unless there is
> > > > >> some more
> > > > >>> evidence of
> > > > >>> support for this work!
> > > > >>>
> > > > >>> Adrian
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> Ahhh...imagining that irresistible "new car" smell?=20
> Check out=20
> > > > >>> new cars at Yahoo! Autos.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > >>
> > > >=20
> > =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > WN
> > > > >>> hcnM->
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > >Ahhh...imagining that irresistible "new car" smell?
> > >Check out
> > ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
> _cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
FncwRzbGsDbmV3LWNhcnM->new=20
> >cars at Yahoo! Autos.
>=20
>=20
>=20
>=20

Delivery-date: Fri, 20 Apr 2007 01:49:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric   LSPs?
Date: Fri, 20 Apr 2007 02:45:26 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Lou,

who wrote 20 April 2007 00:38

>=20
> At 12:27 PM 4/19/2007, [email-masked] wrote:
> >[...]
> >So, when you says LSPs you have to (i) be clear on the network mode=20
> >you are referring to and (ii) if the co-ps mode whether or not the=20
> >LSP respects the requirements of a connection...as not all
> LSPs do here.
> >[...]
>=20
> Neil,
>          As you know LSP is a technology independent term used in
> MPLS and GMPLS.
NH=3D> Yes I know.  But GMPLS !=3D MPLS as the network mode is a =
critical
parameter and places constraints on behaviour.  However, this is not to
say there is plenty of scope for functional component re-use (quite the
contrary in fact)....but I do fundamentally object to the notion that
one can have the *same* instance of functional component (any, but
routing is the most obvious one) running IP to Optics.  This just won't
work for a whole raft of reasons (technical, commercial and regulatory).

>  The original question (requirement for bidirectional=20
> asymmetric-bandwidth *TE* LSPs) was intended to identify which=20
> network modes the WG considered important.  The motivation for the=20
> question was the discussions on  bidirectional asymmetric-bandwidth=20
> TE LSPs for co-ps, specifically Ethernet/PBB-TE, see=20
> draft-takacs-asym-bw-lsp.  Some have asked if we should define a=20
> mechanisms that supports other co-ps and co-cs technologies.  Others=20
> have said that we should not define mechanisms for any technology.
>=20
> Does this help clarify the question?
NH=3D> Yes it does.....and I have raised this internally for discussion =
as
I thought your initial question to the list deserved some answer...still
awaiting colleagues comments.  I will look at Attila's draft as soon as
I get time and see what additional comments I can provide.  But in
general, and as I have already observed, if we are using layer N to
create the topology of a higher layer network then p2p symmetric
constructs are the natural building block...however, if we are at the
top of the network stack and directly supporting some external
application/service, then there is more scope for asymmetry.
>=20
> Lou
>=20
> PS
>=20
> >Aside =3D> One can clearly not construct client layer topoplogy from
> >mp2p server layer constructs!
>=20
> and I'd claim that the current definition of mp2p is cl-ps...
NH=3D> And I'd agree with you, though I would observe that a cl-ps =
traffic
unit MUST have network significant DA/SA labels....this is not forced in
the co-ps mode.  Moreover, there is more to networking than simply
labelling considerations, and the partitioning of resource is
fundamental to many important operational and service related
behaviours/requirements.  One can gain some important insights and
benefits form a better understanding of how labelling and resource
partitioning work and generate the 3 network modes.  PBB-TE, that you
mention in a prior paragraph, was indeed a spin-off from our unified
modelling work.

regards, Neil
>=20
>=20
>=20

Delivery-date: Fri, 20 Apr 2007 01:49:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Fri, 20 Apr 2007 02:47:22 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Igor,

Essentially yes.  But I would qualify this by context.  The closer one =
gets to the duct the more important it is for p2p constructs to be the =
atomic building block.....and more generally this is true for a server =
layer which is used to create the topology of some client layer network. =
 Remember:  A link connection at layer N is formed by a trail (end-end =
network connection) at layer N-1.  Those who are not familiar with func =
arch stuff should try and read my colleague Andy Reid's text book =
'Broadband Networking' chapters 3 and 4 as this gives a good intro to =
func arch concepts.  And ideally should also try and look at the more =
recent work we are doing on unified modelling of networks as we have now =
sorted out the principles as to why the 3 network modes must exist (I =
have just written a paper on this which I will probably be publishing =
later this year in the BT Technology Journal).

One can, in principle, create higher layer topology using p2mp =
constructs (but not any others, like mp2p or mp2mp) but a 'broadcast at =
source filter at sink' networking model is not generally an =
efficient/practical one for topology creation purposes.

When we get to the top of a network stack (ie a layer network directly =
supporting external applications/services) then this is where one can =
more usefully apply asymmetry.

regards, Neil

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]
> Sent: 19 April 2007 21:51
> To: Harrison,N,Neil,JCGA1 R; [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
>=20
> Neil,
>=20
> Let's assume you've got clean co-ps connections(e.g. Ethernet
> connections). My understanding is that you believe that the=20
> bandwidth asymmetricity is useful for p2mp such connections,=20
> but not for p2p connections. Is that correct?
>=20
> Thanks,
> Igor
> =20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 19, 2007 12:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
> Lou Berger asked 19 April 2007 15:05
>=20
> >=20
> >=20
> > Neil,
> >          I agree with Igor, much thanks for your input.
> >=20
> > In reading your response, it's clear that you see
> > a place for bidirectional asymmetric-bandwidth
> > *service*.  I think there is (and has been) general=20
> agreement on this.
> >=20
> > What's not clear to me is if you think there is
> > any requirement for bidirectional asymmetric
> > **LSPs**.  Do you have an opinion on this?
> NH=3D> Well, it depends what you mean by an LSP.  As I've tried
> to point out in the past there are very good scientific=20
> reasons why we are forced to deal with 3 network=20
> modes...cl-ps, co-ps and co-cs...and why all technologies map=20
> to one of these.  Moreover the modes are fundamentally=20
> different...and you cannot apply the same treatment to them=20
> all.  We've done lots of work in explaining this within SG15=20
> unified modelling based on Information Theory considerations=20
> of how both the labelling AND resource assignment work in=20
> space, freq and time dimensions.  The space and freq=20
> dimensions always force a co-cs mode behaviour.  However, it=20
> is how one slices up the time dimension that generates either=20
> the (TDM spin of the) co-cs mode or the co-ps mode.  Without=20
> getting into too much detail, when the time slices are=20
> regular (ie fixed in BOTH start datum AND duration) then=20
> labelling (which is also implicit) and resource assignment=20
> are coupled/fixed and the co-cs mode results.  However, when=20
> the time slices are irregular then labelling (which now has=20
> to be explicit) and resource assignment are decoupled the=20
> co-ps mode results.
>=20
> The co-cs mode is extremely robust to arch misuse.  For
> example, one cannot violate the rules of a connection (ie=20
> single source, no internal routing) in the co-cs mode...and a=20
> connection is a crucial pre-requiste for all manner of things=20
> that one oftens wants determinsism on, like OAM and resource=20
> assignment per se for SLAs. The co-cs mode also has other=20
> desirable properties (like must have OOB control/management,=20
> no QoS classes, etc) which are highly beneficial and make=20
> networking simple...esp for network builder services (ie=20
> constructing the topology of other layer networks).
>=20
> Now the co-ps is not so robust to arch misuse.  One can
> create mp2p merging constructs for example, as we find in=20
> MPLS.  These cannot have simple OAM nor can they provide=20
> deterministic resource assignment/management.
>=20
> So, when you says LSPs you have to (i) be clear on the
> network mode you are referring to and (ii) if the co-ps mode=20
> whether or not the LSP respects the requirements of a=20
> connection...as not all LSPs do here.  Aside =3D> One can=20
> clearly not construct client layer topoplogy from mp2p server=20
> layer constructs!
>=20
> If I am providing (or indeed procuring) a network builder
> service (ie I want to construct the topology of some higher=20
> client layer network....be this a public service network or=20
> indeed a private (VPN) network) then I would want 'LSPs' that=20
> respect the requirements of a connection...because I want to=20
> see some strong SLAs associated with that service.  In the=20
> general case these would be based on p2p BW symmetric=20
> constructs.  However, in the case of end-system applications=20
> supporting specific services like the ones I referred to in=20
> my response to Igor then the requirement may not indeed be=20
> symmetric....the p2mp *connection* being a case in point for=20
> say TV dist (residential) or financial data distribution=20
> (business/private).
>=20
> Not sure if that helps Lou, but its the best I can offer for now.
>=20
> regards, Neil
>=20
> =20
> >=20
> > (if you already stated this, my apologies that I didn't
> > understand you ...)
> >=20
> > Thanks,
> > Lou
> >=20
> > At 09:18 AM 4/19/2007, [email-masked] wrote:
> >=20
> > >Thanks Igor....I think the answer is context sensitive.
> For example:
> > >
> > >-    are we dealing with a client/server network=20
> > >builder private service?...which may contain a
> > >large number of aggregate end-system client application
> traffic flows
> > >-    are we dealing with a single 'end system to=20
> > >1st layer network adaptation' service?...which
> > >may be a public or private service
> > >
> > >In the former case, and increasingly so as one
> > >moves towards the duct, there is (of necessity)
> > >a lack of detailed information of higher client=20
> > >BW requirements.  So here there is a natural=20
> > >case to want to provide symmetric BW=20
> > >resources....and the atomic building block for=20
> > >such services are p2p constructs.
> > >
> > >However, when we look towards specific
> > >end-system services there is more scope for BW
> > >resource asymmetry.......a video streaming=20
> > >service would probably be like this.  Further,=20
> > >it may not be simply p2p but p2mp.  I can also=20
> > >imagine some creative thinking wrt to using a=20
> > >co-ps mode with proper p2mp *connections*=20
> > >providing the service in one direction (ie root=20
> > >to leaves) ....because we want some strong=20
> > >resource assignment and SLA guarantees, eg=20
> > >distributing financial information to=20
> > >traders.....but a cl-ps mode return network=20
> > >(leaves to root) providing 'control signals'=20
> > >(where strong resource assignment may not be so=20
> > >important).  The return direction could however=20
> > >be a set of N p2p connections (probably=20
> > >congruently routed wrt to the other direction)=20
> > >if strong resource assignment and SLAs were also=20
> > >required in the return direction.  The former=20
> > >case here could be considered quite novel as the=20
> > >overall service is using 2 network modes and, by=20
> > >definition, 2 different layer networks....so=20
> > >here there is large degree of asymmetry here.
> > >
> > >So, as one moves towards the duct (and in
> > >general for network builder services) there is,
> > >IMO, a strong requirement for symmetry in all=20
> > >aspects, but as one moves towards the=20
> > >application there are cases where asymmetry is more appropriate.
> > >
> > >regards, Neil
> > >
> > >
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]]
> > >Sent: 19 April 2007 13:36
> > >To: Harrison,N,Neil,JCGA1 R; [email-masked];
> > >[email-masked]; [email-masked]; [email-masked]
> > >Cc: [email-masked]
> > >Subject: RE: Switching technologies requiring bidirectional=20
> > asymmetric LSPs?
> > >
> > >Neil,
> > >
> > >I consider your input very important to this discussion.
> > >
> > >My question is: Do you see use cases for
> > >bidirectional p2p services which are=20
> > >asymmetrical from the bandwidth reservation=20
> > >point of view (that is, in S=3D>D direction you=20
> > >need bandwidth B1, while in D=3D>S direction you=20
> > >need bandwidth B2, and B1 is significantly=20
> > >different from B2), but fully symmetrical in all=20
> > >other aspects (i.e. routes, protection capability, etc.)
> > >
> > >Thanks,
> > >Igor
> > >
> > >[email-masked] wrote:
> > >Thanks Martin,
> > >
> > >Most applications generate asymmetric (wrt time)
> > >information flows in each direction, ie the rate=20
> > >of information flow in each direction is neither=20
> > >constant nor directly proportional to the rate=20
> > >of information flow in the other=20
> > >direction....just think about a voice=20
> > >conversation if not obvious....or even a file transfer.
> > >
> > >However, for an arbitrarily meshed network we
> > >generally require symmetric routings of traffic=20
> > >flows, ie if one direction passes the nodes=20
> > >a->b->c->d in one direction then the other
> > >direction should follow d->c->b->a in both this
> > >and lower layer networks (to the duct).=20
> > >Moreover, we usually require (under failure free=20
> > >conditions) that such routings do not change=20
> > >over the lifetime of a traffic flow.......this=20
> > >is particularly important for connections (ie=20
> > >co-ps and co-cs modes), and especially when they=20
> > >are supporting a network builder service (a VPN=20
> > >if you like), which may be a large aggregate of=20
> > >all kinds of end-system application traffic=20
> > >flows, for some other party. Note that if we add=20
> > >nodes/links to a co mode layer network we should=20
> > >not change existing connection routings. This is=20
> > >not always the case with a cl-ps mode network,=20
> > >ie because we do not have connections adding new=20
> > >nodes/links can allow traffic flows to change routing.
> > >
> > >Is that more clear now wrt what I meant?
> > >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Martin Vigoureux=20
> [mailto:[email-masked]]
> > > > Sent: 19 April 2007 09:37
> > > > To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> > > > [email-masked]; [email-masked]; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Re: Switching technologies requiring bidirectional=20
> > > > asymmetric LSPs?
> > > >
> > > >
> > > > Neil,
> > > >
> > > > for clarification purposes, the asymmetry I was referring=20
> > to was in=20
> > > > terms of bandwidth not path/route or other TE parameter,=20
> > but maybe I=20
> > > > did not catch what you meant by *routings*.
> > > >
> > > > regards,
> > > >
> > > > martin
> > > >
> > > > [email-masked] a =E9crit :
> > > > > I would caution against the observation that because=20
> > traffic flows
> > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > consumed at any
> > > > > epoch) their *routings* can also be asymmetric....this does
> > > > not follow
> > > > > at all. This observation applies to all layer networks (any=20
> > > > > mode/technology).
> > > > >
> > > > > regards, Neil
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: [email-masked]=20
> > [mailto:[email-masked]]=20
> > > > >> On Behalf Of Martin Vigoureux
> > > > >> Sent: 19 April 2007 08:34
> > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou=20
> > > > >> Berger
> > > > >> Cc: [email-masked]
> > > > >> Subject: Re: Switching technologies requiring bidirectional
> > > > >> asymmetric LSPs?
> > > > >>
> > > > >>
> > > > >> All,
> > > > >>
> > > > >> I do believe in the need for asymmetric bidirectional LSPs.=20
> > > > >> Traffic is by nature asymmetric (for the vast majority=20
> > of it at=20
> > > > >> least). We may argue that the sum of asymmetric=20
> traffic could=20
> > > > >> lead to symmetric traffic or that the above statement is=20
> > > > >> dependent on the network segment we are considering,=20
> > but it will=20
> > > > >> remain true and we should definitely capitalize on=20
> CCAMP prior=20
> > > > >> work by taking benefit from the advantages of=20
> > bidirectional LSP=20
> > > > >> setup.
> > > > >>
> > > > >> Furthermore, I believe we should not restrict the work and=20
> > > > >> solution to Ethernet technology only.
> > > > >>
> > > > >> martin
> > > > >>
> > > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > > >>> Hi all,
> > > > >>> please see inline [at]
> > > > >>> Regards,
> > > > >>> Attila
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> *From:* [email-masked]
> > > > >> [mailto:[email-masked]]
> > > > >>> *On Behalf Of *Igor Bryskin
> > > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > > > >>> *Subject:* Re: Switching technologies requiring=20
> bidirectional=20
> > > > >>> asymmetric LSPs?
> > > > >>>
> > > > >>> Adrian, Lou
> > > > >>>
> > > > >>> Please,see in line.
> > > > >>>
> > > > >>> */Adrian Farrel /* wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> I'm a bit surprised that there was no follow-up to=20
> > Lou's email.
> > > > >>>
> > > > >>> Does silence indicate that this was put to bed in
> > > > Prague and
> > > > >>> no-one is
> > > > >>> interested in these LSPs?
> > > > >>>
> > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > continue an
> > > > >>> offline discussion on the topic.
> > > > >>>
> > > > >>> > So a few of us have been having been discussing the
> > > > >>> asymmetric work
> > > > >>> > presented in Prague and it seems to me we have an open
> > > > >>> question on
> > > > >>> > requirements.
> > > > >>> >
> > > > >>> > It's clear that at least one switching
> > > > technology (i.e.,
> > > > >>> ethernet/PBB-TE)
> > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > >>>
> > > > >>> Is this clear? I continue to hear talk of service
> > > > >> requirements,
> > > > >>> but not so
> > > > >>> much of how those services are required to be supported.
> > > > >>>
> > > > >>> The benefits I have heard are:
> > > > >>> 1. Fewer control plane messages
> > > > >>> 2. Ease of enforecement of fate-sharing
> > > > >>>
> > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > >> bidirectional
> > > > >>> LSPs, and BTW you forgot to mention the most
> > > > important one.
> > > > >>> Ethernet OAM is designed, as I understand, on
> > > > >> assumption that
> > > > >>> the trafic takes the same paths in both
> > > > >> directions. So, if we
> > > > >>> want to preserve the Ethernet native OAM (which we
> > > > >> certainly do
> > > > >>> , because this is half of Ethernet functionality)
> > > > >> we must map a
> > > > >>> bidiretcional service on either a single
> > > > >> bidirectional LSP or
> > > > >>> two unidirectional LSPs using the same path. This
> > > > >> is different
> > > > >>> form MPLS where there are no such OAM requirements.
> > > > >>> Lou is talking about asymetrical bi-directional
> > > > >> LSPs, and what
> > > > >>> is not clear (at least for me) whether we need
> > > > >> asymetrical p2p
> > > > >>> Ethernet services.
> > > > >>>
> > > > >>> [at] Adrian's points are related to the single session vs.=20
> > > > >>> multiple session discussions we had, which is
> > > > >> generally true for
> > > > >>> any bidirectional LSP.
> > > > >>> The bidirectionality of Ethernet comes basically from two=20
> > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > >> most of the
> > > > >>> CFM functions will only operate properly if there are=20
> > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > GMPLS LPS is
> > > > >>> essentially a VLAN within which MAC learning is
> > > > >> operating one
> > > > >>> will need symmetric paths in order the learning functions=20
> > > > >>> properly.
> > > > >>>
> > > > >>> I had the impression that we already converged
> > > > >> before Prague to
> > > > >>> a single remaining question: do we need the
> > > > >>>> asymmetric bw<<
> > > > >>> extension for a single session bidirectional LSP.
> > > > There were
> > > > >>> some possible cases for asymmetric bw LSPs
> > > > mentioned by Don,
> > > > >>> Diego and myself but these seemed not to convince=20
> everybody.=20
> > > > >>> Imho we should focus on this question
> > > > not to loop
> > > > >>> into the discussion we had already.
> > > > >>>
> > > > >>> If we agree on that bidirectional services over
> > > > >> Ethernet need
> > > > >>> symmetrical paths than we could conclude that
> > > > using a single
> > > > >>> session to setup the bidirectional LSP would be the
> > > > >> preferred
> > > > >>> way at least over Ethernet. In this case, imho it is quite=20
> > > > >>> reasonable to assume that asymmetrical services
> > > > >> that require a
> > > > >>> dedicated LSP would also use a single signaling
> > > > exchange to
> > > > >>> setup the LSP, hence there would be a need for the
> > > > >> asymmetric bw
> > > > >>> extension. Following this thinking, the question
> > > > >> turns into the
> > > > >>> aggregation/hierarchy discussion that was bought up
> > > > >> by Dimitri
> > > > >>> earlier. That is, do we have the need of LSPs per
> > > > >> service. My
> > > > >>> two cents: generally not but there are certain
> > > > >> services where it
> > > > >>> is indeed a reasonable assumption, e.g., IPTV or private=20
> > > > >>> services.
> > > > >>>
> > > > >>> These are significant, but not dramatic, requirements.
> > > > >>>
> > > > >>> > The question is:
> > > > >>> >
> > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > >>> > (a) a technology specific requirement, or
> > > > >>> > (b) one that is common (this is CCAMP after
> > > > >> all!) to multiple
> > > > >>> switching
> > > > >>> > technologies?
> > > > >>>
> > > > >>> CCAMP deals in transport networks. As far as I can
> > > > >> see the service
> > > > >>> requirements would be pretty much the same all transport=20
> > > > >>> networks and would certainly be applicable to=20
> packet, L2, and=20
> > > > >>> TDM (the latter because TDM will
> > > > >>> be called on to support L2).
> > > > >>>
> > > > >>> IB>> See my comment above: there is a differnce
> > > > >> between MPLS and
> > > > >>> Ethernet services. Also there are certainly
> > > > >> differences between
> > > > >>> MPLS and lambda services (use of the same lambda in both=20
> > > > >>> directions, for example). So each transport
> > > > >> technology may have
> > > > >>> distinct requirements WRT bidirectional services
> > > > >> and connections
> > > > >>> on which the services are mapped.
> > > > >>>
> > > > >>> > Please keep in mind that service requirements
> > > > are not the
> > > > >>> same thing as
> > > > >>> > switching technology requirements. For example,
> > > > >> we have long
> > > > >>> built
> > > > >>> > bidirectional asymmetric services on
> > > > unidirectional MPLS
> > > > >>> LSPs.
> > > > >>>
> > > > >>> Well, exactly!
> > > > >>> Perhaps someone can explain why the Ethernet
> > > > >> hardware is forced
> > > > >>> to require
> > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > >>>
> > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > >>> Ethernet OAM.
> > > > >>>
> > > > >>> Igor
> > > > >>>
> > > > >>> > The answer to this question will help determine
> > > > >> if we should
> > > > >>> have a
> > > > >>> > technology specific solution or a generic CCAMP
> > > > >> solution (as
> > > > >>> well as the
> > > > >>> > complexity of the solution.)
> > > > >>>
> > > > >>> We should not take any action that deliberately
> > > > precludes or
> > > > >>> makes more
> > > > >>> complex the genericisation (is that an American
> > > > >> word?) of the
> > > > >>> solution
> > > > >>> unless there is a significant difference in simplicity of=20
> > > > >>> solutions.
> > > > >>>
> > > > >>> But we should take no action at all unless there is
> > > > >> some more
> > > > >>> evidence of
> > > > >>> support for this work!
> > > > >>>
> > > > >>> Adrian
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>=20
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> Ahhh...imagining that irresistible "new car" smell?=20
> Check out=20
> > > > >>> new cars at Yahoo! Autos.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > >>
> > > >=20
> > =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > WN
> > > > >>> hcnM->
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > >Ahhh...imagining that irresistible "new car" smell?
> > >Check out
> > ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
> _cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
> FncwRzbGsDbmV3LWNhcnM->new=20
> >cars at Yahoo! Autos.
>=20
>=20
>=20
>=20

Delivery-date: Thu, 19 Apr 2007 23:39:56 +0000
Date: Thu, 19 Apr 2007 19:37:58 -0400
To: <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Cc: <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>

At 12:27 PM 4/19/2007, [email-masked] wrote:
>[...]
>So, when you says LSPs you have to (i) be clear on the network mode 
>you are referring to and (ii) if the co-ps mode whether or not the 
>LSP respects the requirements of a connection...as not all LSPs do here.
>[...]

Neil,
         As you know LSP is a technology independent term used in 
MPLS and GMPLS.  The original question (requirement for bidirectional 
asymmetric-bandwidth *TE* LSPs) was intended to identify which 
network modes the WG considered important.  The motivation for the 
question was the discussions on  bidirectional asymmetric-bandwidth 
TE LSPs for co-ps, specifically Ethernet/PBB-TE, see 
draft-takacs-asym-bw-lsp.  Some have asked if we should define a 
mechanisms that supports other co-ps and co-cs technologies.  Others 
have said that we should not define mechanisms for any technology.

Does this help clarify the question?

Lou

PS

>Aside => One can clearly not construct client layer topoplogy from 
>mp2p server layer constructs!

and I'd claim that the current definition of mp2p is cl-ps...

Delivery-date: Thu, 19 Apr 2007 16:30:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric  LSPs?
Date: Thu, 19 Apr 2007 17:27:51 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Lou Berger asked 19 April 2007 15:05

>=20
>=20
> Neil,
>          I agree with Igor, much thanks for your input.
>=20
> In reading your response, it's clear that you see=20
> a place for bidirectional asymmetric-bandwidth=20
> *service*.  I think there is (and has been) general agreement on this.
>=20
> What's not clear to me is if you think there is=20
> any requirement for bidirectional asymmetric=20
> **LSPs**.  Do you have an opinion on this?
NH=3D> Well, it depends what you mean by an LSP.  As I've tried to point =
out in the past there are very good scientific reasons why we are forced =
to deal with 3 network modes...cl-ps, co-ps and co-cs...and why all =
technologies map to one of these.  Moreover the modes are fundamentally =
different...and you cannot apply the same treatment to them all.  We've =
done lots of work in explaining this within SG15 unified modelling based =
on Information Theory considerations of how both the labelling AND =
resource assignment work in space, freq and time dimensions.  The space =
and freq dimensions always force a co-cs mode behaviour.  However, it is =
how one slices up the time dimension that generates either the (TDM spin =
of the) co-cs mode or the co-ps mode.  Without getting into too much =
detail, when the time slices are regular (ie fixed in BOTH start datum =
AND duration) then labelling (which is also implicit) and resource =
assignment are coupled/fixed and the co-cs mode results.  However, when =
the time slices are irregular then labelling (which now has to be =
explicit) and resource assignment are decoupled the co-ps mode results.

The co-cs mode is extremely robust to arch misuse.  For example, one =
cannot violate the rules of a connection (ie single source, no internal =
routing) in the co-cs mode...and a connection is a crucial pre-requiste =
for all manner of things that one oftens wants determinsism on, like OAM =
and resource assignment per se for SLAs. The co-cs mode also has other =
desirable properties (like must have OOB control/management, no QoS =
classes, etc) which are highly beneficial and make networking =
simple...esp for network builder services (ie constructing the topology =
of other layer networks).

Now the co-ps is not so robust to arch misuse.  One can create mp2p =
merging constructs for example, as we find in MPLS.  These cannot have =
simple OAM nor can they provide deterministic resource =
assignment/management.

So, when you says LSPs you have to (i) be clear on the network mode you =
are referring to and (ii) if the co-ps mode whether or not the LSP =
respects the requirements of a connection...as not all LSPs do here.  =
Aside =3D> One can clearly not construct client layer topoplogy from =
mp2p server layer constructs!

If I am providing (or indeed procuring) a network builder service (ie I =
want to construct the topology of some higher client layer network....be =
this a public service network or indeed a private (VPN) network) then I =
would want 'LSPs' that respect the requirements of a =
connection...because I want to see some strong SLAs associated with that =
service.  In the general case these would be based on p2p BW symmetric =
constructs.  However, in the case of end-system applications supporting =
specific services like the ones I referred to in my response to Igor =
then the requirement may not indeed be symmetric....the p2mp =
*connection* being a case in point for say TV dist (residential) or =
financial data distribution (business/private).

Not sure if that helps Lou, but its the best I can offer for now.

regards, Neil

=20
>=20
> (if you already stated this, my apologies that I didn't=20
> understand you ...)
>=20
> Thanks,
> Lou
>=20
> At 09:18 AM 4/19/2007, [email-masked] wrote:
>=20
> >Thanks Igor....I think the answer is context sensitive.  For example:
> >
> >-    are we dealing with a client/server network=20
> >builder private service?...which may contain a
> >large number of aggregate end-system client application traffic flows
> >-    are we dealing with a single 'end system to=20
> >1st layer network adaptation' service?...which=20
> >may be a public or private service
> >
> >In the former case, and increasingly so as one
> >moves towards the duct, there is (of necessity)=20
> >a lack of detailed information of higher client=20
> >BW requirements.  So here there is a natural=20
> >case to want to provide symmetric BW=20
> >resources....and the atomic building block for=20
> >such services are p2p constructs.
> >
> >However, when we look towards specific
> >end-system services there is more scope for BW=20
> >resource asymmetry.......a video streaming=20
> >service would probably be like this.  Further,=20
> >it may not be simply p2p but p2mp.  I can also=20
> >imagine some creative thinking wrt to using a=20
> >co-ps mode with proper p2mp *connections*=20
> >providing the service in one direction (ie root=20
> >to leaves) ....because we want some strong=20
> >resource assignment and SLA guarantees, eg=20
> >distributing financial information to=20
> >traders.....but a cl-ps mode return network=20
> >(leaves to root) providing 'control signals'=20
> >(where strong resource assignment may not be so=20
> >important).  The return direction could however=20
> >be a set of N p2p connections (probably=20
> >congruently routed wrt to the other direction)=20
> >if strong resource assignment and SLAs were also=20
> >required in the return direction.  The former=20
> >case here could be considered quite novel as the=20
> >overall service is using 2 network modes and, by=20
> >definition, 2 different layer networks....so=20
> >here there is large degree of asymmetry here.
> >
> >So, as one moves towards the duct (and in
> >general for network builder services) there is,=20
> >IMO, a strong requirement for symmetry in all=20
> >aspects, but as one moves towards the=20
> >application there are cases where asymmetry is more appropriate.
> >
> >regards, Neil
> >
> >
> >-----Original Message-----
> >From: Igor Bryskin [mailto:[email-masked]]
> >Sent: 19 April 2007 13:36
> >To: Harrison,N,Neil,JCGA1 R;
> >[email-masked];=20
> >[email-masked]; [email-masked]; [email-masked]
> >Cc: [email-masked]
> >Subject: RE: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
> >
> >Neil,
> >
> >I consider your input very important to this discussion.
> >
> >My question is: Do you see use cases for
> >bidirectional p2p services which are=20
> >asymmetrical from the bandwidth reservation=20
> >point of view (that is, in S=3D>D direction you=20
> >need bandwidth B1, while in D=3D>S direction you=20
> >need bandwidth B2, and B1 is significantly=20
> >different from B2), but fully symmetrical in all=20
> >other aspects (i.e. routes, protection capability, etc.)
> >
> >Thanks,
> >Igor
> >
> >[email-masked] wrote:
> >Thanks Martin,
> >
> >Most applications generate asymmetric (wrt time)
> >information flows in each direction, ie the rate=20
> >of information flow in each direction is neither=20
> >constant nor directly proportional to the rate=20
> >of information flow in the other=20
> >direction....just think about a voice=20
> >conversation if not obvious....or even a file transfer.
> >
> >However, for an arbitrarily meshed network we
> >generally require symmetric routings of traffic=20
> >flows, ie if one direction passes the nodes=20
> >a->b->c->d in one direction then the other
> >direction should follow d->c->b->a in both this
> >and lower layer networks (to the duct).=20
> >Moreover, we usually require (under failure free=20
> >conditions) that such routings do not change=20
> >over the lifetime of a traffic flow.......this=20
> >is particularly important for connections (ie=20
> >co-ps and co-cs modes), and especially when they=20
> >are supporting a network builder service (a VPN=20
> >if you like), which may be a large aggregate of=20
> >all kinds of end-system application traffic=20
> >flows, for some other party. Note that if we add=20
> >nodes/links to a co mode layer network we should=20
> >not change existing connection routings. This is=20
> >not always the case with a cl-ps mode network,=20
> >ie because we do not have connections adding new=20
> >nodes/links can allow traffic flows to change routing.
> >
> >Is that more clear now wrt what I meant?
> >
> >regards, Neil
> >
> > > -----Original Message-----
> > > From: Martin Vigoureux [mailto:[email-masked]]
> > > Sent: 19 April 2007 09:37
> > > To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> > > [email-masked]; [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: Switching technologies requiring bidirectional=20
> > > asymmetric LSPs?
> > >
> > >
> > > Neil,
> > >
> > > for clarification purposes, the asymmetry I was referring=20
> to was in=20
> > > terms of bandwidth not path/route or other TE parameter,=20
> but maybe I=20
> > > did not catch what you meant by *routings*.
> > >
> > > regards,
> > >
> > > martin
> > >
> > > [email-masked] a =E9crit :
> > > > I would caution against the observation that because=20
> traffic flows
> > > > a->b and b->a are invariably asymmetric (wrt resource
> > > consumed at any
> > > > epoch) their *routings* can also be asymmetric....this does
> > > not follow
> > > > at all. This observation applies to all layer networks (any=20
> > > > mode/technology).
> > > >
> > > > regards, Neil
> > > >
> > > >> -----Original Message-----
> > > >> From: [email-masked]=20
> [mailto:[email-masked]]=20
> > > >> On Behalf Of Martin Vigoureux
> > > >> Sent: 19 April 2007 08:34
> > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou=20
> > > >> Berger
> > > >> Cc: [email-masked]
> > > >> Subject: Re: Switching technologies requiring bidirectional
> > > >> asymmetric LSPs?
> > > >>
> > > >>
> > > >> All,
> > > >>
> > > >> I do believe in the need for asymmetric bidirectional LSPs.=20
> > > >> Traffic is by nature asymmetric (for the vast majority=20
> of it at=20
> > > >> least). We may argue that the sum of asymmetric traffic could=20
> > > >> lead to symmetric traffic or that the above statement is=20
> > > >> dependent on the network segment we are considering,=20
> but it will=20
> > > >> remain true and we should definitely capitalize on CCAMP prior=20
> > > >> work by taking benefit from the advantages of=20
> bidirectional LSP=20
> > > >> setup.
> > > >>
> > > >> Furthermore, I believe we should not restrict the work and=20
> > > >> solution to Ethernet technology only.
> > > >>
> > > >> martin
> > > >>
> > > >> Attila Takacs (IJ/ETH) a =E9crit :
> > > >>> Hi all,
> > > >>> please see inline [at]
> > > >>> Regards,
> > > >>> Attila
> > > >>>
> > > >>>
> > > >> --------------------------------------------------------------
> > > >> ----------
> > > >>> *From:* [email-masked]
> > > >> [mailto:[email-masked]]
> > > >>> *On Behalf Of *Igor Bryskin
> > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > > >>> *Subject:* Re: Switching technologies requiring bidirectional=20
> > > >>> asymmetric LSPs?
> > > >>>
> > > >>> Adrian, Lou
> > > >>>
> > > >>> Please,see in line.
> > > >>>
> > > >>> */Adrian Farrel /* wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> I'm a bit surprised that there was no follow-up to=20
> Lou's email.
> > > >>>
> > > >>> Does silence indicate that this was put to bed in
> > > Prague and
> > > >>> no-one is
> > > >>> interested in these LSPs?
> > > >>>
> > > >>> [at] well, as Lou mentioned at least a few of us
> > > continue an
> > > >>> offline discussion on the topic.
> > > >>>
> > > >>> > So a few of us have been having been discussing the
> > > >>> asymmetric work
> > > >>> > presented in Prague and it seems to me we have an open
> > > >>> question on
> > > >>> > requirements.
> > > >>> >
> > > >>> > It's clear that at least one switching
> > > technology (i.e.,
> > > >>> ethernet/PBB-TE)
> > > >>> > requires support for bidirectional asymmetric LSPs.
> > > >>>
> > > >>> Is this clear? I continue to hear talk of service
> > > >> requirements,
> > > >>> but not so
> > > >>> much of how those services are required to be supported.
> > > >>>
> > > >>> The benefits I have heard are:
> > > >>> 1. Fewer control plane messages
> > > >>> 2. Ease of enforecement of fate-sharing
> > > >>>
> > > >>> IB>> Adrian, you enumerated here the benefits of
> > > >> bidirectional
> > > >>> LSPs, and BTW you forgot to mention the most
> > > important one.
> > > >>> Ethernet OAM is designed, as I understand, on
> > > >> assumption that
> > > >>> the trafic takes the same paths in both
> > > >> directions. So, if we
> > > >>> want to preserve the Ethernet native OAM (which we
> > > >> certainly do
> > > >>> , because this is half of Ethernet functionality)
> > > >> we must map a
> > > >>> bidiretcional service on either a single
> > > >> bidirectional LSP or
> > > >>> two unidirectional LSPs using the same path. This
> > > >> is different
> > > >>> form MPLS where there are no such OAM requirements.
> > > >>> Lou is talking about asymetrical bi-directional
> > > >> LSPs, and what
> > > >>> is not clear (at least for me) whether we need
> > > >> asymetrical p2p
> > > >>> Ethernet services.
> > > >>>
> > > >>> [at] Adrian's points are related to the single session vs.=20
> > > >>> multiple session discussions we had, which is
> > > >> generally true for
> > > >>> any bidirectional LSP.
> > > >>> The bidirectionality of Ethernet comes basically from two=20
> > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > >> most of the
> > > >>> CFM functions will only operate properly if there are=20
> > > >>> symmetrical paths. (2) on the other hand, if a
> > > GMPLS LPS is
> > > >>> essentially a VLAN within which MAC learning is
> > > >> operating one
> > > >>> will need symmetric paths in order the learning functions=20
> > > >>> properly.
> > > >>>
> > > >>> I had the impression that we already converged
> > > >> before Prague to
> > > >>> a single remaining question: do we need the
> > > >>>> asymmetric bw<<
> > > >>> extension for a single session bidirectional LSP.
> > > There were
> > > >>> some possible cases for asymmetric bw LSPs
> > > mentioned by Don,
> > > >>> Diego and myself but these seemed not to convince everybody.=20
> > > >>> Imho we should focus on this question
> > > not to loop
> > > >>> into the discussion we had already.
> > > >>>
> > > >>> If we agree on that bidirectional services over
> > > >> Ethernet need
> > > >>> symmetrical paths than we could conclude that
> > > using a single
> > > >>> session to setup the bidirectional LSP would be the
> > > >> preferred
> > > >>> way at least over Ethernet. In this case, imho it is quite=20
> > > >>> reasonable to assume that asymmetrical services
> > > >> that require a
> > > >>> dedicated LSP would also use a single signaling
> > > exchange to
> > > >>> setup the LSP, hence there would be a need for the
> > > >> asymmetric bw
> > > >>> extension. Following this thinking, the question
> > > >> turns into the
> > > >>> aggregation/hierarchy discussion that was bought up
> > > >> by Dimitri
> > > >>> earlier. That is, do we have the need of LSPs per
> > > >> service. My
> > > >>> two cents: generally not but there are certain
> > > >> services where it
> > > >>> is indeed a reasonable assumption, e.g., IPTV or private=20
> > > >>> services.
> > > >>>
> > > >>> These are significant, but not dramatic, requirements.
> > > >>>
> > > >>> > The question is:
> > > >>> >
> > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > >>> > (a) a technology specific requirement, or
> > > >>> > (b) one that is common (this is CCAMP after
> > > >> all!) to multiple
> > > >>> switching
> > > >>> > technologies?
> > > >>>
> > > >>> CCAMP deals in transport networks. As far as I can
> > > >> see the service
> > > >>> requirements would be pretty much the same all transport=20
> > > >>> networks and would certainly be applicable to packet, L2, and=20
> > > >>> TDM (the latter because TDM will
> > > >>> be called on to support L2).
> > > >>>
> > > >>> IB>> See my comment above: there is a differnce
> > > >> between MPLS and
> > > >>> Ethernet services. Also there are certainly
> > > >> differences between
> > > >>> MPLS and lambda services (use of the same lambda in both=20
> > > >>> directions, for example). So each transport
> > > >> technology may have
> > > >>> distinct requirements WRT bidirectional services
> > > >> and connections
> > > >>> on which the services are mapped.
> > > >>>
> > > >>> > Please keep in mind that service requirements
> > > are not the
> > > >>> same thing as
> > > >>> > switching technology requirements. For example,
> > > >> we have long
> > > >>> built
> > > >>> > bidirectional asymmetric services on
> > > unidirectional MPLS
> > > >>> LSPs.
> > > >>>
> > > >>> Well, exactly!
> > > >>> Perhaps someone can explain why the Ethernet
> > > >> hardware is forced
> > > >>> to require
> > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > >>>
> > > >>> IB>> Again, IMO the answer is to be able to use native
> > > >>> Ethernet OAM.
> > > >>>
> > > >>> Igor
> > > >>>
> > > >>> > The answer to this question will help determine
> > > >> if we should
> > > >>> have a
> > > >>> > technology specific solution or a generic CCAMP
> > > >> solution (as
> > > >>> well as the
> > > >>> > complexity of the solution.)
> > > >>>
> > > >>> We should not take any action that deliberately
> > > precludes or
> > > >>> makes more
> > > >>> complex the genericisation (is that an American
> > > >> word?) of the
> > > >>> solution
> > > >>> unless there is a significant difference in simplicity of=20
> > > >>> solutions.
> > > >>>
> > > >>> But we should take no action at all unless there is
> > > >> some more
> > > >>> evidence of
> > > >>> support for this work!
> > > >>>
> > > >>> Adrian
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >> --------------------------------------------------------------
> > > >> ----------
> > > >>> Ahhh...imagining that irresistible "new car" smell? Check out=20
> > > >>> new cars at Yahoo! Autos.
> > > >>>
> > > >>>
> > > >>
> > > >> *http://autos.yahoo.com/new_cars.htm
> > > >>
> > >=20
> l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > WN
> > > >>> hcnM->
> > > >>>
> > > >>
> > > >
> > >
> >
> >
> >
> >Ahhh...imagining that irresistible "new car" smell?
> >Check out
> ><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new
_cars.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGs=
DbmV3LWNhcnM->new=20
>cars at Yahoo! Autos.

Delivery-date: Thu, 19 Apr 2007 14:07:06 +0000
Date: Thu, 19 Apr 2007 10:04:45 -0400
To: <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Cc: <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>,<[email-masked]>, <[email-masked]>

Neil,
         I agree with Igor, much thanks for your input.

In reading your response, it's clear that you see=20
a place for bidirectional asymmetric-bandwidth=20
*service*.  I think there is (and has been) general agreement on this.

What's not clear to me is if you think there is=20
any requirement for bidirectional asymmetric=20
**LSPs**.  Do you have an opinion on this?

(if you already stated this, my apologies that I didn't understand you ...)

Thanks,
Lou

At 09:18 AM 4/19/2007, [email-masked] wrote:

>Thanks Igor....I think the answer is context sensitive.  For example:
>
>-    are we dealing with a client/server network=20
>builder private service?...which may contain a=20
>large number of aggregate end-system client application traffic flows
>-    are we dealing with a single 'end system to=20
>1st layer network adaptation' service?...which=20
>may be a public or private service
>
>In the former case, and increasingly so as one=20
>moves towards the duct, there is (of necessity)=20
>a lack of detailed information of higher client=20
>BW requirements.  So here there is a natural=20
>case to want to provide symmetric BW=20
>resources....and the atomic building block for=20
>such services are p2p constructs.
>
>However, when we look towards specific=20
>end-system services there is more scope for BW=20
>resource asymmetry.......a video streaming=20
>service would probably be like this.  Further,=20
>it may not be simply p2p but p2mp.  I can also=20
>imagine some creative thinking wrt to using a=20
>co-ps mode with proper p2mp *connections*=20
>providing the service in one direction (ie root=20
>to leaves) ....because we want some strong=20
>resource assignment and SLA guarantees, eg=20
>distributing financial information to=20
>traders.....but a cl-ps mode return network=20
>(leaves to root) providing 'control signals'=20
>(where strong resource assignment may not be so=20
>important).  The return direction could however=20
>be a set of N p2p connections (probably=20
>congruently routed wrt to the other direction)=20
>if strong resource assignment and SLAs were also=20
>required in the return direction.  The former=20
>case here could be considered quite novel as the=20
>overall service is using 2 network modes and, by=20
>definition, 2 different layer networks....so=20
>here there is large degree of asymmetry here.
>
>So, as one moves towards the duct (and in=20
>general for network builder services) there is,=20
>IMO, a strong requirement for symmetry in all=20
>aspects, but as one moves towards the=20
>application there are cases where asymmetry is more appropriate.
>
>regards, Neil
>
>
>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]
>Sent: 19 April 2007 13:36
>To: Harrison,N,Neil,JCGA1 R;=20
>[email-masked];=20
>[email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: Switching technologies requiring bidirectional asymmetric=
 LSPs?
>
>Neil,
>
>I consider your input very important to this discussion.
>
>My question is: Do you see use cases for=20
>bidirectional p2p services which are=20
>asymmetrical from the bandwidth reservation=20
>point of view (that is, in S=3D>D direction you=20
>need bandwidth B1, while in D=3D>S direction you=20
>need bandwidth B2, and B1 is significantly=20
>different from B2), but fully symmetrical in all=20
>other aspects (i.e. routes, protection capability, etc.)
>
>Thanks,
>Igor
>
>[email-masked] wrote:
>Thanks Martin,
>
>Most applications generate asymmetric (wrt time)=20
>information flows in each direction, ie the rate=20
>of information flow in each direction is neither=20
>constant nor directly proportional to the rate=20
>of information flow in the other=20
>direction....just think about a voice=20
>conversation if not obvious....or even a file transfer.
>
>However, for an arbitrarily meshed network we=20
>generally require symmetric routings of traffic=20
>flows, ie if one direction passes the nodes=20
>a->b->c->d in one direction then the other=20
>direction should follow d->c->b->a in both this=20
>and lower layer networks (to the duct).=20
>Moreover, we usually require (under failure free=20
>conditions) that such routings do not change=20
>over the lifetime of a traffic flow.......this=20
>is particularly important for connections (ie=20
>co-ps and co-cs modes), and especially when they=20
>are supporting a network builder service (a VPN=20
>if you like), which may be a large aggregate of=20
>all kinds of end-system application traffic=20
>flows, for some other party. Note that if we add=20
>nodes/links to a co mode layer network we should=20
>not change existing connection routings. This is=20
>not always the case with a cl-ps mode network,=20
>ie because we do not have connections adding new=20
>nodes/links can allow traffic flows to change routing.
>
>Is that more clear now wrt what I meant?
>
>regards, Neil
>
> > -----Original Message-----
> > From: Martin Vigoureux [mailto:[email-masked]]
> > Sent: 19 April 2007 09:37
> > To: Harrison,N,Neil,JCGA1 R; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: Re: Switching technologies requiring bidirectional
> > asymmetric LSPs?
> >
> >
> > Neil,
> >
> > for clarification purposes, the asymmetry I was referring to
> > was in terms of bandwidth not path/route or other TE
> > parameter, but maybe I did not catch what you meant by *routings*.
> >
> > regards,
> >
> > martin
> >
> > [email-masked] a =E9crit :
> > > I would caution against the observation that because traffic flows
> > > a->b and b->a are invariably asymmetric (wrt resource
> > consumed at any
> > > epoch) their *routings* can also be asymmetric....this does
> > not follow
> > > at all. This observation applies to all layer networks (any
> > > mode/technology).
> > >
> > > regards, Neil
> > >
> > >> -----Original Message-----
> > >> From: [email-masked]
> > >> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> > >> Sent: 19 April 2007 08:34
> > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> > >> Cc: [email-masked]
> > >> Subject: Re: Switching technologies requiring bidirectional
> > >> asymmetric LSPs?
> > >>
> > >>
> > >> All,
> > >>
> > >> I do believe in the need for asymmetric bidirectional LSPs.
> > >> Traffic is by nature asymmetric (for the vast majority of it
> > >> at least). We may argue that the sum of asymmetric traffic
> > >> could lead to symmetric traffic or that the above statement
> > >> is dependent on the network segment we are considering, but
> > >> it will remain true and we should definitely capitalize on
> > >> CCAMP prior work by taking benefit from the advantages of
> > >> bidirectional LSP setup.
> > >>
> > >> Furthermore, I believe we should not restrict the work and
> > >> solution to Ethernet technology only.
> > >>
> > >> martin
> > >>
> > >> Attila Takacs (IJ/ETH) a =E9crit :
> > >>> Hi all,
> > >>> please see inline [at]
> > >>> Regards,
> > >>> Attila
> > >>>
> > >>>
> > >> --------------------------------------------------------------
> > >> ----------
> > >>> *From:* [email-masked]
> > >> [mailto:[email-masked]]
> > >>> *On Behalf Of *Igor Bryskin
> > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> > >>> *Subject:* Re: Switching technologies requiring bidirectional
> > >>> asymmetric LSPs?
> > >>>
> > >>> Adrian, Lou
> > >>>
> > >>> Please,see in line.
> > >>>
> > >>> */Adrian Farrel /* wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> I'm a bit surprised that there was no follow-up to Lou's
> > >>> email.
> > >>>
> > >>> Does silence indicate that this was put to bed in
> > Prague and
> > >>> no-one is
> > >>> interested in these LSPs?
> > >>>
> > >>> [at] well, as Lou mentioned at least a few of us
> > continue an
> > >>> offline discussion on the topic.
> > >>>
> > >>> > So a few of us have been having been discussing the
> > >>> asymmetric work
> > >>> > presented in Prague and it seems to me we have an open
> > >>> question on
> > >>> > requirements.
> > >>> >
> > >>> > It's clear that at least one switching
> > technology (i.e.,
> > >>> ethernet/PBB-TE)
> > >>> > requires support for bidirectional asymmetric LSPs.
> > >>>
> > >>> Is this clear? I continue to hear talk of service
> > >> requirements,
> > >>> but not so
> > >>> much of how those services are required to be supported.
> > >>>
> > >>> The benefits I have heard are:
> > >>> 1. Fewer control plane messages
> > >>> 2. Ease of enforecement of fate-sharing
> > >>>
> > >>> IB>> Adrian, you enumerated here the benefits of
> > >> bidirectional
> > >>> LSPs, and BTW you forgot to mention the most
> > important one.
> > >>> Ethernet OAM is designed, as I understand, on
> > >> assumption that
> > >>> the trafic takes the same paths in both
> > >> directions. So, if we
> > >>> want to preserve the Ethernet native OAM (which we
> > >> certainly do
> > >>> , because this is half of Ethernet functionality)
> > >> we must map a
> > >>> bidiretcional service on either a single
> > >> bidirectional LSP or
> > >>> two unidirectional LSPs using the same path. This
> > >> is different
> > >>> form MPLS where there are no such OAM requirements.
> > >>> Lou is talking about asymetrical bi-directional
> > >> LSPs, and what
> > >>> is not clear (at least for me) whether we need
> > >> asymetrical p2p
> > >>> Ethernet services.
> > >>>
> > >>> [at] Adrian's points are related to the single session vs.
> > >>> multiple session discussions we had, which is
> > >> generally true for
> > >>> any bidirectional LSP.
> > >>> The bidirectionality of Ethernet comes basically from two
> > >>> aspects imho: (1) in any case, as Igor pointed out,
> > >> most of the
> > >>> CFM functions will only operate properly if there are
> > >>> symmetrical paths. (2) on the other hand, if a
> > GMPLS LPS is
> > >>> essentially a VLAN within which MAC learning is
> > >> operating one
> > >>> will need symmetric paths in order the learning functions
> > >>> properly.
> > >>>
> > >>> I had the impression that we already converged
> > >> before Prague to
> > >>> a single remaining question: do we need the
> > >>>> asymmetric bw<<
> > >>> extension for a single session bidirectional LSP.
> > There were
> > >>> some possible cases for asymmetric bw LSPs
> > mentioned by Don,
> > >>> Diego and myself but these seemed not to convince
> > >>> everybody. Imho we should focus on this question
> > not to loop
> > >>> into the discussion we had already.
> > >>>
> > >>> If we agree on that bidirectional services over
> > >> Ethernet need
> > >>> symmetrical paths than we could conclude that
> > using a single
> > >>> session to setup the bidirectional LSP would be the
> > >> preferred
> > >>> way at least over Ethernet. In this case, imho it is quite
> > >>> reasonable to assume that asymmetrical services
> > >> that require a
> > >>> dedicated LSP would also use a single signaling
> > exchange to
> > >>> setup the LSP, hence there would be a need for the
> > >> asymmetric bw
> > >>> extension. Following this thinking, the question
> > >> turns into the
> > >>> aggregation/hierarchy discussion that was bought up
> > >> by Dimitri
> > >>> earlier. That is, do we have the need of LSPs per
> > >> service. My
> > >>> two cents: generally not but there are certain
> > >> services where it
> > >>> is indeed a reasonable assumption, e.g., IPTV or private
> > >>> services.
> > >>>
> > >>> These are significant, but not dramatic, requirements.
> > >>>
> > >>> > The question is:
> > >>> >
> > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > >>> > (a) a technology specific requirement, or
> > >>> > (b) one that is common (this is CCAMP after
> > >> all!) to multiple
> > >>> switching
> > >>> > technologies?
> > >>>
> > >>> CCAMP deals in transport networks. As far as I can
> > >> see the service
> > >>> requirements would be pretty much the same all transport
> > >>> networks and would
> > >>> certainly be applicable to packet, L2, and TDM (the latter
> > >>> because TDM will
> > >>> be called on to support L2).
> > >>>
> > >>> IB>> See my comment above: there is a differnce
> > >> between MPLS and
> > >>> Ethernet services. Also there are certainly
> > >> differences between
> > >>> MPLS and lambda services (use of the same lambda in both
> > >>> directions, for example). So each transport
> > >> technology may have
> > >>> distinct requirements WRT bidirectional services
> > >> and connections
> > >>> on which the services are mapped.
> > >>>
> > >>> > Please keep in mind that service requirements
> > are not the
> > >>> same thing as
> > >>> > switching technology requirements. For example,
> > >> we have long
> > >>> built
> > >>> > bidirectional asymmetric services on
> > unidirectional MPLS
> > >>> LSPs.
> > >>>
> > >>> Well, exactly!
> > >>> Perhaps someone can explain why the Ethernet
> > >> hardware is forced
> > >>> to require
> > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > >>>
> > >>> IB>> Again, IMO the answer is to be able to use native
> > >>> Ethernet OAM.
> > >>>
> > >>> Igor
> > >>>
> > >>> > The answer to this question will help determine
> > >> if we should
> > >>> have a
> > >>> > technology specific solution or a generic CCAMP
> > >> solution (as
> > >>> well as the
> > >>> > complexity of the solution.)
> > >>>
> > >>> We should not take any action that deliberately
> > precludes or
> > >>> makes more
> > >>> complex the genericisation (is that an American
> > >> word?) of the
> > >>> solution
> > >>> unless there is a significant difference in simplicity of
> > >>> solutions.
> > >>>
> > >>> But we should take no action at all unless there is
> > >> some more
> > >>> evidence of
> > >>> support for this work!
> > >>>
> > >>> Adrian
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >> --------------------------------------------------------------
> > >> ----------
> > >>> Ahhh...imagining that irresistible "new car" smell?
> > >>> Check out new cars at Yahoo! Autos.
> > >>>
> > >>>
> > >>
> > >> *http://autos.yahoo.com/new_cars.htm
> > >>
> > l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> > >>> hcnM->
> > >>>
> > >>
> > >
> >
>
>
>
>Ahhh...imagining that irresistible "new car" smell?
>Check out=20
><http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new_cars.html;_=
ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->n=
ew=20
>cars at Yahoo! Autos.

Delivery-date: Thu, 19 Apr 2007 13:19:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Thu, 19 Apr 2007 14:18:13 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Thanks Igor....I think the answer is context sensitive.  For example:
=20
-    are we dealing with a client/server network builder private =
service?...which may contain a large number of aggregate end-system =
client application traffic flows
-    are we dealing with a single 'end system to 1st layer network =
adaptation' service?...which may be a public or private service
=20
In the former case, and increasingly so as one moves towards the duct, =
there is (of necessity) a lack of detailed information of higher client =
BW requirements.  So here there is a natural case to want to provide =
symmetric BW resources....and the atomic building block for such =
services are p2p constructs.
=20
However, when we look towards specific end-system services there is more =
scope for BW resource asymmetry.......a video streaming service would =
probably be like this.  Further, it may not be simply p2p but p2mp.  I =
can also imagine some creative thinking wrt to using a co-ps mode with =
proper p2mp *connections* providing the service in one direction (ie =
root to leaves) ....because we want some strong resource assignment and =
SLA guarantees, eg distributing financial information to traders.....but =
a cl-ps mode return network (leaves to root) providing 'control signals' =
(where strong resource assignment may not be so important).  The return =
direction could however be a set of N p2p connections (probably =
congruently routed wrt to the other direction) if strong resource =
assignment and SLAs were also required in the return direction.  The =
former case here could be considered quite novel as the overall service =
is using 2 network modes and, by definition, 2 different layer =
networks....so here there is large degree of asymmetry here.
=20
So, as one moves towards the duct (and in general for network builder =
services) there is, IMO, a strong requirement for symmetry in all =
aspects, but as one moves towards the application there are cases where =
asymmetry is more appropriate.
=20
regards, Neil=20
=20
=20

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]=20
Sent: 19 April 2007 13:36
To: Harrison,N,Neil,JCGA1 R; [email-masked]; =
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Switching technologies requiring bidirectional asymmetric =
LSPs?

Neil,

I consider your input very important to this discussion.=20

My question is: Do you see use cases for bidirectional p2p services =
which are asymmetrical from the bandwidth reservation point of view =
(that is, in S=3D>D direction you need bandwidth B1, while in D=3D>S =
direction you need bandwidth B2, and B1 is significantly different from =
B2), but fully symmetrical in all other aspects (i.e. routes, protection =
capability, etc.)

Thanks,
Igor

[email-masked] wrote:=20

Thanks Martin,

Most applications generate asymmetric (wrt time) information flows in =
each direction, ie the rate of information flow in each direction is =
neither constant nor directly proportional to the rate of information =
flow in the other direction....just think about a voice conversation if =
not obvious....or even a file transfer.

However, for an arbitrarily meshed network we generally require =
symmetric routings of traffic flows, ie if one direction passes the =
nodes a->b->c->d in one direction then the other direction should follow =
d->c->b->a in both this and lower layer networks (to the duct). =
Moreover, we usually require (under failure free conditions) that such =
routings do not change over the lifetime of a traffic flow.......this is =
particularly important for connections (ie co-ps and co-cs modes), and =
especially when they are supporting a network builder service (a VPN if =
you like), which may be a large aggregate of all kinds of end-system =
application traffic flows, for some other party. Note that if we add =
nodes/links to a co mode layer network we should not change existing =
connection routings. This is not always the case with a cl-ps mode =
network, ie because we do not have connections adding new nodes/links =
can allow traffic flows to change routing.

Is that more clear now wrt what I meant?

regards, Neil

> -----Original Message-----
> From: Martin Vigoureux [mailto:[email-masked]]=20
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
>=20
> Neil,
>=20
> for clarification purposes, the asymmetry I was referring to=20
> was in terms of bandwidth not path/route or other TE=20
> parameter, but maybe I did not catch what you meant by *routings*.
>=20
> regards,
>=20
> martin
>=20
> [email-masked] a =E9crit :
> > I would caution against the observation that because traffic flows=20
> > a->b and b->a are invariably asymmetric (wrt resource=20
> consumed at any=20
> > epoch) their *routings* can also be asymmetric....this does=20
> not follow=20
> > at all. This observation applies to all layer networks (any=20
> > mode/technology).
> >=20
> > regards, Neil
> >=20
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> >> Sent: 19 April 2007 08:34
> >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> Subject: Re: Switching technologies requiring bidirectional=20
> >> asymmetric LSPs?
> >>
> >>
> >> All,
> >>
> >> I do believe in the need for asymmetric bidirectional LSPs.
> >> Traffic is by nature asymmetric (for the vast majority of it=20
> >> at least). We may argue that the sum of asymmetric traffic=20
> >> could lead to symmetric traffic or that the above statement=20
> >> is dependent on the network segment we are considering, but=20
> >> it will remain true and we should definitely capitalize on=20
> >> CCAMP prior work by taking benefit from the advantages of=20
> >> bidirectional LSP setup.
> >>
> >> Furthermore, I believe we should not restrict the work and
> >> solution to Ethernet technology only.
> >>
> >> martin
> >>
> >> Attila Takacs (IJ/ETH) a =E9crit :
> >>> Hi all,
> >>> please see inline [at]
> >>> Regards,
> >>> Attila
> >>>
> >>>=20
> >> --------------------------------------------------------------
> >> ----------
> >>> *From:* [email-masked]
> >> [mailto:[email-masked]]
> >>> *On Behalf Of *Igor Bryskin
> >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> >>> *To:* Adrian Farrel; [email-masked]; Lou Berger
> >>> *Subject:* Re: Switching technologies requiring bidirectional
> >>> asymmetric LSPs?
> >>>
> >>> Adrian, Lou
> >>>
> >>> Please,see in line.
> >>>
> >>> */Adrian Farrel /* wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm a bit surprised that there was no follow-up to Lou's
> >>> email.
> >>>
> >>> Does silence indicate that this was put to bed in=20
> Prague and
> >>> no-one is
> >>> interested in these LSPs?
> >>>=20
> >>> [at] well, as Lou mentioned at least a few of us=20
> continue an
> >>> offline discussion on the topic.
> >>>=20
> >>> > So a few of us have been having been discussing the
> >>> asymmetric work
> >>> > presented in Prague and it seems to me we have an open
> >>> question on
> >>> > requirements.
> >>> >
> >>> > It's clear that at least one switching=20
> technology (i.e.,
> >>> ethernet/PBB-TE)
> >>> > requires support for bidirectional asymmetric LSPs.
> >>>
> >>> Is this clear? I continue to hear talk of service
> >> requirements,
> >>> but not so
> >>> much of how those services are required to be supported.
> >>>
> >>> The benefits I have heard are:
> >>> 1. Fewer control plane messages
> >>> 2. Ease of enforecement of fate-sharing
> >>>
> >>> IB>> Adrian, you enumerated here the benefits of
> >> bidirectional
> >>> LSPs, and BTW you forgot to mention the most=20
> important one.
> >>> Ethernet OAM is designed, as I understand, on
> >> assumption that
> >>> the trafic takes the same paths in both
> >> directions. So, if we
> >>> want to preserve the Ethernet native OAM (which we
> >> certainly do
> >>> , because this is half of Ethernet functionality)
> >> we must map a
> >>> bidiretcional service on either a single
> >> bidirectional LSP or
> >>> two unidirectional LSPs using the same path. This
> >> is different
> >>> form MPLS where there are no such OAM requirements.
> >>> Lou is talking about asymetrical bi-directional
> >> LSPs, and what
> >>> is not clear (at least for me) whether we need
> >> asymetrical p2p
> >>> Ethernet services.
> >>>=20
> >>> [at] Adrian's points are related to the single session vs.
> >>> multiple session discussions we had, which is
> >> generally true for
> >>> any bidirectional LSP.
> >>> The bidirectionality of Ethernet comes basically from two
> >>> aspects imho: (1) in any case, as Igor pointed out,
> >> most of the
> >>> CFM functions will only operate properly if there are
> >>> symmetrical paths. (2) on the other hand, if a=20
> GMPLS LPS is
> >>> essentially a VLAN within which MAC learning is
> >> operating one
> >>> will need symmetric paths in order the learning functions
> >>> properly.
> >>>=20
> >>> I had the impression that we already converged
> >> before Prague to
> >>> a single remaining question: do we need the
> >>>> asymmetric bw<<
> >>> extension for a single session bidirectional LSP.=20
> There were
> >>> some possible cases for asymmetric bw LSPs=20
> mentioned by Don,
> >>> Diego and myself but these seemed not to convince
> >>> everybody. Imho we should focus on this question=20
> not to loop
> >>> into the discussion we had already.
> >>>=20
> >>> If we agree on that bidirectional services over
> >> Ethernet need
> >>> symmetrical paths than we could conclude that=20
> using a single
> >>> session to setup the bidirectional LSP would be the
> >> preferred
> >>> way at least over Ethernet. In this case, imho it is quite
> >>> reasonable to assume that asymmetrical services
> >> that require a
> >>> dedicated LSP would also use a single signaling=20
> exchange to
> >>> setup the LSP, hence there would be a need for the
> >> asymmetric bw
> >>> extension. Following this thinking, the question
> >> turns into the
> >>> aggregation/hierarchy discussion that was bought up
> >> by Dimitri
> >>> earlier. That is, do we have the need of LSPs per
> >> service. My
> >>> two cents: generally not but there are certain
> >> services where it
> >>> is indeed a reasonable assumption, e.g., IPTV or private
> >>> services.
> >>>=20
> >>> These are significant, but not dramatic, requirements.
> >>>
> >>> > The question is:
> >>> >
> >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> >>> > (a) a technology specific requirement, or
> >>> > (b) one that is common (this is CCAMP after
> >> all!) to multiple
> >>> switching
> >>> > technologies?
> >>>
> >>> CCAMP deals in transport networks. As far as I can
> >> see the service
> >>> requirements would be pretty much the same all transport
> >>> networks and would
> >>> certainly be applicable to packet, L2, and TDM (the latter
> >>> because TDM will
> >>> be called on to support L2).
> >>>
> >>> IB>> See my comment above: there is a differnce
> >> between MPLS and
> >>> Ethernet services. Also there are certainly
> >> differences between
> >>> MPLS and lambda services (use of the same lambda in both
> >>> directions, for example). So each transport
> >> technology may have
> >>> distinct requirements WRT bidirectional services
> >> and connections
> >>> on which the services are mapped.
> >>>
> >>> > Please keep in mind that service requirements=20
> are not the
> >>> same thing as
> >>> > switching technology requirements. For example,
> >> we have long
> >>> built
> >>> > bidirectional asymmetric services on=20
> unidirectional MPLS
> >>> LSPs.
> >>>
> >>> Well, exactly!
> >>> Perhaps someone can explain why the Ethernet
> >> hardware is forced
> >>> to require
> >>> bidirectional asymmetric LSPs when MPLS is happy without?
> >>>
> >>> IB>> Again, IMO the answer is to be able to use native
> >>> Ethernet OAM.
> >>>
> >>> Igor
> >>>
> >>> > The answer to this question will help determine
> >> if we should
> >>> have a
> >>> > technology specific solution or a generic CCAMP
> >> solution (as
> >>> well as the
> >>> > complexity of the solution.)
> >>>
> >>> We should not take any action that deliberately=20
> precludes or
> >>> makes more
> >>> complex the genericisation (is that an American
> >> word?) of the
> >>> solution
> >>> unless there is a significant difference in simplicity of
> >>> solutions.
> >>>
> >>> But we should take no action at all unless there is
> >> some more
> >>> evidence of
> >>> support for this work!
> >>>
> >>> Adrian
> >>>
> >>>
> >>>
> >>>
> >>>=20
> >> --------------------------------------------------------------
> >> ----------
> >>> Ahhh...imagining that irresistible "new car" smell?
> >>> Check out new cars at Yahoo! Autos.
> >>>=20
> >>>
> >>=20
> >> *http://autos.yahoo.com/new_cars.htm
> >>=20
> =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> >>> hcnM->
> >=20
>=20

  _____ =20

Ahhh...imagining that irresistible "new car" smell?
Check out new  =
<http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new_cars.html=
;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhc=
nM-> cars at Yahoo! Autos.=20

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

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

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Thanks Igor....I think the answer is context sensitive.&nbsp; =
For=20
example:</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>-&nbsp;&nbsp;&nbsp; are we dealing with a client/server network =
builder=20
private service?...which may contain a large number of aggregate =
end-system=20
client application traffic flows</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>-&nbsp;&nbsp;&nbsp; are we dealing with a single&nbsp;'end =
system to 1st=20
layer network adaptation' service?...which may be a public or private=20
service</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>In the former case, and increasingly so as one moves towards =
the duct,=20
there is (of necessity) a lack of detailed information of higher client =
BW=20
requirements.&nbsp; So here there is a natural case to want to provide =
symmetric=20
BW resources....and the atomic building block for such services are p2p=20
constructs.</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>However, when we look towards specific end-system services =
there is more=20
scope for BW resource asymmetry.......a video streaming service would =
probably=20
be like this.&nbsp; Further, it may not be simply p2p but p2mp.&nbsp; I =
can also=20
imagine some creative thinking wrt to using a co-ps mode with proper =
p2mp=20
*connections* providing the service in one direction (ie root to leaves) =

....because we want some strong resource assignment and SLA guarantees, =
eg=20
distributing financial information to traders.....but a cl-ps mode =
return=20
network (leaves to root) providing 'control signals' (where strong =
resource=20
assignment may not be so important).&nbsp; The return direction could =
however be=20
a set of N p2p connections (probably congruently routed wrt to the other =

direction) if strong resource assignment and SLAs were also required in =
the=20
return direction.&nbsp; The former case here could be considered quite =
novel as=20
the overall service is using 2 network modes and, by definition, 2 =
different=20
layer networks....so here there is large degree of asymmetry=20
here.</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>So, as one moves towards the duct (and in general for network =
builder=20
services) there is, IMO, a strong requirement for symmetry in all =
aspects, but=20
as one moves towards the application there are cases where asymmetry is =
more=20
appropriate.</FONT></SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT>&nbsp;</SPAN></DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D177494712-19042007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 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> Igor =
Bryskin=20
  [mailto:[email-masked]] <BR><B>Sent:</B> 19 April 2007=20
  13:36<BR><B>To:</B> Harrison,N,Neil,JCGA1 R;=20
  [email-masked]; [email-masked];=20
  [email-masked]; [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE: Switching technologies =
requiring=20
  bidirectional asymmetric LSPs?<BR><BR></FONT></DIV>Neil,<BR><BR>I =
consider=20
  your input very important to this discussion. <BR><BR>My question is: =
Do you=20
  see use cases for bidirectional p2p services which are asymmetrical =
from the=20
  bandwidth reservation point of view (that is, in S=3D&gt;D direction =
you need=20
  bandwidth B1, while in D=3D&gt;S direction you need bandwidth B2, and =
B1 is=20
  significantly different from B2), but fully symmetrical in all other =
aspects=20
  (i.e. routes, protection capability,=20
  =
etc.)<BR><BR>Thanks,<BR>Igor<BR><BR><B><I>[email-masked]</I></B> =

wrote:
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(16,16,255) 2px solid">Thanks=20
    Martin,<BR><BR>Most applications generate asymmetric (wrt time) =
information=20
    flows in each direction, ie the rate of information flow in each =
direction=20
    is neither constant nor directly proportional to the rate of =
information=20
    flow in the other direction....just think about a voice conversation =
if not=20
    obvious....or even a file transfer.<BR><BR>However, for an =
arbitrarily=20
    meshed network we generally require symmetric routings of traffic =
flows, ie=20
    if one direction passes the nodes a-&gt;b-&gt;c-&gt;d in one =
direction then=20
    the other direction should follow d-&gt;c-&gt;b-&gt;a in both this =
and lower=20
    layer networks (to the duct). Moreover, we usually require (under =
failure=20
    free conditions) that such routings do not change over the lifetime =
of a=20
    traffic flow.......this is particularly important for connections =
(ie co-ps=20
    and co-cs modes), and especially when they are supporting a network =
builder=20
    service (a VPN if you like), which may be a large aggregate of all =
kinds of=20
    end-system application traffic flows, for some other party. Note =
that if we=20
    add nodes/links to a co mode layer network we should not change =
existing=20
    connection routings. This is not always the case with a cl-ps mode =
network,=20
    ie because we do not have connections adding new nodes/links can =
allow=20
    traffic flows to change routing.<BR><BR>Is that more clear now wrt =
what I=20
    meant?<BR><BR>regards, Neil<BR><BR>&gt; -----Original =
Message-----<BR>&gt;=20
    From: Martin Vigoureux [mailto:[email-masked]] =
<BR>&gt;=20
    Sent: 19 April 2007 09:37<BR>&gt; To: Harrison,N,Neil,JCGA1 R;=20
    [email-masked]; <BR>&gt; [email-masked];=20
    [email-masked]; [email-masked]<BR>&gt; Cc: =
[email-masked]<BR>&gt;=20
    Subject: Re: Switching technologies requiring bidirectional <BR>&gt; =

    asymmetric LSPs?<BR>&gt; <BR>&gt; <BR>&gt; Neil,<BR>&gt; <BR>&gt; =
for=20
    clarification purposes, the asymmetry I was referring to <BR>&gt; =
was in=20
    terms of bandwidth not path/route or other TE <BR>&gt; parameter, =
but maybe=20
    I did not catch what you meant by *routings*.<BR>&gt; <BR>&gt;=20
    regards,<BR>&gt; <BR>&gt; martin<BR>&gt; <BR>&gt; =
[email-masked] a=20
    =E9crit :<BR>&gt; &gt; I would caution against the observation that =
because=20
    traffic flows <BR>&gt; &gt; a-&gt;b and b-&gt;a are invariably =
asymmetric=20
    (wrt resource <BR>&gt; consumed at any <BR>&gt; &gt; epoch) their =
*routings*=20
    can also be asymmetric....this does <BR>&gt; not follow <BR>&gt; =
&gt; at=20
    all. This observation applies to all layer networks (any <BR>&gt; =
&gt;=20
    mode/technology).<BR>&gt; &gt; <BR>&gt; &gt; regards, Neil<BR>&gt; =
&gt;=20
    <BR>&gt; &gt;&gt; -----Original Message-----<BR>&gt; &gt;&gt; From:=20
    [email-masked]<BR>&gt; &gt;&gt; =
[mailto:[email-masked]]=20
    On Behalf Of Martin Vigoureux<BR>&gt; &gt;&gt; Sent: 19 April 2007=20
    08:34<BR>&gt; &gt;&gt; To: Attila Takacs (IJ/ETH); Igor Bryskin; =
Adrian=20
    Farrel; Lou Berger<BR>&gt; &gt;&gt; Cc: [email-masked]<BR>&gt; =
&gt;&gt;=20
    Subject: Re: Switching technologies requiring bidirectional <BR>&gt; =

    &gt;&gt; asymmetric LSPs?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;=20
    All,<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; I do believe in the need for=20
    asymmetric bidirectional LSPs.<BR>&gt; &gt;&gt; Traffic is by nature =

    asymmetric (for the vast majority of it <BR>&gt; &gt;&gt; at least). =
We may=20
    argue that the sum of asymmetric traffic <BR>&gt; &gt;&gt; could =
lead to=20
    symmetric traffic or that the above statement <BR>&gt; &gt;&gt; is =
dependent=20
    on the network segment we are considering, but <BR>&gt; &gt;&gt; it =
will=20
    remain true and we should definitely capitalize on <BR>&gt; &gt;&gt; =
CCAMP=20
    prior work by taking benefit from the advantages of <BR>&gt; =
&gt;&gt;=20
    bidirectional LSP setup.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; =
Furthermore, I=20
    believe we should not restrict the work and<BR>&gt; &gt;&gt; =
solution to=20
    Ethernet technology only.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; =
martin<BR>&gt;=20
    &gt;&gt;<BR>&gt; &gt;&gt; Attila Takacs (IJ/ETH) a =E9crit :<BR>&gt; =

    &gt;&gt;&gt; Hi all,<BR>&gt; &gt;&gt;&gt; please see inline =
[at]<BR>&gt;=20
    &gt;&gt;&gt; Regards,<BR>&gt; &gt;&gt;&gt; Attila<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;=20
    =
--------------------------------------------------------------<BR>&gt;=20
    &gt;&gt; ----------<BR>&gt; &gt;&gt;&gt; *From:*=20
    [email-masked]<BR>&gt; &gt;&gt;=20
    [mailto:[email-masked]]<BR>&gt; &gt;&gt;&gt; *On Behalf Of =
*Igor=20
    Bryskin<BR>&gt; &gt;&gt;&gt; *Sent:* Tuesday, April 17, 2007 10:19=20
    PM<BR>&gt; &gt;&gt;&gt; *To:* Adrian Farrel; [email-masked]; Lou =

    Berger<BR>&gt; &gt;&gt;&gt; *Subject:* Re: Switching technologies =
requiring=20
    bidirectional<BR>&gt; &gt;&gt;&gt; asymmetric LSPs?<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Adrian, Lou<BR>&gt; =
&gt;&gt;&gt;<BR>&gt;=20
    &gt;&gt;&gt; Please,see in line.<BR>&gt; &gt;&gt;&gt;<BR>&gt; =
&gt;&gt;&gt;=20
    */Adrian Farrel <[email-masked]>/* wrote:<BR>&gt; =
&gt;&gt;&gt;<BR>&gt;=20
    &gt;&gt;&gt; Hi,<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; I'm a bit =

    surprised that there was no follow-up to Lou's<BR>&gt; &gt;&gt;&gt;=20
    email.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Does silence =
indicate that=20
    this was put to bed in <BR>&gt; Prague and<BR>&gt; &gt;&gt;&gt; =
no-one=20
    is<BR>&gt; &gt;&gt;&gt; interested in these LSPs?<BR>&gt; =
&gt;&gt;&gt;=20
    <BR>&gt; &gt;&gt;&gt; [at] well, as Lou mentioned at least a few of =
us=20
    <BR>&gt; continue an<BR>&gt; &gt;&gt;&gt; offline discussion on the=20
    topic.<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; &gt; So a few of =
us have=20
    been having been discussing the<BR>&gt; &gt;&gt;&gt; asymmetric =
work<BR>&gt;=20
    &gt;&gt;&gt; &gt; presented in Prague and it seems to me we have an=20
    open<BR>&gt; &gt;&gt;&gt; question on<BR>&gt; &gt;&gt;&gt; &gt;=20
    requirements.<BR>&gt; &gt;&gt;&gt; &gt;<BR>&gt; &gt;&gt;&gt; &gt; =
It's clear=20
    that at least one switching <BR>&gt; technology (i.e.,<BR>&gt; =
&gt;&gt;&gt;=20
    ethernet/PBB-TE)<BR>&gt; &gt;&gt;&gt; &gt; requires support for=20
    bidirectional asymmetric LSPs.<BR>&gt; &gt;&gt;&gt;<BR>&gt; =
&gt;&gt;&gt; Is=20
    this clear? I continue to hear talk of service<BR>&gt; &gt;&gt;=20
    requirements,<BR>&gt; &gt;&gt;&gt; but not so<BR>&gt; &gt;&gt;&gt; =
much of=20
    how those services are required to be supported.<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; The benefits I have heard =
are:<BR>&gt;=20
    &gt;&gt;&gt; 1. Fewer control plane messages<BR>&gt; &gt;&gt;&gt; 2. =
Ease of=20
    enforecement of fate-sharing<BR>&gt; &gt;&gt;&gt;<BR>&gt; =
&gt;&gt;&gt;=20
    IB&gt;&gt; Adrian, you enumerated here the benefits of<BR>&gt; =
&gt;&gt;=20
    bidirectional<BR>&gt; &gt;&gt;&gt; LSPs, and BTW you forgot to =
mention the=20
    most <BR>&gt; important one.<BR>&gt; &gt;&gt;&gt; Ethernet OAM is =
designed,=20
    as I understand, on<BR>&gt; &gt;&gt; assumption that<BR>&gt; =
&gt;&gt;&gt;=20
    the trafic takes the same paths in both<BR>&gt; &gt;&gt; directions. =
So, if=20
    we<BR>&gt; &gt;&gt;&gt; want to preserve the Ethernet native OAM =
(which=20
    we<BR>&gt; &gt;&gt; certainly do<BR>&gt; &gt;&gt;&gt; , because this =
is half=20
    of Ethernet functionality)<BR>&gt; &gt;&gt; we must map a<BR>&gt;=20
    &gt;&gt;&gt; bidiretcional service on either a single<BR>&gt; =
&gt;&gt;=20
    bidirectional LSP or<BR>&gt; &gt;&gt;&gt; two unidirectional LSPs =
using the=20
    same path. This<BR>&gt; &gt;&gt; is different<BR>&gt; &gt;&gt;&gt; =
form MPLS=20
    where there are no such OAM requirements.<BR>&gt; &gt;&gt;&gt; Lou =
is=20
    talking about asymetrical bi-directional<BR>&gt; &gt;&gt; LSPs, and=20
    what<BR>&gt; &gt;&gt;&gt; is not clear (at least for me) whether we=20
    need<BR>&gt; &gt;&gt; asymetrical p2p<BR>&gt; &gt;&gt;&gt; Ethernet=20
    services.<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; [at] Adrian's =
points=20
    are related to the single session vs.<BR>&gt; &gt;&gt;&gt; multiple =
session=20
    discussions we had, which is<BR>&gt; &gt;&gt; generally true =
for<BR>&gt;=20
    &gt;&gt;&gt; any bidirectional LSP.<BR>&gt; &gt;&gt;&gt; The=20
    bidirectionality of Ethernet comes basically from two<BR>&gt; =
&gt;&gt;&gt;=20
    aspects imho: (1) in any case, as Igor pointed out,<BR>&gt; &gt;&gt; =
most of=20
    the<BR>&gt; &gt;&gt;&gt; CFM functions will only operate properly if =
there=20
    are<BR>&gt; &gt;&gt;&gt; symmetrical paths. (2) on the other hand, =
if a=20
    <BR>&gt; GMPLS LPS is<BR>&gt; &gt;&gt;&gt; essentially a VLAN within =
which=20
    MAC learning is<BR>&gt; &gt;&gt; operating one<BR>&gt; &gt;&gt;&gt; =
will=20
    need symmetric paths in order the learning functions<BR>&gt; =
&gt;&gt;&gt;=20
    properly.<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; I had the =
impression=20
    that we already converged<BR>&gt; &gt;&gt; before Prague to<BR>&gt;=20
    &gt;&gt;&gt; a single remaining question: do we need the<BR>&gt;=20
    &gt;&gt;&gt;&gt; asymmetric bw&lt;&lt;<BR>&gt; &gt;&gt;&gt; =
extension for a=20
    single session bidirectional LSP. <BR>&gt; There were<BR>&gt; =
&gt;&gt;&gt;=20
    some possible cases for asymmetric bw LSPs <BR>&gt; mentioned by=20
    Don,<BR>&gt; &gt;&gt;&gt; Diego and myself but these seemed not to=20
    convince<BR>&gt; &gt;&gt;&gt; everybody. Imho we should focus on =
this=20
    question <BR>&gt; not to loop<BR>&gt; &gt;&gt;&gt; into the =
discussion we=20
    had already.<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; If we agree =
on that=20
    bidirectional services over<BR>&gt; &gt;&gt; Ethernet need<BR>&gt;=20
    &gt;&gt;&gt; symmetrical paths than we could conclude that <BR>&gt; =
using a=20
    single<BR>&gt; &gt;&gt;&gt; session to setup the bidirectional LSP =
would be=20
    the<BR>&gt; &gt;&gt; preferred<BR>&gt; &gt;&gt;&gt; way at least =
over=20
    Ethernet. In this case, imho it is quite<BR>&gt; &gt;&gt;&gt; =
reasonable to=20
    assume that asymmetrical services<BR>&gt; &gt;&gt; that require =
a<BR>&gt;=20
    &gt;&gt;&gt; dedicated LSP would also use a single signaling =
<BR>&gt;=20
    exchange to<BR>&gt; &gt;&gt;&gt; setup the LSP, hence there would be =
a need=20
    for the<BR>&gt; &gt;&gt; asymmetric bw<BR>&gt; &gt;&gt;&gt; =
extension.=20
    Following this thinking, the question<BR>&gt; &gt;&gt; turns into=20
    the<BR>&gt; &gt;&gt;&gt; aggregation/hierarchy discussion that was =
bought=20
    up<BR>&gt; &gt;&gt; by Dimitri<BR>&gt; &gt;&gt;&gt; earlier. That =
is, do we=20
    have the need of LSPs per<BR>&gt; &gt;&gt; service. My<BR>&gt; =
&gt;&gt;&gt;=20
    two cents: generally not but there are certain<BR>&gt; &gt;&gt; =
services=20
    where it<BR>&gt; &gt;&gt;&gt; is indeed a reasonable assumption, =
e.g., IPTV=20
    or private<BR>&gt; &gt;&gt;&gt; services.<BR>&gt; &gt;&gt;&gt; =
<BR>&gt;=20
    &gt;&gt;&gt; These are significant, but not dramatic, =
requirements.<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; &gt; The question is:<BR>&gt; =
&gt;&gt;&gt;=20
    &gt;<BR>&gt; &gt;&gt;&gt; &gt; Is the *requirement* for =
bidirectional=20
    asymmetric LSPs:<BR>&gt; &gt;&gt;&gt; &gt; (a) a technology specific =

    requirement, or<BR>&gt; &gt;&gt;&gt; &gt; (b) one that is common =
(this is=20
    CCAMP after<BR>&gt; &gt;&gt; all!) to multiple<BR>&gt; &gt;&gt;&gt;=20
    switching<BR>&gt; &gt;&gt;&gt; &gt; technologies?<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; CCAMP deals in transport networks. =
As far=20
    as I can<BR>&gt; &gt;&gt; see the service<BR>&gt; &gt;&gt;&gt; =
requirements=20
    would be pretty much the same all transport<BR>&gt; &gt;&gt;&gt; =
networks=20
    and would<BR>&gt; &gt;&gt;&gt; certainly be applicable to packet, =
L2, and=20
    TDM (the latter<BR>&gt; &gt;&gt;&gt; because TDM will<BR>&gt; =
&gt;&gt;&gt;=20
    be called on to support L2).<BR>&gt; &gt;&gt;&gt;<BR>&gt; =
&gt;&gt;&gt;=20
    IB&gt;&gt; See my comment above: there is a differnce<BR>&gt; =
&gt;&gt;=20
    between MPLS and<BR>&gt; &gt;&gt;&gt; Ethernet services. Also there =
are=20
    certainly<BR>&gt; &gt;&gt; differences between<BR>&gt; &gt;&gt;&gt; =
MPLS and=20
    lambda services (use of the same lambda in both<BR>&gt; &gt;&gt;&gt; =

    directions, for example). So each transport<BR>&gt; &gt;&gt; =
technology may=20
    have<BR>&gt; &gt;&gt;&gt; distinct requirements WRT bidirectional=20
    services<BR>&gt; &gt;&gt; and connections<BR>&gt; &gt;&gt;&gt; on =
which the=20
    services are mapped.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; &gt; =
Please=20
    keep in mind that service requirements <BR>&gt; are not the<BR>&gt;=20
    &gt;&gt;&gt; same thing as<BR>&gt; &gt;&gt;&gt; &gt; switching =
technology=20
    requirements. For example,<BR>&gt; &gt;&gt; we have long<BR>&gt;=20
    &gt;&gt;&gt; built<BR>&gt; &gt;&gt;&gt; &gt; bidirectional =
asymmetric=20
    services on <BR>&gt; unidirectional MPLS<BR>&gt; &gt;&gt;&gt; =
LSPs.<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Well, exactly!<BR>&gt; =
&gt;&gt;&gt;=20
    Perhaps someone can explain why the Ethernet<BR>&gt; &gt;&gt; =
hardware is=20
    forced<BR>&gt; &gt;&gt;&gt; to require<BR>&gt; &gt;&gt;&gt; =
bidirectional=20
    asymmetric LSPs when MPLS is happy without?<BR>&gt; =
&gt;&gt;&gt;<BR>&gt;=20
    &gt;&gt;&gt; IB&gt;&gt; Again, IMO the answer is to be able to use=20
    native<BR>&gt; &gt;&gt;&gt; Ethernet OAM.<BR>&gt; =
&gt;&gt;&gt;<BR>&gt;=20
    &gt;&gt;&gt; Igor<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; &gt; The =
answer=20
    to this question will help determine<BR>&gt; &gt;&gt; if we =
should<BR>&gt;=20
    &gt;&gt;&gt; have a<BR>&gt; &gt;&gt;&gt; &gt; technology specific =
solution=20
    or a generic CCAMP<BR>&gt; &gt;&gt; solution (as<BR>&gt; =
&gt;&gt;&gt; well=20
    as the<BR>&gt; &gt;&gt;&gt; &gt; complexity of the =
solution.)<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; We should not take any action that =

    deliberately <BR>&gt; precludes or<BR>&gt; &gt;&gt;&gt; makes =
more<BR>&gt;=20
    &gt;&gt;&gt; complex the genericisation (is that an American<BR>&gt; =

    &gt;&gt; word?) of the<BR>&gt; &gt;&gt;&gt; solution<BR>&gt; =
&gt;&gt;&gt;=20
    unless there is a significant difference in simplicity of<BR>&gt;=20
    &gt;&gt;&gt; solutions.<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; =
But we=20
    should take no action at all unless there is<BR>&gt; &gt;&gt; some=20
    more<BR>&gt; &gt;&gt;&gt; evidence of<BR>&gt; &gt;&gt;&gt; support =
for this=20
    work!<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; Adrian<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt;<BR>&gt;=20
    &gt;&gt;&gt;<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;=20
    =
--------------------------------------------------------------<BR>&gt;=20
    &gt;&gt; ----------<BR>&gt; &gt;&gt;&gt; Ahhh...imagining that =
irresistible=20
    "new car" smell?<BR>&gt; &gt;&gt;&gt; Check out new cars at Yahoo!=20
    Autos.<BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt; =
<HTTP:=20
    evt=3D"48245/" us.rd.yahoo.com=3D""><BR>&gt; &gt;&gt;=20
    *http://autos.yahoo.com/new_cars.htm<BR>&gt; &gt;&gt; <BR>&gt;=20
    =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN<=
BR>&gt;=20
    &gt;&gt;&gt; hcnM-&gt;<BR>&gt; &gt;&gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;=20
    <BR>&gt; <BR></HTTP:></[email-masked]></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  Ahhh...imagining that irresistible "new car" smell?<BR>Check out <A=20
  =
href=3D"http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new_ca=
rs.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbm=
V3LWNhcnM-">new=20
  cars at Yahoo! Autos.</A> </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C78285.3C1E7972--

Delivery-date: Thu, 19 Apr 2007 12:38:42 +0000
Date: Thu, 19 Apr 2007 05:36:04 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]

--0-1781290107-1176986164=:1234
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Neil,

I consider your input very important to this discussion. 

My question is: Do you see use cases for bidirectional p2p services which are asymmetrical from the bandwidth reservation point of view (that is, in S=>D direction you need bandwidth B1, while in D=>S direction you need bandwidth B2, and B1 is significantly different from B2), but fully symmetrical in all other aspects (i.e. routes, protection capability, etc.)

Thanks,
Igor

[email-masked] wrote: Thanks Martin,

Most applications generate asymmetric (wrt time) information flows in each direction, ie the rate of information flow in each direction is neither constant nor directly proportional to the rate of information flow in the other direction....just think about a voice conversation if not obvious....or even a file transfer.

However, for an arbitrarily meshed network we generally require symmetric routings of traffic flows, ie if one direction passes the nodes a->b->c->d in one direction then the other direction should follow d->c->b->a in both this and lower layer networks (to the duct). Moreover, we usually require (under failure free conditions) that such routings do not change over the lifetime of a traffic flow.......this is particularly important for connections (ie co-ps and co-cs modes), and especially when they are supporting a network builder service (a VPN if you like), which may be a large aggregate of all kinds of end-system application traffic flows, for some other party.  Note that if we add nodes/links to a co mode layer network we should not change existing connection routings.  This is not always the case with a cl-ps mode network, ie because we do not have connections adding new nodes/links can allow traffic flows to change routing.

Is that more clear now wrt what I meant?

regards, Neil

> -----Original Message-----
> From: Martin Vigoureux [mailto:[email-masked]] 
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Switching technologies requiring bidirectional 
> asymmetric LSPs?
> 
> 
> Neil,
> 
> for clarification purposes, the asymmetry I was referring to 
> was in terms of bandwidth not path/route or other TE 
> parameter, but maybe I did not catch what you meant by *routings*.
> 
> regards,
> 
> martin
> 
> [email-masked] a écrit :
> > I would caution against the observation that because traffic flows 
> > a->b and b->a are invariably asymmetric (wrt resource 
> consumed at any 
> > epoch) their *routings* can also be asymmetric....this does 
> not follow 
> > at all.  This observation applies to all layer networks (any 
> > mode/technology).
> > 
> > regards, Neil
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> >> Sent: 19 April 2007 08:34
> >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> Subject: Re: Switching technologies requiring bidirectional 
> >> asymmetric LSPs?
> >>
> >>
> >> All,
> >>
> >> I do believe in the need for asymmetric bidirectional LSPs.
> >> Traffic is by nature asymmetric (for the vast majority of it 
> >> at least). We may argue that the sum of asymmetric traffic 
> >> could lead to symmetric traffic or that the above statement 
> >> is dependent on the network segment we are considering, but 
> >> it will remain true and we should definitely capitalize on 
> >> CCAMP prior work by taking benefit from the advantages of 
> >> bidirectional LSP setup.
> >>
> >> Furthermore, I believe we should not restrict the work and
> >> solution to Ethernet technology only.
> >>
> >> martin
> >>
> >> Attila Takacs (IJ/ETH) a écrit :
> >>> Hi all,
> >>> please see inline [at]
> >>> Regards,
> >>> Attila
> >>>
> >>>     
> >> --------------------------------------------------------------
> >> ----------
> >>>     *From:* [email-masked]
> >> [mailto:[email-masked]]
> >>>     *On Behalf Of *Igor Bryskin
> >>>     *Sent:* Tuesday, April 17, 2007 10:19 PM
> >>>     *To:* Adrian Farrel; [email-masked]; Lou Berger
> >>>     *Subject:* Re: Switching technologies requiring bidirectional
> >>>     asymmetric LSPs?
> >>>
> >>>     Adrian, Lou
> >>>
> >>>     Please,see in line.
> >>>
> >>>     */Adrian Farrel /* wrote:
> >>>
> >>>         Hi,
> >>>
> >>>         I'm a bit surprised that there was no follow-up to Lou's
> >>> email.
> >>>
> >>>         Does silence indicate that this was put to bed in 
> Prague and
> >>>         no-one is
> >>>         interested in these LSPs?
> >>>          
> >>>         [at] well, as Lou mentioned at least a few of us 
> continue an
> >>>         offline discussion on the topic.
> >>>          
> >>>          > So a few of us have been having been discussing the
> >>>         asymmetric work
> >>>          > presented in Prague and it seems to me we have an open
> >>>         question on
> >>>          > requirements.
> >>>          >
> >>>          > It's clear that at least one switching 
> technology (i.e.,
> >>>         ethernet/PBB-TE)
> >>>          > requires support for bidirectional asymmetric LSPs.
> >>>
> >>>         Is this clear? I continue to hear talk of service
> >> requirements,
> >>>         but not so
> >>>         much of how those services are required to be supported.
> >>>
> >>>         The benefits I have heard are:
> >>>         1. Fewer control plane messages
> >>>         2. Ease of enforecement of fate-sharing
> >>>
> >>>         IB>> Adrian, you enumerated here the benefits of
> >> bidirectional
> >>>         LSPs, and BTW you forgot to mention the most 
> important one.
> >>>         Ethernet OAM is designed, as I understand, on
> >> assumption that
> >>>         the trafic  takes the same  paths in both
> >> directions. So, if we
> >>>         want to preserve the Ethernet native OAM (which we
> >> certainly do
> >>>         , because this is half of Ethernet functionality)
> >> we must map a
> >>>         bidiretcional service on either a single
> >> bidirectional LSP or
> >>>         two unidirectional LSPs using the same path. This
> >> is different
> >>>         form MPLS where there are no such OAM requirements.
> >>>         Lou is talking about asymetrical bi-directional
> >> LSPs, and what
> >>>         is not clear (at least for me) whether we need
> >> asymetrical p2p
> >>>         Ethernet services.
> >>>          
> >>>         [at] Adrian's points are related to the single session vs.
> >>>         multiple session discussions we had, which is
> >> generally true for
> >>>         any bidirectional LSP.
> >>>         The bidirectionality of Ethernet comes basically from two
> >>>         aspects imho: (1) in any case, as Igor pointed out,
> >> most of the
> >>>         CFM functions will only operate properly if there are
> >>>         symmetrical paths. (2) on the other hand, if a 
> GMPLS LPS is
> >>>         essentially a VLAN within which MAC learning is
> >> operating one
> >>>         will need symmetric paths in order the learning functions
> >>> properly.
> >>>          
> >>>         I had the impression that we already converged
> >> before Prague to
> >>>         a single remaining question: do we need the
> >>>> asymmetric bw<<
> >>>         extension for a single session bidirectional LSP. 
> There were
> >>>         some possible cases for asymmetric bw LSPs 
> mentioned by Don,
> >>>         Diego and myself but these seemed not to convince
> >>>         everybody. Imho we should focus on this question 
> not to loop
> >>>         into the discussion we had already.
> >>>          
> >>>         If we agree on that bidirectional services over
> >> Ethernet need
> >>>         symmetrical paths than we could conclude that 
> using a single
> >>>         session to setup the bidirectional LSP would be the
> >> preferred
> >>>         way at least over Ethernet. In this case, imho it is quite
> >>>         reasonable to assume that asymmetrical services
> >> that require a
> >>>         dedicated LSP would also use a single signaling 
> exchange to
> >>>         setup the LSP, hence there would be a need for the
> >> asymmetric bw
> >>>         extension. Following this thinking, the question
> >> turns into the
> >>>         aggregation/hierarchy discussion that was bought up
> >> by Dimitri
> >>>         earlier. That is, do we have the need of LSPs per
> >> service. My
> >>>         two cents: generally not but there are certain
> >> services where it
> >>>         is indeed a reasonable assumption, e.g., IPTV or private
> >>> services.
> >>>          
> >>>         These are significant, but not dramatic, requirements.
> >>>
> >>>          > The question is:
> >>>          >
> >>>          > Is the *requirement* for bidirectional asymmetric LSPs:
> >>>          > (a) a technology specific requirement, or
> >>>          > (b) one that is common (this is CCAMP after
> >> all!) to multiple
> >>>         switching
> >>>          > technologies?
> >>>
> >>>         CCAMP deals in transport networks. As far as I can
> >> see the service
> >>>         requirements would be pretty much the same all transport
> >>>         networks and would
> >>>         certainly be applicable to packet, L2, and TDM (the latter
> >>>         because TDM will
> >>>         be called on to support L2).
> >>>
> >>>         IB>> See my comment above: there is a differnce
> >> between MPLS and
> >>>         Ethernet services. Also there are certainly
> >> differences between
> >>>         MPLS and lambda services (use of the same lambda in both
> >>>         directions, for example). So each transport
> >> technology may have
> >>>         distinct requirements WRT bidirectional services
> >> and connections
> >>>         on which the services are mapped.
> >>>
> >>>          > Please keep in mind that service requirements 
> are not the
> >>>         same thing as
> >>>          > switching technology requirements. For example,
> >> we have long
> >>>         built
> >>>          > bidirectional asymmetric services on 
> unidirectional MPLS
> >>> LSPs.
> >>>
> >>>         Well, exactly!
> >>>         Perhaps someone can explain why the Ethernet
> >> hardware is forced
> >>>         to require
> >>>         bidirectional asymmetric LSPs when MPLS is happy without?
> >>>
> >>>         IB>> Again, IMO the answer is to be able to use native
> >>> Ethernet OAM.
> >>>
> >>>         Igor
> >>>
> >>>          > The answer to this question will help determine
> >> if we should
> >>>         have a
> >>>          > technology specific solution or a generic CCAMP
> >> solution (as
> >>>         well as the
> >>>          > complexity of the solution.)
> >>>
> >>>         We should not take any action that deliberately 
> precludes or
> >>>         makes more
> >>>         complex the genericisation (is that an American
> >> word?) of the
> >>>         solution
> >>>         unless there is a significant difference in simplicity of
> >>> solutions.
> >>>
> >>>         But we should take no action at all unless there is
> >> some more
> >>>         evidence of
> >>>         support for this work!
> >>>
> >>>         Adrian
> >>>
> >>>
> >>>
> >>>
> >>>     
> >> --------------------------------------------------------------
> >> ----------
> >>>     Ahhh...imagining that irresistible "new car" smell?
> >>>     Check out new cars at Yahoo! Autos.
> >>>     
> >>>
> >>  
> >> *http://autos.yahoo.com/new_cars.htm
> >> 
> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> >>> hcnM->
> >>>
> >>
> > 
> 

---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.
--0-1781290107-1176986164=:1234
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Neil,<br><br>I consider your input very important to this discussion. <br><br>My question is: Do you see use cases for bidirectional p2p services which are asymmetrical from the bandwidth reservation point of view (that is, in S=&gt;D direction you need bandwidth B1, while in D=&gt;S direction you need bandwidth B2, and B1 is significantly different from B2), but fully symmetrical in all other aspects (i.e. routes, protection capability, etc.)<br><br>Thanks,<br>Igor<br><br><b><i>[email-masked]</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Thanks Martin,<br><br>Most applications generate asymmetric (wrt time) information flows in each direction, ie the rate of information flow in each direction is neither constant nor directly proportional to the rate of information flow in the other direction....just think about a voice conversation if not obvious....or even a file
 transfer.<br><br>However, for an arbitrarily meshed network we generally require symmetric routings of traffic flows, ie if one direction passes the nodes a-&gt;b-&gt;c-&gt;d in one direction then the other direction should follow d-&gt;c-&gt;b-&gt;a in both this and lower layer networks (to the duct). Moreover, we usually require (under failure free conditions) that such routings do not change over the lifetime of a traffic flow.......this is particularly important for connections (ie co-ps and co-cs modes), and especially when they are supporting a network builder service (a VPN if you like), which may be a large aggregate of all kinds of end-system application traffic flows, for some other party.  Note that if we add nodes/links to a co mode layer network we should not change existing connection routings.  This is not always the case with a cl-ps mode network, ie because we do not have connections adding new nodes/links can allow traffic flows to change
 routing.<br><br>Is that more clear now wrt what I meant?<br><br>regards, Neil<br><br>&gt; -----Original Message-----<br>&gt; From: Martin Vigoureux [mailto:[email-masked]] <br>&gt; Sent: 19 April 2007 09:37<br>&gt; To: Harrison,N,Neil,JCGA1 R; [email-masked]; <br>&gt; [email-masked]; [email-masked]; [email-masked]<br>&gt; Cc: [email-masked]<br>&gt; Subject: Re: Switching technologies requiring bidirectional <br>&gt; asymmetric LSPs?<br>&gt; <br>&gt; <br>&gt; Neil,<br>&gt; <br>&gt; for clarification purposes, the asymmetry I was referring to <br>&gt; was in terms of bandwidth not path/route or other TE <br>&gt; parameter, but maybe I did not catch what you meant by *routings*.<br>&gt; <br>&gt; regards,<br>&gt; <br>&gt; martin<br>&gt; <br>&gt; [email-masked] a écrit :<br>&gt; &gt; I would caution against the observation that because traffic flows <br>&gt; &gt; a-&gt;b and b-&gt;a are invariably asymmetric (wrt resource
 <br>&gt; consumed at any <br>&gt; &gt; epoch) their *routings* can also be asymmetric....this does <br>&gt; not follow <br>&gt; &gt; at all.  This observation applies to all layer networks (any <br>&gt; &gt; mode/technology).<br>&gt; &gt; <br>&gt; &gt; regards, Neil<br>&gt; &gt; <br>&gt; &gt;&gt; -----Original Message-----<br>&gt; &gt;&gt; From: [email-masked]<br>&gt; &gt;&gt; [mailto:[email-masked]] On Behalf Of Martin Vigoureux<br>&gt; &gt;&gt; Sent: 19 April 2007 08:34<br>&gt; &gt;&gt; To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger<br>&gt; &gt;&gt; Cc: [email-masked]<br>&gt; &gt;&gt; Subject: Re: Switching technologies requiring bidirectional <br>&gt; &gt;&gt; asymmetric LSPs?<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; All,<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; I do believe in the need for asymmetric bidirectional LSPs.<br>&gt; &gt;&gt; Traffic is by nature asymmetric (for the vast majority of it <br>&gt; &gt;&gt; at
 least). We may argue that the sum of asymmetric traffic <br>&gt; &gt;&gt; could lead to symmetric traffic or that the above statement <br>&gt; &gt;&gt; is dependent on the network segment we are considering, but <br>&gt; &gt;&gt; it will remain true and we should definitely capitalize on <br>&gt; &gt;&gt; CCAMP prior work by taking benefit from the advantages of <br>&gt; &gt;&gt; bidirectional LSP setup.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Furthermore, I believe we should not restrict the work and<br>&gt; &gt;&gt; solution to Ethernet technology only.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; martin<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Attila Takacs (IJ/ETH) a écrit :<br>&gt; &gt;&gt;&gt; Hi all,<br>&gt; &gt;&gt;&gt; please see inline [at]<br>&gt; &gt;&gt;&gt; Regards,<br>&gt; &gt;&gt;&gt; Attila<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;     <br>&gt; &gt;&gt; --------------------------------------------------------------<br>&gt; &gt;&gt; ----------<br>&gt; &gt;&gt;&gt;     *From:*
 [email-masked]<br>&gt; &gt;&gt; [mailto:[email-masked]]<br>&gt; &gt;&gt;&gt;     *On Behalf Of *Igor Bryskin<br>&gt; &gt;&gt;&gt;     *Sent:* Tuesday, April 17, 2007 10:19 PM<br>&gt; &gt;&gt;&gt;     *To:* Adrian Farrel; [email-masked]; Lou Berger<br>&gt; &gt;&gt;&gt;     *Subject:* Re: Switching technologies requiring bidirectional<br>&gt; &gt;&gt;&gt;     asymmetric LSPs?<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;     Adrian, Lou<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;     Please,see in line.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;     */Adrian Farrel <[email-masked]>/* wrote:<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Hi,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         I'm a bit surprised that there was no follow-up to Lou's<br>&gt; &gt;&gt;&gt; email.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Does silence indicate that this was put to bed in <br>&gt; Prague and<br>&gt; &gt;&gt;&gt;         no-one is<br>&gt; &gt;&gt;&gt; 
        interested in these LSPs?<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;         [at] well, as Lou mentioned at least a few of us <br>&gt; continue an<br>&gt; &gt;&gt;&gt;         offline discussion on the topic.<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;          &gt; So a few of us have been having been discussing the<br>&gt; &gt;&gt;&gt;         asymmetric work<br>&gt; &gt;&gt;&gt;          &gt; presented in Prague and it seems to me we have an open<br>&gt; &gt;&gt;&gt;         question on<br>&gt; &gt;&gt;&gt;          &gt; requirements.<br>&gt; &gt;&gt;&gt;          &gt;<br>&gt; &gt;&gt;&gt;          &gt; It's clear that at least one switching <br>&gt; technology (i.e.,<br>&gt; &gt;&gt;&gt;         ethernet/PBB-TE)<br>&gt; &gt;&gt;&gt;          &gt; requires support for bidirectional asymmetric LSPs.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Is this clear? I continue to hear talk of service<br>&gt; &gt;&gt; requirements,<br>&gt;
 &gt;&gt;&gt;         but not so<br>&gt; &gt;&gt;&gt;         much of how those services are required to be supported.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         The benefits I have heard are:<br>&gt; &gt;&gt;&gt;         1. Fewer control plane messages<br>&gt; &gt;&gt;&gt;         2. Ease of enforecement of fate-sharing<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         IB&gt;&gt; Adrian, you enumerated here the benefits of<br>&gt; &gt;&gt; bidirectional<br>&gt; &gt;&gt;&gt;         LSPs, and BTW you forgot to mention the most <br>&gt; important one.<br>&gt; &gt;&gt;&gt;         Ethernet OAM is designed, as I understand, on<br>&gt; &gt;&gt; assumption that<br>&gt; &gt;&gt;&gt;         the trafic  takes the same  paths in both<br>&gt; &gt;&gt; directions. So, if we<br>&gt; &gt;&gt;&gt;         want to preserve the Ethernet native OAM (which we<br>&gt; &gt;&gt; certainly do<br>&gt; &gt;&gt;&gt;         , because this is half of Ethernet functionality)<br>&gt; &gt;&gt;
 we must map a<br>&gt; &gt;&gt;&gt;         bidiretcional service on either a single<br>&gt; &gt;&gt; bidirectional LSP or<br>&gt; &gt;&gt;&gt;         two unidirectional LSPs using the same path. This<br>&gt; &gt;&gt; is different<br>&gt; &gt;&gt;&gt;         form MPLS where there are no such OAM requirements.<br>&gt; &gt;&gt;&gt;         Lou is talking about asymetrical bi-directional<br>&gt; &gt;&gt; LSPs, and what<br>&gt; &gt;&gt;&gt;         is not clear (at least for me) whether we need<br>&gt; &gt;&gt; asymetrical p2p<br>&gt; &gt;&gt;&gt;         Ethernet services.<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;         [at] Adrian's points are related to the single session vs.<br>&gt; &gt;&gt;&gt;         multiple session discussions we had, which is<br>&gt; &gt;&gt; generally true for<br>&gt; &gt;&gt;&gt;         any bidirectional LSP.<br>&gt; &gt;&gt;&gt;         The bidirectionality of Ethernet comes basically from two<br>&gt; &gt;&gt;&gt;         aspects
 imho: (1) in any case, as Igor pointed out,<br>&gt; &gt;&gt; most of the<br>&gt; &gt;&gt;&gt;         CFM functions will only operate properly if there are<br>&gt; &gt;&gt;&gt;         symmetrical paths. (2) on the other hand, if a <br>&gt; GMPLS LPS is<br>&gt; &gt;&gt;&gt;         essentially a VLAN within which MAC learning is<br>&gt; &gt;&gt; operating one<br>&gt; &gt;&gt;&gt;         will need symmetric paths in order the learning functions<br>&gt; &gt;&gt;&gt; properly.<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;         I had the impression that we already converged<br>&gt; &gt;&gt; before Prague to<br>&gt; &gt;&gt;&gt;         a single remaining question: do we need the<br>&gt; &gt;&gt;&gt;&gt; asymmetric bw&lt;&lt;<br>&gt; &gt;&gt;&gt;         extension for a single session bidirectional LSP. <br>&gt; There were<br>&gt; &gt;&gt;&gt;         some possible cases for asymmetric bw LSPs <br>&gt; mentioned by Don,<br>&gt; &gt;&gt;&gt;         Diego and myself
 but these seemed not to convince<br>&gt; &gt;&gt;&gt;         everybody. Imho we should focus on this question <br>&gt; not to loop<br>&gt; &gt;&gt;&gt;         into the discussion we had already.<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;         If we agree on that bidirectional services over<br>&gt; &gt;&gt; Ethernet need<br>&gt; &gt;&gt;&gt;         symmetrical paths than we could conclude that <br>&gt; using a single<br>&gt; &gt;&gt;&gt;         session to setup the bidirectional LSP would be the<br>&gt; &gt;&gt; preferred<br>&gt; &gt;&gt;&gt;         way at least over Ethernet. In this case, imho it is quite<br>&gt; &gt;&gt;&gt;         reasonable to assume that asymmetrical services<br>&gt; &gt;&gt; that require a<br>&gt; &gt;&gt;&gt;         dedicated LSP would also use a single signaling <br>&gt; exchange to<br>&gt; &gt;&gt;&gt;         setup the LSP, hence there would be a need for the<br>&gt; &gt;&gt; asymmetric bw<br>&gt; &gt;&gt;&gt;        
 extension. Following this thinking, the question<br>&gt; &gt;&gt; turns into the<br>&gt; &gt;&gt;&gt;         aggregation/hierarchy discussion that was bought up<br>&gt; &gt;&gt; by Dimitri<br>&gt; &gt;&gt;&gt;         earlier. That is, do we have the need of LSPs per<br>&gt; &gt;&gt; service. My<br>&gt; &gt;&gt;&gt;         two cents: generally not but there are certain<br>&gt; &gt;&gt; services where it<br>&gt; &gt;&gt;&gt;         is indeed a reasonable assumption, e.g., IPTV or private<br>&gt; &gt;&gt;&gt; services.<br>&gt; &gt;&gt;&gt;          <br>&gt; &gt;&gt;&gt;         These are significant, but not dramatic, requirements.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;          &gt; The question is:<br>&gt; &gt;&gt;&gt;          &gt;<br>&gt; &gt;&gt;&gt;          &gt; Is the *requirement* for bidirectional asymmetric LSPs:<br>&gt; &gt;&gt;&gt;          &gt; (a) a technology specific requirement, or<br>&gt; &gt;&gt;&gt;          &gt; (b) one that is common (this is
 CCAMP after<br>&gt; &gt;&gt; all!) to multiple<br>&gt; &gt;&gt;&gt;         switching<br>&gt; &gt;&gt;&gt;          &gt; technologies?<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         CCAMP deals in transport networks. As far as I can<br>&gt; &gt;&gt; see the service<br>&gt; &gt;&gt;&gt;         requirements would be pretty much the same all transport<br>&gt; &gt;&gt;&gt;         networks and would<br>&gt; &gt;&gt;&gt;         certainly be applicable to packet, L2, and TDM (the latter<br>&gt; &gt;&gt;&gt;         because TDM will<br>&gt; &gt;&gt;&gt;         be called on to support L2).<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         IB&gt;&gt; See my comment above: there is a differnce<br>&gt; &gt;&gt; between MPLS and<br>&gt; &gt;&gt;&gt;         Ethernet services. Also there are certainly<br>&gt; &gt;&gt; differences between<br>&gt; &gt;&gt;&gt;         MPLS and lambda services (use of the same lambda in both<br>&gt; &gt;&gt;&gt;         directions, for example). So
 each transport<br>&gt; &gt;&gt; technology may have<br>&gt; &gt;&gt;&gt;         distinct requirements WRT bidirectional services<br>&gt; &gt;&gt; and connections<br>&gt; &gt;&gt;&gt;         on which the services are mapped.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;          &gt; Please keep in mind that service requirements <br>&gt; are not the<br>&gt; &gt;&gt;&gt;         same thing as<br>&gt; &gt;&gt;&gt;          &gt; switching technology requirements. For example,<br>&gt; &gt;&gt; we have long<br>&gt; &gt;&gt;&gt;         built<br>&gt; &gt;&gt;&gt;          &gt; bidirectional asymmetric services on <br>&gt; unidirectional MPLS<br>&gt; &gt;&gt;&gt; LSPs.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Well, exactly!<br>&gt; &gt;&gt;&gt;         Perhaps someone can explain why the Ethernet<br>&gt; &gt;&gt; hardware is forced<br>&gt; &gt;&gt;&gt;         to require<br>&gt; &gt;&gt;&gt;         bidirectional asymmetric LSPs when MPLS is happy without?<br>&gt;
 &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         IB&gt;&gt; Again, IMO the answer is to be able to use native<br>&gt; &gt;&gt;&gt; Ethernet OAM.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Igor<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;          &gt; The answer to this question will help determine<br>&gt; &gt;&gt; if we should<br>&gt; &gt;&gt;&gt;         have a<br>&gt; &gt;&gt;&gt;          &gt; technology specific solution or a generic CCAMP<br>&gt; &gt;&gt; solution (as<br>&gt; &gt;&gt;&gt;         well as the<br>&gt; &gt;&gt;&gt;          &gt; complexity of the solution.)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         We should not take any action that deliberately <br>&gt; precludes or<br>&gt; &gt;&gt;&gt;         makes more<br>&gt; &gt;&gt;&gt;         complex the genericisation (is that an American<br>&gt; &gt;&gt; word?) of the<br>&gt; &gt;&gt;&gt;         solution<br>&gt; &gt;&gt;&gt;         unless there is a significant difference in simplicity of<br>&gt;
 &gt;&gt;&gt; solutions.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         But we should take no action at all unless there is<br>&gt; &gt;&gt; some more<br>&gt; &gt;&gt;&gt;         evidence of<br>&gt; &gt;&gt;&gt;         support for this work!<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;         Adrian<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;     <br>&gt; &gt;&gt; --------------------------------------------------------------<br>&gt; &gt;&gt; ----------<br>&gt; &gt;&gt;&gt;     Ahhh...imagining that irresistible "new car" smell?<br>&gt; &gt;&gt;&gt;     Check out new cars at Yahoo! Autos.<br>&gt; &gt;&gt;&gt;     <br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt; <http: us.rd.yahoo.com="" evt="48245/"> <br>&gt; &gt;&gt; *http://autos.yahoo.com/new_cars.htm<br>&gt; &gt;&gt; <br>&gt; l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN<br>&gt; &gt;&gt;&gt; hcnM-&gt;<br>&gt; &gt;&gt;&gt;<br>&gt;
 &gt;&gt;<br>&gt; &gt; <br>&gt; <br></http:></[email-masked]></blockquote><br><p>&#32;

      <hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>

--0-1781290107-1176986164=:1234--

Delivery-date: Thu, 19 Apr 2007 09:13:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Thu, 19 Apr 2007 10:12:08 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Thanks Martin,

Most applications generate asymmetric (wrt time) information flows in =
each direction, ie the rate of information flow in each direction is =
neither constant nor directly proportional to the rate of information =
flow in the other direction....just think about a voice conversation if =
not obvious....or even a file transfer.

However, for an arbitrarily meshed network we generally require =
symmetric routings of traffic flows, ie if one direction passes the =
nodes a->b->c->d in one direction then the other direction should follow =
d->c->b->a in both this and lower layer networks (to the duct). =
Moreover, we usually require (under failure free conditions) that such =
routings do not change over the lifetime of a traffic flow.......this is =
particularly important for connections (ie co-ps and co-cs modes), and =
especially when they are supporting a network builder service (a VPN if =
you like), which may be a large aggregate of all kinds of end-system =
application traffic flows, for some other party.  Note that if we add =
nodes/links to a co mode layer network we should not change existing =
connection routings.  This is not always the case with a cl-ps mode =
network, ie because we do not have connections adding new nodes/links =
can allow traffic flows to change routing.

Is that more clear now wrt what I meant?

regards, Neil

> -----Original Message-----
> From: Martin Vigoureux [mailto:[email-masked]]=20
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
>=20
> Neil,
>=20
> for clarification purposes, the asymmetry I was referring to=20
> was in terms of bandwidth not path/route or other TE=20
> parameter, but maybe I did not catch what you meant by *routings*.
>=20
> regards,
>=20
> martin
>=20
> [email-masked] a =E9crit :
> > I would caution against the observation that because traffic flows=20
> > a->b and b->a are invariably asymmetric (wrt resource=20
> consumed at any=20
> > epoch) their *routings* can also be asymmetric....this does=20
> not follow=20
> > at all.  This observation applies to all layer networks (any=20
> > mode/technology).
> >=20
> > regards, Neil
> >=20
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> >> Sent: 19 April 2007 08:34
> >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> Subject: Re: Switching technologies requiring bidirectional=20
> >> asymmetric LSPs?
> >>
> >>
> >> All,
> >>
> >> I do believe in the need for asymmetric bidirectional LSPs.
> >> Traffic is by nature asymmetric (for the vast majority of it=20
> >> at least). We may argue that the sum of asymmetric traffic=20
> >> could lead to symmetric traffic or that the above statement=20
> >> is dependent on the network segment we are considering, but=20
> >> it will remain true and we should definitely capitalize on=20
> >> CCAMP prior work by taking benefit from the advantages of=20
> >> bidirectional LSP setup.
> >>
> >> Furthermore, I believe we should not restrict the work and
> >> solution to Ethernet technology only.
> >>
> >> martin
> >>
> >> Attila Takacs (IJ/ETH) a =E9crit :
> >>> Hi all,
> >>> please see inline [at]
> >>> Regards,
> >>> Attila
> >>>
> >>>    =20
> >> --------------------------------------------------------------
> >> ----------
> >>>     *From:* [email-masked]
> >> [mailto:[email-masked]]
> >>>     *On Behalf Of *Igor Bryskin
> >>>     *Sent:* Tuesday, April 17, 2007 10:19 PM
> >>>     *To:* Adrian Farrel; [email-masked]; Lou Berger
> >>>     *Subject:* Re: Switching technologies requiring bidirectional
> >>>     asymmetric LSPs?
> >>>
> >>>     Adrian, Lou
> >>>
> >>>     Please,see in line.
> >>>
> >>>     */Adrian Farrel <[email-masked]>/* wrote:
> >>>
> >>>         Hi,
> >>>
> >>>         I'm a bit surprised that there was no follow-up to Lou's
> >>> email.
> >>>
> >>>         Does silence indicate that this was put to bed in=20
> Prague and
> >>>         no-one is
> >>>         interested in these LSPs?
> >>>         =20
> >>>         [at] well, as Lou mentioned at least a few of us=20
> continue an
> >>>         offline discussion on the topic.
> >>>         =20
> >>>          > So a few of us have been having been discussing the
> >>>         asymmetric work
> >>>          > presented in Prague and it seems to me we have an open
> >>>         question on
> >>>          > requirements.
> >>>          >
> >>>          > It's clear that at least one switching=20
> technology (i.e.,
> >>>         ethernet/PBB-TE)
> >>>          > requires support for bidirectional asymmetric LSPs.
> >>>
> >>>         Is this clear? I continue to hear talk of service
> >> requirements,
> >>>         but not so
> >>>         much of how those services are required to be supported.
> >>>
> >>>         The benefits I have heard are:
> >>>         1. Fewer control plane messages
> >>>         2. Ease of enforecement of fate-sharing
> >>>
> >>>         IB>> Adrian, you enumerated here the benefits of
> >> bidirectional
> >>>         LSPs, and BTW you forgot to mention the most=20
> important one.
> >>>         Ethernet OAM is designed, as I understand, on
> >> assumption that
> >>>         the trafic  takes the same  paths in both
> >> directions. So, if we
> >>>         want to preserve the Ethernet native OAM (which we
> >> certainly do
> >>>         , because this is half of Ethernet functionality)
> >> we must map a
> >>>         bidiretcional service on either a single
> >> bidirectional LSP or
> >>>         two unidirectional LSPs using the same path. This
> >> is different
> >>>         form MPLS where there are no such OAM requirements.
> >>>         Lou is talking about asymetrical bi-directional
> >> LSPs, and what
> >>>         is not clear (at least for me) whether we need
> >> asymetrical p2p
> >>>         Ethernet services.
> >>>         =20
> >>>         [at] Adrian's points are related to the single session vs.
> >>>         multiple session discussions we had, which is
> >> generally true for
> >>>         any bidirectional LSP.
> >>>         The bidirectionality of Ethernet comes basically from two
> >>>         aspects imho: (1) in any case, as Igor pointed out,
> >> most of the
> >>>         CFM functions will only operate properly if there are
> >>>         symmetrical paths. (2) on the other hand, if a=20
> GMPLS LPS is
> >>>         essentially a VLAN within which MAC learning is
> >> operating one
> >>>         will need symmetric paths in order the learning functions
> >>> properly.
> >>>         =20
> >>>         I had the impression that we already converged
> >> before Prague to
> >>>         a single remaining question: do we need the
> >>>> asymmetric bw<<
> >>>         extension for a single session bidirectional LSP.=20
> There were
> >>>         some possible cases for asymmetric bw LSPs=20
> mentioned by Don,
> >>>         Diego and myself but these seemed not to convince
> >>>         everybody. Imho we should focus on this question=20
> not to loop
> >>>         into the discussion we had already.
> >>>         =20
> >>>         If we agree on that bidirectional services over
> >> Ethernet need
> >>>         symmetrical paths than we could conclude that=20
> using a single
> >>>         session to setup the bidirectional LSP would be the
> >> preferred
> >>>         way at least over Ethernet. In this case, imho it is quite
> >>>         reasonable to assume that asymmetrical services
> >> that require a
> >>>         dedicated LSP would also use a single signaling=20
> exchange to
> >>>         setup the LSP, hence there would be a need for the
> >> asymmetric bw
> >>>         extension. Following this thinking, the question
> >> turns into the
> >>>         aggregation/hierarchy discussion that was bought up
> >> by Dimitri
> >>>         earlier. That is, do we have the need of LSPs per
> >> service. My
> >>>         two cents: generally not but there are certain
> >> services where it
> >>>         is indeed a reasonable assumption, e.g., IPTV or private
> >>> services.
> >>>         =20
> >>>         These are significant, but not dramatic, requirements.
> >>>
> >>>          > The question is:
> >>>          >
> >>>          > Is the *requirement* for bidirectional asymmetric LSPs:
> >>>          > (a) a technology specific requirement, or
> >>>          > (b) one that is common (this is CCAMP after
> >> all!) to multiple
> >>>         switching
> >>>          > technologies?
> >>>
> >>>         CCAMP deals in transport networks. As far as I can
> >> see the service
> >>>         requirements would be pretty much the same all transport
> >>>         networks and would
> >>>         certainly be applicable to packet, L2, and TDM (the latter
> >>>         because TDM will
> >>>         be called on to support L2).
> >>>
> >>>         IB>> See my comment above: there is a differnce
> >> between MPLS and
> >>>         Ethernet services. Also there are certainly
> >> differences between
> >>>         MPLS and lambda services (use of the same lambda in both
> >>>         directions, for example). So each transport
> >> technology may have
> >>>         distinct requirements WRT bidirectional services
> >> and connections
> >>>         on which the services are mapped.
> >>>
> >>>          > Please keep in mind that service requirements=20
> are not the
> >>>         same thing as
> >>>          > switching technology requirements. For example,
> >> we have long
> >>>         built
> >>>          > bidirectional asymmetric services on=20
> unidirectional MPLS
> >>> LSPs.
> >>>
> >>>         Well, exactly!
> >>>         Perhaps someone can explain why the Ethernet
> >> hardware is forced
> >>>         to require
> >>>         bidirectional asymmetric LSPs when MPLS is happy without?
> >>>
> >>>         IB>> Again, IMO the answer is to be able to use native
> >>> Ethernet OAM.
> >>>
> >>>         Igor
> >>>
> >>>          > The answer to this question will help determine
> >> if we should
> >>>         have a
> >>>          > technology specific solution or a generic CCAMP
> >> solution (as
> >>>         well as the
> >>>          > complexity of the solution.)
> >>>
> >>>         We should not take any action that deliberately=20
> precludes or
> >>>         makes more
> >>>         complex the genericisation (is that an American
> >> word?) of the
> >>>         solution
> >>>         unless there is a significant difference in simplicity of
> >>> solutions.
> >>>
> >>>         But we should take no action at all unless there is
> >> some more
> >>>         evidence of
> >>>         support for this work!
> >>>
> >>>         Adrian
> >>>
> >>>
> >>>
> >>>
> >>>    =20
> >> --------------------------------------------------------------
> >> ----------
> >>>     Ahhh...imagining that irresistible "new car" smell?
> >>>     Check out new cars at Yahoo! Autos.
> >>>    =20
> >>>
> >> <http://us.rd.yahoo.com/evt=3D48245/>=20
> >> *http://autos.yahoo.com/new_cars.htm
> >>=20
> =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> >>> hcnM->
> >=20
>=20

Delivery-date: Thu, 19 Apr 2007 08:37:48 +0000
Date: Thu, 19 Apr 2007 10:36:34 +0200
From: Martin Vigoureux <[email-masked]>
Organization: ALCATEL-LUCENT - CTO/R&I
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: Switching technologies requiring bidirectional asymmetric LSPs?

Neil,

for clarification purposes, the asymmetry I was referring to
was in terms of bandwidth not path/route or other TE parameter,
but maybe I did not catch what you meant by *routings*.

regards,

martin

[email-masked] a écrit :
> I would caution against the observation that because traffic flows a->b and b->a are invariably asymmetric (wrt resource consumed at any epoch) their *routings* can also be asymmetric....this does not follow at all.  This observation applies to all layer networks (any mode/technology).
> 
> regards, Neil
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
>> Sent: 19 April 2007 08:34
>> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
>> Cc: [email-masked]
>> Subject: Re: Switching technologies requiring bidirectional 
>> asymmetric LSPs?
>>
>>
>> All,
>>
>> I do believe in the need for asymmetric bidirectional LSPs. 
>> Traffic is by nature asymmetric (for the vast majority of it 
>> at least). We may argue that the sum of asymmetric traffic 
>> could lead to symmetric traffic or that the above statement 
>> is dependent on the network segment we are considering, but 
>> it will remain true and we should definitely capitalize on 
>> CCAMP prior work by taking benefit from the advantages of 
>> bidirectional LSP setup.
>>
>> Furthermore, I believe we should not restrict the work and 
>> solution to Ethernet technology only.
>>
>> martin
>>
>> Attila Takacs (IJ/ETH) a écrit :
>>> Hi all,
>>> please see inline [at]
>>> Regards,
>>> Attila
>>>
>>>     
>> --------------------------------------------------------------
>> ----------
>>>     *From:* [email-masked] 
>> [mailto:[email-masked]]
>>>     *On Behalf Of *Igor Bryskin
>>>     *Sent:* Tuesday, April 17, 2007 10:19 PM
>>>     *To:* Adrian Farrel; [email-masked]; Lou Berger
>>>     *Subject:* Re: Switching technologies requiring bidirectional
>>>     asymmetric LSPs?
>>>
>>>     Adrian, Lou
>>>
>>>     Please,see in line.
>>>
>>>     */Adrian Farrel <[email-masked]>/* wrote:
>>>
>>>         Hi,
>>>
>>>         I'm a bit surprised that there was no follow-up to Lou's 
>>> email.
>>>
>>>         Does silence indicate that this was put to bed in Prague and
>>>         no-one is
>>>         interested in these LSPs?
>>>          
>>>         [at] well, as Lou mentioned at least a few of us continue an
>>>         offline discussion on the topic.
>>>          
>>>          > So a few of us have been having been discussing the
>>>         asymmetric work
>>>          > presented in Prague and it seems to me we have an open
>>>         question on
>>>          > requirements.
>>>          >
>>>          > It's clear that at least one switching technology (i.e.,
>>>         ethernet/PBB-TE)
>>>          > requires support for bidirectional asymmetric LSPs.
>>>
>>>         Is this clear? I continue to hear talk of service 
>> requirements,
>>>         but not so
>>>         much of how those services are required to be supported.
>>>
>>>         The benefits I have heard are:
>>>         1. Fewer control plane messages
>>>         2. Ease of enforecement of fate-sharing
>>>
>>>         IB>> Adrian, you enumerated here the benefits of 
>> bidirectional
>>>         LSPs, and BTW you forgot to mention the most important one.
>>>         Ethernet OAM is designed, as I understand, on 
>> assumption that
>>>         the trafic  takes the same  paths in both 
>> directions. So, if we
>>>         want to preserve the Ethernet native OAM (which we 
>> certainly do
>>>         , because this is half of Ethernet functionality) 
>> we must map a
>>>         bidiretcional service on either a single 
>> bidirectional LSP or
>>>         two unidirectional LSPs using the same path. This 
>> is different
>>>         form MPLS where there are no such OAM requirements.
>>>         Lou is talking about asymetrical bi-directional 
>> LSPs, and what
>>>         is not clear (at least for me) whether we need 
>> asymetrical p2p
>>>         Ethernet services.
>>>          
>>>         [at] Adrian's points are related to the single session vs.
>>>         multiple session discussions we had, which is 
>> generally true for
>>>         any bidirectional LSP.
>>>         The bidirectionality of Ethernet comes basically from two
>>>         aspects imho: (1) in any case, as Igor pointed out, 
>> most of the
>>>         CFM functions will only operate properly if there are
>>>         symmetrical paths. (2) on the other hand, if a GMPLS LPS is
>>>         essentially a VLAN within which MAC learning is 
>> operating one
>>>         will need symmetric paths in order the learning functions 
>>> properly.
>>>          
>>>         I had the impression that we already converged 
>> before Prague to
>>>         a single remaining question: do we need the 
>>>> asymmetric bw<<
>>>         extension for a single session bidirectional LSP. There were
>>>         some possible cases for asymmetric bw LSPs mentioned by Don,
>>>         Diego and myself but these seemed not to convince
>>>         everybody. Imho we should focus on this question not to loop
>>>         into the discussion we had already.
>>>          
>>>         If we agree on that bidirectional services over 
>> Ethernet need
>>>         symmetrical paths than we could conclude that using a single
>>>         session to setup the bidirectional LSP would be the 
>> preferred
>>>         way at least over Ethernet. In this case, imho it is quite
>>>         reasonable to assume that asymmetrical services 
>> that require a
>>>         dedicated LSP would also use a single signaling exchange to
>>>         setup the LSP, hence there would be a need for the 
>> asymmetric bw
>>>         extension. Following this thinking, the question 
>> turns into the
>>>         aggregation/hierarchy discussion that was bought up 
>> by Dimitri
>>>         earlier. That is, do we have the need of LSPs per 
>> service. My
>>>         two cents: generally not but there are certain 
>> services where it
>>>         is indeed a reasonable assumption, e.g., IPTV or private 
>>> services.
>>>          
>>>         These are significant, but not dramatic, requirements.
>>>
>>>          > The question is:
>>>          >
>>>          > Is the *requirement* for bidirectional asymmetric LSPs:
>>>          > (a) a technology specific requirement, or
>>>          > (b) one that is common (this is CCAMP after 
>> all!) to multiple
>>>         switching
>>>          > technologies?
>>>
>>>         CCAMP deals in transport networks. As far as I can 
>> see the service
>>>         requirements would be pretty much the same all transport
>>>         networks and would
>>>         certainly be applicable to packet, L2, and TDM (the latter
>>>         because TDM will
>>>         be called on to support L2).
>>>
>>>         IB>> See my comment above: there is a differnce 
>> between MPLS and
>>>         Ethernet services. Also there are certainly 
>> differences between
>>>         MPLS and lambda services (use of the same lambda in both
>>>         directions, for example). So each transport 
>> technology may have
>>>         distinct requirements WRT bidirectional services 
>> and connections
>>>         on which the services are mapped.
>>>
>>>          > Please keep in mind that service requirements are not the
>>>         same thing as
>>>          > switching technology requirements. For example, 
>> we have long
>>>         built
>>>          > bidirectional asymmetric services on unidirectional MPLS 
>>> LSPs.
>>>
>>>         Well, exactly!
>>>         Perhaps someone can explain why the Ethernet 
>> hardware is forced
>>>         to require
>>>         bidirectional asymmetric LSPs when MPLS is happy without?
>>>
>>>         IB>> Again, IMO the answer is to be able to use native 
>>> Ethernet OAM.
>>>
>>>         Igor
>>>
>>>          > The answer to this question will help determine 
>> if we should
>>>         have a
>>>          > technology specific solution or a generic CCAMP 
>> solution (as
>>>         well as the
>>>          > complexity of the solution.)
>>>
>>>         We should not take any action that deliberately precludes or
>>>         makes more
>>>         complex the genericisation (is that an American 
>> word?) of the
>>>         solution
>>>         unless there is a significant difference in simplicity of 
>>> solutions.
>>>
>>>         But we should take no action at all unless there is 
>> some more
>>>         evidence of
>>>         support for this work!
>>>
>>>         Adrian
>>>
>>>
>>>
>>>
>>>     
>> --------------------------------------------------------------
>> ----------
>>>     Ahhh...imagining that irresistible "new car" smell?
>>>     Check out new cars at Yahoo! Autos.
>>>     
>>>
>> <http://us.rd.yahoo.com/evt=48245/> *http://autos.yahoo.com/new_cars.htm
>> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
>>> hcnM->
>>>
>>
> 

Delivery-date: Thu, 19 Apr 2007 08:26:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Thu, 19 Apr 2007 09:25:48 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I would caution against the observation that because traffic flows a->b =
and b->a are invariably asymmetric (wrt resource consumed at any epoch) =
their *routings* can also be asymmetric....this does not follow at all.  =
This observation applies to all layer networks (any mode/technology).

regards, Neil

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: 19 April 2007 08:34
> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> Cc: [email-masked]
> Subject: Re: Switching technologies requiring bidirectional=20
> asymmetric LSPs?
>=20
>=20
> All,
>=20
> I do believe in the need for asymmetric bidirectional LSPs.=20
> Traffic is by nature asymmetric (for the vast majority of it=20
> at least). We may argue that the sum of asymmetric traffic=20
> could lead to symmetric traffic or that the above statement=20
> is dependent on the network segment we are considering, but=20
> it will remain true and we should definitely capitalize on=20
> CCAMP prior work by taking benefit from the advantages of=20
> bidirectional LSP setup.
>=20
> Furthermore, I believe we should not restrict the work and=20
> solution to Ethernet technology only.
>=20
> martin
>=20
> Attila Takacs (IJ/ETH) a =E9crit :
> > Hi all,
> > please see inline [at]
> > Regards,
> > Attila
> >=20
> >    =20
> --------------------------------------------------------------
> ----------
> >     *From:* [email-masked]=20
> [mailto:[email-masked]]
> >     *On Behalf Of *Igor Bryskin
> >     *Sent:* Tuesday, April 17, 2007 10:19 PM
> >     *To:* Adrian Farrel; [email-masked]; Lou Berger
> >     *Subject:* Re: Switching technologies requiring bidirectional
> >     asymmetric LSPs?
> >=20
> >     Adrian, Lou
> >=20
> >     Please,see in line.
> >=20
> >     */Adrian Farrel <[email-masked]>/* wrote:
> >=20
> >         Hi,
> >=20
> >         I'm a bit surprised that there was no follow-up to Lou's=20
> > email.
> >=20
> >         Does silence indicate that this was put to bed in Prague and
> >         no-one is
> >         interested in these LSPs?
> >         =20
> >         [at] well, as Lou mentioned at least a few of us continue an
> >         offline discussion on the topic.
> >         =20
> >          > So a few of us have been having been discussing the
> >         asymmetric work
> >          > presented in Prague and it seems to me we have an open
> >         question on
> >          > requirements.
> >          >
> >          > It's clear that at least one switching technology (i.e.,
> >         ethernet/PBB-TE)
> >          > requires support for bidirectional asymmetric LSPs.
> >=20
> >         Is this clear? I continue to hear talk of service=20
> requirements,
> >         but not so
> >         much of how those services are required to be supported.
> >=20
> >         The benefits I have heard are:
> >         1. Fewer control plane messages
> >         2. Ease of enforecement of fate-sharing
> >=20
> >         IB>> Adrian, you enumerated here the benefits of=20
> bidirectional
> >         LSPs, and BTW you forgot to mention the most important one.
> >         Ethernet OAM is designed, as I understand, on=20
> assumption that
> >         the trafic  takes the same  paths in both=20
> directions. So, if we
> >         want to preserve the Ethernet native OAM (which we=20
> certainly do
> >         , because this is half of Ethernet functionality)=20
> we must map a
> >         bidiretcional service on either a single=20
> bidirectional LSP or
> >         two unidirectional LSPs using the same path. This=20
> is different
> >         form MPLS where there are no such OAM requirements.
> >         Lou is talking about asymetrical bi-directional=20
> LSPs, and what
> >         is not clear (at least for me) whether we need=20
> asymetrical p2p
> >         Ethernet services.
> >         =20
> >         [at] Adrian's points are related to the single session vs.
> >         multiple session discussions we had, which is=20
> generally true for
> >         any bidirectional LSP.
> >         The bidirectionality of Ethernet comes basically from two
> >         aspects imho: (1) in any case, as Igor pointed out,=20
> most of the
> >         CFM functions will only operate properly if there are
> >         symmetrical paths. (2) on the other hand, if a GMPLS LPS is
> >         essentially a VLAN within which MAC learning is=20
> operating one
> >         will need symmetric paths in order the learning functions=20
> > properly.
> >         =20
> >         I had the impression that we already converged=20
> before Prague to
> >         a single remaining question: do we need the=20
> >>asymmetric bw<<
> >         extension for a single session bidirectional LSP. There were
> >         some possible cases for asymmetric bw LSPs mentioned by Don,
> >         Diego and myself but these seemed not to convince
> >         everybody. Imho we should focus on this question not to loop
> >         into the discussion we had already.
> >         =20
> >         If we agree on that bidirectional services over=20
> Ethernet need
> >         symmetrical paths than we could conclude that using a single
> >         session to setup the bidirectional LSP would be the=20
> preferred
> >         way at least over Ethernet. In this case, imho it is quite
> >         reasonable to assume that asymmetrical services=20
> that require a
> >         dedicated LSP would also use a single signaling exchange to
> >         setup the LSP, hence there would be a need for the=20
> asymmetric bw
> >         extension. Following this thinking, the question=20
> turns into the
> >         aggregation/hierarchy discussion that was bought up=20
> by Dimitri
> >         earlier. That is, do we have the need of LSPs per=20
> service. My
> >         two cents: generally not but there are certain=20
> services where it
> >         is indeed a reasonable assumption, e.g., IPTV or private=20
> > services.
> >         =20
> >         These are significant, but not dramatic, requirements.
> >=20
> >          > The question is:
> >          >
> >          > Is the *requirement* for bidirectional asymmetric LSPs:
> >          > (a) a technology specific requirement, or
> >          > (b) one that is common (this is CCAMP after=20
> all!) to multiple
> >         switching
> >          > technologies?
> >=20
> >         CCAMP deals in transport networks. As far as I can=20
> see the service
> >         requirements would be pretty much the same all transport
> >         networks and would
> >         certainly be applicable to packet, L2, and TDM (the latter
> >         because TDM will
> >         be called on to support L2).
> >=20
> >         IB>> See my comment above: there is a differnce=20
> between MPLS and
> >         Ethernet services. Also there are certainly=20
> differences between
> >         MPLS and lambda services (use of the same lambda in both
> >         directions, for example). So each transport=20
> technology may have
> >         distinct requirements WRT bidirectional services=20
> and connections
> >         on which the services are mapped.
> >=20
> >          > Please keep in mind that service requirements are not the
> >         same thing as
> >          > switching technology requirements. For example,=20
> we have long
> >         built
> >          > bidirectional asymmetric services on unidirectional MPLS=20
> > LSPs.
> >=20
> >         Well, exactly!
> >         Perhaps someone can explain why the Ethernet=20
> hardware is forced
> >         to require
> >         bidirectional asymmetric LSPs when MPLS is happy without?
> >=20
> >         IB>> Again, IMO the answer is to be able to use native=20
> > Ethernet OAM.
> >=20
> >         Igor
> >=20
> >          > The answer to this question will help determine=20
> if we should
> >         have a
> >          > technology specific solution or a generic CCAMP=20
> solution (as
> >         well as the
> >          > complexity of the solution.)
> >=20
> >         We should not take any action that deliberately precludes or
> >         makes more
> >         complex the genericisation (is that an American=20
> word?) of the
> >         solution
> >         unless there is a significant difference in simplicity of=20
> > solutions.
> >=20
> >         But we should take no action at all unless there is=20
> some more
> >         evidence of
> >         support for this work!
> >=20
> >         Adrian
> >=20
> >=20
> >=20
> >=20
> >    =20
> --------------------------------------------------------------
> ----------
> >     Ahhh...imagining that irresistible "new car" smell?
> >     Check out new cars at Yahoo! Autos.
> >    =20
> >=20
> <http://us.rd.yahoo.com/evt=3D48245/> =
*http://autos.yahoo.com/new_cars.htm
> >=20
> =
l;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> > hcnM->
> >=20
>=20
>=20

Delivery-date: Thu, 19 Apr 2007 07:36:49 +0000
Date: Thu, 19 Apr 2007 09:33:53 +0200
From: Martin Vigoureux <[email-masked]>
Organization: ALCATEL-LUCENT - CTO/R&I
To: "Attila Takacs (IJ/ETH)" <[email-masked]>, Igor Bryskin <[email-masked]>, Adrian Farrel <[email-masked]>, Lou Berger <[email-masked]>
CC: [email-masked]
Subject: Re: Switching technologies requiring bidirectional asymmetric LSPs?

All,

I do believe in the need for asymmetric bidirectional LSPs.
Traffic is by nature asymmetric (for the vast majority of it at least).
We may argue that the sum of asymmetric traffic could lead to symmetric
traffic or that the above statement is dependent on the network segment
we are considering, but it will remain true and we should definitely
capitalize on CCAMP prior work by taking benefit from the advantages of
bidirectional LSP setup.

Furthermore, I believe we should not restrict the work and solution to
Ethernet technology only.

martin

Attila Takacs (IJ/ETH) a écrit :
> Hi all,
> please see inline [at]
> Regards,
> Attila
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Igor Bryskin
>     *Sent:* Tuesday, April 17, 2007 10:19 PM
>     *To:* Adrian Farrel; [email-masked]; Lou Berger
>     *Subject:* Re: Switching technologies requiring bidirectional
>     asymmetric LSPs?
> 
>     Adrian, Lou
> 
>     Please,see in line.
> 
>     */Adrian Farrel <[email-masked]>/* wrote:
> 
>         Hi,
> 
>         I'm a bit surprised that there was no follow-up to Lou's email.
> 
>         Does silence indicate that this was put to bed in Prague and
>         no-one is
>         interested in these LSPs?
>          
>         [at] well, as Lou mentioned at least a few of us continue an
>         offline discussion on the topic.
>          
>          > So a few of us have been having been discussing the
>         asymmetric work
>          > presented in Prague and it seems to me we have an open
>         question on
>          > requirements.
>          >
>          > It's clear that at least one switching technology (i.e.,
>         ethernet/PBB-TE)
>          > requires support for bidirectional asymmetric LSPs.
> 
>         Is this clear? I continue to hear talk of service requirements,
>         but not so
>         much of how those services are required to be supported.
> 
>         The benefits I have heard are:
>         1. Fewer control plane messages
>         2. Ease of enforecement of fate-sharing
> 
>         IB>> Adrian, you enumerated here the benefits of bidirectional
>         LSPs, and BTW you forgot to mention the most important one.
>         Ethernet OAM is designed, as I understand, on assumption that
>         the trafic  takes the same  paths in both directions. So, if we
>         want to preserve the Ethernet native OAM (which we certainly do
>         , because this is half of Ethernet functionality) we must map a
>         bidiretcional service on either a single bidirectional LSP or
>         two unidirectional LSPs using the same path. This is different
>         form MPLS where there are no such OAM requirements.
>         Lou is talking about asymetrical bi-directional LSPs, and what
>         is not clear (at least for me) whether we need asymetrical p2p
>         Ethernet services.
>          
>         [at] Adrian's points are related to the single session vs.
>         multiple session discussions we had, which is generally true for
>         any bidirectional LSP.
>         The bidirectionality of Ethernet comes basically from two
>         aspects imho: (1) in any case, as Igor pointed out, most of the
>         CFM functions will only operate properly if there are
>         symmetrical paths. (2) on the other hand, if a GMPLS LPS is
>         essentially a VLAN within which MAC learning is operating one
>         will need symmetric paths in order the learning functions properly. 
>          
>         I had the impression that we already converged before Prague to
>         a single remaining question: do we need the >>asymmetric bw<<
>         extension for a single session bidirectional LSP. There were
>         some possible cases for asymmetric bw LSPs mentioned by Don,
>         Diego and myself but these seemed not to convince
>         everybody. Imho we should focus on this question not to loop
>         into the discussion we had already.
>          
>         If we agree on that bidirectional services over Ethernet need
>         symmetrical paths than we could conclude that using a single
>         session to setup the bidirectional LSP would be the preferred
>         way at least over Ethernet. In this case, imho it is quite
>         reasonable to assume that asymmetrical services that require a
>         dedicated LSP would also use a single signaling exchange to
>         setup the LSP, hence there would be a need for the asymmetric bw
>         extension. Following this thinking, the question turns into the
>         aggregation/hierarchy discussion that was bought up by Dimitri
>         earlier. That is, do we have the need of LSPs per service. My
>         two cents: generally not but there are certain services where it
>         is indeed a reasonable assumption, e.g., IPTV or private services. 
>          
>         These are significant, but not dramatic, requirements.
> 
>          > The question is:
>          >
>          > Is the *requirement* for bidirectional asymmetric LSPs:
>          > (a) a technology specific requirement, or
>          > (b) one that is common (this is CCAMP after all!) to multiple
>         switching
>          > technologies?
> 
>         CCAMP deals in transport networks. As far as I can see the service
>         requirements would be pretty much the same all transport
>         networks and would
>         certainly be applicable to packet, L2, and TDM (the latter
>         because TDM will
>         be called on to support L2).
> 
>         IB>> See my comment above: there is a differnce between MPLS and
>         Ethernet services. Also there are certainly differences between
>         MPLS and lambda services (use of the same lambda in both
>         directions, for example). So each transport technology may have
>         distinct requirements WRT bidirectional services and connections
>         on which the services are mapped.
> 
>          > Please keep in mind that service requirements are not the
>         same thing as
>          > switching technology requirements. For example, we have long
>         built
>          > bidirectional asymmetric services on unidirectional MPLS LSPs.
> 
>         Well, exactly!
>         Perhaps someone can explain why the Ethernet hardware is forced
>         to require
>         bidirectional asymmetric LSPs when MPLS is happy without?
> 
>         IB>> Again, IMO the answer is to be able to use native Ethernet OAM.
> 
>         Igor
> 
>          > The answer to this question will help determine if we should
>         have a
>          > technology specific solution or a generic CCAMP solution (as
>         well as the
>          > complexity of the solution.)
> 
>         We should not take any action that deliberately precludes or
>         makes more
>         complex the genericisation (is that an American word?) of the
>         solution
>         unless there is a significant difference in simplicity of solutions.
> 
>         But we should take no action at all unless there is some more
>         evidence of
>         support for this work!
> 
>         Adrian
> 
> 
> 
> 
>     ------------------------------------------------------------------------
>     Ahhh...imagining that irresistible "new car" smell?
>     Check out new cars at Yahoo! Autos.
>     <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->
> 

Delivery-date: Wed, 18 Apr 2007 19:51:42 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-06.txt 
Date: Wed, 18 Apr 2007 15:50:02 -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		: Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-addressing-06.txt
	Pages		: 21
	Date		: 2007-4-18
	
This document clarifies the use of addresses in Generalized
   Multi-Protocol Label Switching (GMPLS) networks. The aim is to
   facilitate better interworking of GMPLS-capable Label Switching
   Routers (LSRs). The document is based on experience gained in
   implementation, interoperability testing, and deployment.

   The document describes how to interpret address and identifier fields
   within GMPLS protocols, and how to choose which addresses to set in
   those fields for specific control plane usage models. It also
   discusses how to handle IPv6 sources and destinations in the MPLS and
   GMPLS Traffic Engineering (TE) Management Information Base (MIB)
   modules.

   This document does not define new procedures of processes.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-addressing-06.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, 18 Apr 2007 09:46:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Wed, 18 Apr 2007 11:44:10 +0200
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Lou Berger" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7819E.1E202CDF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
please see inline [at]
Regards,
Attila

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Igor Bryskin
	Sent: Tuesday, April 17, 2007 10:19 PM
	To: Adrian Farrel; [email-masked]; Lou Berger
	Subject: Re: Switching technologies requiring bidirectional
asymmetric LSPs?
=09
=09
	Adrian, Lou
=09
	Please,see in line.
=09
	Adrian Farrel <[email-masked]> wrote:=20

		Hi,
	=09
		I'm a bit surprised that there was no follow-up to Lou's
email.
	=09
		Does silence indicate that this was put to bed in Prague
and no-one is=20
		interested in these LSPs?
		=20
		[at] well, as Lou mentioned at least a few of us
continue an offline discussion on the topic.
		=20
		> So a few of us have been having been discussing the
asymmetric work=20
		> presented in Prague and it seems to me we have an open
question on=20
		> requirements.
		>
		> It's clear that at least one switching technology
(i.e., ethernet/PBB-TE)=20
		> requires support for bidirectional asymmetric LSPs.
	=09
		Is this clear? I continue to hear talk of service
requirements, but not so=20
		much of how those services are required to be supported.
	=09
		The benefits I have heard are:
		1. Fewer control plane messages
		2. Ease of enforecement of fate-sharing
	=09
		IB>> Adrian, you enumerated here the benefits of
bidirectional LSPs, and BTW you forgot to mention the most important
one. Ethernet OAM is designed, as I understand, on assumption that the
trafic  takes the same  paths in both directions. So, if we want to
preserve the Ethernet native OAM (which we certainly do , because this
is half of Ethernet functionality) we must map a bidiretcional service
on either a single bidirectional LSP or two unidirectional LSPs using
the same path. This is different form MPLS where there are no such OAM
requirements.
		Lou is talking about asymetrical bi-directional LSPs,
and what is not clear (at least for me) whether we need asymetrical p2p
Ethernet services.
		=20
		[at] Adrian's points are related to the single session
vs. multiple session discussions we had, which is generally true for any
bidirectional LSP.
		The bidirectionality of Ethernet comes basically from
two aspects imho: (1) in any case, as Igor pointed out, most of the CFM
functions will only operate properly if there are symmetrical paths. (2)
on the other hand, if a GMPLS LPS is essentially a VLAN within which MAC
learning is operating one will need symmetric paths in order the
learning functions properly.=20
		=20
		I had the impression that we already converged before
Prague to a single remaining question: do we need the >>asymmetric bw<<
extension for a single session bidirectional LSP. There were some
possible cases for asymmetric bw LSPs mentioned by Don, Diego and myself
but these seemed not to convince everybody. Imho we should focus on this
question not to loop into the discussion we had already.=20
		=20
		If we agree on that bidirectional services over Ethernet
need symmetrical paths than we could conclude that using a single
session to setup the bidirectional LSP would be the preferred way at
least over Ethernet. In this case, imho it is quite reasonable to assume
that asymmetrical services that require a dedicated LSP would also use a
single signaling exchange to setup the LSP, hence there would be a need
for the asymmetric bw extension. Following this thinking, the question
turns into the aggregation/hierarchy discussion that was bought up by
Dimitri earlier. That is, do we have the need of LSPs per service. My
two cents: generally not but there are certain services where it is
indeed a reasonable assumption, e.g., IPTV or private services.=20
		=20
		These are significant, but not dramatic, requirements.
	=09
		> The question is:
		>
		> Is the *requirement* for bidirectional asymmetric
LSPs:
		> (a) a technology specific requirement, or
		> (b) one that is common (this is CCAMP after all!) to
multiple switching=20
		> technologies?
	=09
		CCAMP deals in transport networks. As far as I can see
the service=20
		requirements would be pretty much the same all transport
networks and would=20
		certainly be applicable to packet, L2, and TDM (the
latter because TDM will=20
		be called on to support L2).
	=09
		IB>> See my comment above: there is a differnce between
MPLS and Ethernet services. Also there are certainly differences between
MPLS and lambda services (use of the same lambda in both directions, for
example). So each transport technology may have distinct requirements
WRT bidirectional services and connections on which the services are
mapped.
	=09
		> Please keep in mind that service requirements are not
the same thing as=20
		> switching technology requirements. For example, we
have long built=20
		> bidirectional asymmetric services on unidirectional
MPLS LSPs.
	=09
		Well, exactly!
		Perhaps someone can explain why the Ethernet hardware is
forced to require=20
		bidirectional asymmetric LSPs when MPLS is happy
without?
	=09
		IB>> Again, IMO the answer is to be able to use native
Ethernet OAM.
	=09
		Igor
	=09
		> The answer to this question will help determine if we
should have a=20
		> technology specific solution or a generic CCAMP
solution (as well as the=20
		> complexity of the solution.)
	=09
		We should not take any action that deliberately
precludes or makes more=20
		complex the genericisation (is that an American word?)
of the solution=20
		unless there is a significant difference in simplicity
of solutions.
	=09
		But we should take no action at all unless there is some
more evidence of=20
		support for this work!
	=09
		Adrian=20
	=09
	=09
	=09
	=09

=09
________________________________

	Ahhh...imagining that irresistible "new car" smell?
	Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new_cars.html=
;
_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcn=
M
-> =20

------_=_NextPart_001_01C7819E.1E202CDF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff =
size=3D2>please=20
see inline [at]</FONT></SPAN></DIV>
<DIV><SPAN class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff =

size=3D2>Attila</FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Igor=20
  Bryskin<BR><B>Sent:</B> Tuesday, April 17, 2007 10:19 PM<BR><B>To:</B> =
Adrian=20
  Farrel; [email-masked]; Lou Berger<BR><B>Subject:</B> Re: =
Switching=20
  technologies requiring bidirectional asymmetric =
LSPs?<BR></FONT><BR></DIV>
  <DIV></DIV>Adrian, Lou<BR><BR>Please,see in line.<BR><BR><B><I>Adrian =
Farrel=20
  &lt;[email-masked]&gt;</I></B> wrote:
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(16,16,255) 2px solid">
    <DIV>Hi,<BR><BR>I'm a bit surprised that there was no follow-up to =
Lou's=20
    email.<BR><BR>Does silence indicate that this was put to bed in =
Prague and=20
    no-one is <BR>interested in these LSPs?<BR><SPAN=20
    class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff=20
    size=3D2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>[at] well, as Lou mentioned at least a few of us continue =
an offline=20
    discussion on the topic.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007>&nbsp;</SPAN><BR>&gt; So a few =
of us=20
    have been having been discussing the asymmetric work <BR>&gt; =
presented in=20
    Prague and it seems to me we have an open question on <BR>&gt;=20
    requirements.<BR>&gt;<BR>&gt; It's clear that at least one switching =

    technology (i.e., ethernet/PBB-TE) <BR>&gt; requires support for=20
    bidirectional asymmetric LSPs.<BR><BR>Is this clear? I continue to =
hear talk=20
    of service requirements, but not so <BR>much of how those services =
are=20
    required to be supported.<BR><BR>The benefits I have heard =
are:<BR>1. Fewer=20
    control plane messages<BR>2. Ease of enforecement of=20
    fate-sharing<BR><BR>IB&gt;&gt; Adrian, you enumerated here the =
benefits of=20
    bidirectional LSPs, and BTW you forgot to mention the most important =
one.=20
    Ethernet OAM is designed, as I understand, on assumption that the=20
    trafic&nbsp; takes the same&nbsp; paths in both directions. So, if =
we want=20
    to preserve the Ethernet native OAM (which we certainly do , because =
this is=20
    half of Ethernet functionality) we must map a bidiretcional service =
on=20
    either a single bidirectional LSP or two unidirectional LSPs using =
the same=20
    path. This is different form MPLS where there are no such OAM=20
    requirements.<BR>Lou is talking about asymetrical bi-directional =
LSPs, and=20
    what is not clear (at least for me) whether we need asymetrical p2p =
Ethernet=20
    services.<BR><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>[at] Adrian's points are related to&nbsp;the single session =
vs.=20
    multiple session discussions we had, which is generally true for any =

    bidirectional LSP.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>The bidirectionality of Ethernet comes basically from two =
aspects=20
    imho: (1) in any case, as Igor pointed out, most of the CFM =
functions will=20
    only operate properly if there are symmetrical paths. (2)&nbsp;on =
the other=20
    hand,&nbsp;if a GMPLS LPS is essentially a VLAN within which MAC =
learning is=20
    operating one will need symmetric paths in order the learning =
functions=20
    properly.</FONT></SPAN><SPAN =
class=3D457423008-18042007>&nbsp;</SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007></SPAN><SPAN=20
    class=3D457423008-18042007><FONT face=3DArial color=3D#0000ff=20
    size=3D2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
    had the impression that we already converged before Prague to a =
single=20
    remaining question: do we need the &gt;&gt;asymmetric bw&lt;&lt;=20
    extension&nbsp;for a single session&nbsp;bidirectional =
LSP.&nbsp;There were=20
    some possible cases for asymmetric bw LSPs&nbsp;mentioned by Don, =
Diego and=20
    myself but these seemed not to convince everybody.&nbsp;Imho we =
should focus=20
    on this question not to loop into&nbsp;the discussion we had =
already.=20
    </FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D457423008-18042007><FONT face=3DArial =
color=3D#0000ff size=3D2>If=20
    we agree on that bidirectional services over Ethernet need =
symmetrical paths=20
    than we could conclude that using a single session to setup the=20
    bidirectional LSP would be the preferred way at least over Ethernet. =
In this=20
    case, imho it is quite reasonable to assume that asymmetrical =
services that=20
    require a dedicated LSP would also use a single signaling exchange =
to setup=20
    the LSP, hence there would be a need for the asymmetric bw =
extension.=20
    Following this thinking, the question turns into the=20
    aggregation/hierarchy&nbsp;discussion that was bought up by Dimitri =
earlier.=20
    That is, do we have the need&nbsp;of LSPs per service. My two=20
    cents:&nbsp;generally not but there are certain services where it is =
indeed=20
    a reasonable assumption, e.g., IPTV or private=20
    services.&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D457423008-18042007></SPAN><SPAN=20
    class=3D457423008-18042007></SPAN><SPAN =
class=3D457423008-18042007></SPAN><SPAN=20
    class=3D457423008-18042007></SPAN><SPAN=20
    class=3D457423008-18042007>&nbsp;</SPAN><BR>These are significant, =
but not=20
    dramatic, requirements.<BR><BR>&gt; The question is:<BR>&gt;<BR>&gt; =
Is the=20
    *requirement* for bidirectional asymmetric LSPs:<BR>&gt; (a) a =
technology=20
    specific requirement, or<BR>&gt; (b) one that is common (this is =
CCAMP after=20
    all!) to multiple switching <BR>&gt; technologies?<BR><BR>CCAMP =
deals in=20
    transport networks. As far as I can see the service <BR>requirements =
would=20
    be pretty much the same all transport networks and would =
<BR>certainly be=20
    applicable to packet, L2, and TDM (the latter because TDM will =
<BR>be called=20
    on to support L2).<BR><BR>IB&gt;&gt; See my comment above: there is =
a=20
    differnce between MPLS and Ethernet services. Also there are =
certainly=20
    differences between MPLS and lambda services (use of the same lambda =
in both=20
    directions, for example). So each transport technology may have =
distinct=20
    requirements WRT bidirectional services and connections on which the =

    services are mapped.<BR><BR>&gt; Please keep in mind that service=20
    requirements are not the same thing as <BR>&gt; switching technology =

    requirements. For example, we have long built <BR>&gt; bidirectional =

    asymmetric services on unidirectional MPLS LSPs.<BR><BR>Well,=20
    exactly!<BR>Perhaps someone can explain why the Ethernet hardware is =
forced=20
    to require <BR>bidirectional asymmetric LSPs when MPLS is happy=20
    without?<BR><BR>IB&gt;&gt; Again, IMO the answer is to be able to =
use native=20
    Ethernet OAM.<BR><BR>Igor<BR><BR>&gt; The answer to this question =
will help=20
    determine if we should have a <BR>&gt; technology specific solution =
or a=20
    generic CCAMP solution (as well as the <BR>&gt; complexity of the=20
    solution.)<BR><BR>We should not take any action that deliberately =
precludes=20
    or makes more <BR>complex the genericisation (is that an American =
word?) of=20
    the solution <BR>unless there is a significant difference in =
simplicity of=20
    solutions.<BR><BR>But we should take no action at all unless there =
is some=20
    more evidence of <BR>support for this work!<BR><BR>Adrian=20
    <BR><BR><BR><BR></DIV></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  Ahhh...imagining that irresistible "new car" smell?<BR>Check out <A=20
  =
href=3D"http://us.rd.yahoo.com/evt=3D48245/*http://autos.yahoo.com/new_ca=
rs.html;_ylc=3DX3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbm=
V3LWNhcnM-">new=20
  cars at Yahoo! Autos.</A> </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C7819E.1E202CDF--

Delivery-date: Tue, 17 Apr 2007 20:20:32 +0000
Date: Tue, 17 Apr 2007 13:18:35 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Switching technologies requiring bidirectional asymmetric LSPs?
To: Adrian Farrel <[email-masked]>, [email-masked], Lou Berger <[email-masked]>

--0-1322826229-1176841115=:35725
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian, Lou

Please,see in line.

Adrian Farrel <[email-masked]> wrote: Hi,

I'm a bit surprised that there was no follow-up to Lou's email.

Does silence indicate that this was put to bed in Prague and no-one is 
interested in these LSPs?

> So a few of us have been having been discussing the asymmetric work 
> presented in Prague and it seems to me we have an open question on 
> requirements.
>
> It's clear that at least one switching technology (i.e., ethernet/PBB-TE) 
> requires support for bidirectional asymmetric LSPs.

Is this clear? I continue to hear talk of service requirements, but not so 
much of how those services are required to be supported.

The benefits I have heard are:
1. Fewer control plane messages
2. Ease of enforecement of fate-sharing

IB>> Adrian, you enumerated here the benefits of bidirectional LSPs, and BTW you forgot to mention the most important one. Ethernet OAM is designed, as I understand, on assumption that the trafic  takes the same  paths in both directions. So, if we want to preserve the Ethernet native OAM (which we certainly do , because this is half of Ethernet functionality) we must map a bidiretcional service on either a single bidirectional LSP or two unidirectional LSPs using the same path. This is different form MPLS where there are no such OAM requirements.
Lou is talking about asymetrical bi-directional LSPs, and what is not clear (at least for me) whether we need asymetrical p2p Ethernet services.

These are significant, but not dramatic, requirements.

> The question is:
>
> Is the *requirement* for bidirectional asymmetric LSPs:
> (a) a technology specific requirement, or
> (b) one that is common (this is CCAMP after all!) to multiple switching 
> technologies?

CCAMP deals in transport networks. As far as I can see the service 
requirements would be pretty much the same all transport networks and would 
certainly be applicable to packet, L2, and TDM (the latter because TDM will 
be called on to support L2).

IB>> See my comment above: there is a differnce between MPLS and Ethernet services. Also there are certainly differences between MPLS and lambda services (use of the same lambda in both directions, for example). So each transport technology may have distinct requirements WRT bidirectional services and connections on which the services are mapped.

> Please keep in mind that service requirements are not the same thing as 
> switching technology requirements.  For example, we have long built 
> bidirectional asymmetric services on unidirectional MPLS LSPs.

Well, exactly!
Perhaps someone can explain why the Ethernet hardware is forced to require 
bidirectional asymmetric LSPs when MPLS is happy without?

IB>> Again, IMO the answer is to be able to use native Ethernet OAM.

Igor

> The answer to this question will help determine if we should have a 
> technology specific solution or a generic CCAMP solution (as well as the 
> complexity of the solution.)

We should not take any action that deliberately precludes or makes more 
complex the genericisation (is that an American word?) of the solution 
unless there is a significant difference in simplicity of solutions.

But we should take no action at all unless there is some more evidence of 
support for this work!

Adrian 

---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.
--0-1322826229-1176841115=:35725
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian, Lou<br><br>Please,see in line.<br><br><b><i>Adrian Farrel &lt;[email-masked]&gt;</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Hi,<br><br>I'm a bit surprised that there was no follow-up to Lou's email.<br><br>Does silence indicate that this was put to bed in Prague and no-one is <br>interested in these LSPs?<br><br>&gt; So a few of us have been having been discussing the asymmetric work <br>&gt; presented in Prague and it seems to me we have an open question on <br>&gt; requirements.<br>&gt;<br>&gt; It's clear that at least one switching technology (i.e., ethernet/PBB-TE) <br>&gt; requires support for bidirectional asymmetric LSPs.<br><br>Is this clear? I continue to hear talk of service requirements, but not so <br>much of how those services are required to be supported.<br><br>The benefits I have heard are:<br>1. Fewer control plane messages<br>2. Ease of enforecement of
 fate-sharing<br><br>IB&gt;&gt; Adrian, you enumerated here the benefits of bidirectional LSPs, and BTW you forgot to mention the most important one. Ethernet OAM is designed, as I understand, on assumption that the trafic&nbsp; takes the same&nbsp; paths in both directions. So, if we want to preserve the Ethernet native OAM (which we certainly do , because this is half of Ethernet functionality) we must map a bidiretcional service on either a single bidirectional LSP or two unidirectional LSPs using the same path. This is different form MPLS where there are no such OAM requirements.<br>Lou is talking about asymetrical bi-directional LSPs, and what is not clear (at least for me) whether we need asymetrical p2p Ethernet services.<br><br>These are significant, but not dramatic, requirements.<br><br>&gt; The question is:<br>&gt;<br>&gt; Is the *requirement* for bidirectional asymmetric LSPs:<br>&gt; (a) a technology specific requirement, or<br>&gt; (b) one that is common (this
 is CCAMP after all!) to multiple switching <br>&gt; technologies?<br><br>CCAMP deals in transport networks. As far as I can see the service <br>requirements would be pretty much the same all transport networks and would <br>certainly be applicable to packet, L2, and TDM (the latter because TDM will <br>be called on to support L2).<br><br>IB&gt;&gt; See my comment above: there is a differnce between MPLS and Ethernet services. Also there are certainly differences between MPLS and lambda services (use of the same lambda in both directions, for example). So each transport technology may have distinct requirements WRT bidirectional services and connections on which the services are mapped.<br><br>&gt; Please keep in mind that service requirements are not the same thing as <br>&gt; switching technology requirements.  For example, we have long built <br>&gt; bidirectional asymmetric services on unidirectional MPLS LSPs.<br><br>Well, exactly!<br>Perhaps someone can explain why
 the Ethernet hardware is forced to require <br>bidirectional asymmetric LSPs when MPLS is happy without?<br><br>IB&gt;&gt; Again, IMO the answer is to be able to use native Ethernet OAM.<br><br>Igor<br><br>&gt; The answer to this question will help determine if we should have a <br>&gt; technology specific solution or a generic CCAMP solution (as well as the <br>&gt; complexity of the solution.)<br><br>We should not take any action that deliberately precludes or makes more <br>complex the genericisation (is that an American word?) of the solution <br>unless there is a significant difference in simplicity of solutions.<br><br>But we should take no action at all unless there is some more evidence of <br>support for this work!<br><br>Adrian <br><br><br><br></blockquote><br><p>&#32;

      <hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>

--0-1322826229-1176841115=:35725--

Delivery-date: Tue, 17 Apr 2007 13:52:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Tue, 17 Apr 2007 09:49:30 -0400
From: "Don Fedyk" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Lou Berger" <[email-masked]>

Hi Adrian

Lou stated:=20
> > Please keep in mind that service requirements are not the=20
> > same thing as switching technology requirements.  For=20
> > example, we have long built  bidirectional asymmetric=20
> > services on unidirectional MPLS LSPs.
>=20
And Adrian asked:=20
> Well, exactly!
> Perhaps someone can explain why the Ethernet hardware is=20
> forced to require bidirectional asymmetric LSPs when MPLS=20
> is happy without?

A clarification. I assume you are asking why Ethernet hardware is
bidirectional?  Hardware is agnostic to the asymmetric BW aspects above
as far as I know.=20

Why bidirectional? In the case of Ethernet, Ethernet Bridging Hardware
uses Bidirectional Relays, symmetric spanning trees and optionally
learning (learning requires symmetry and is built into the relay
function).=20

We could debate the origins of this etc. But that is not what we are
chartered to do. We should not be asking "How do we change the
technology to fit GMPLS?".   =20

Regards,
Don=20

Delivery-date: Tue, 17 Apr 2007 08:43:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Lou Berger" <[email-masked]>
Subject: Re: Switching technologies requiring bidirectional asymmetric LSPs?
Date: Mon, 16 Apr 2007 17:06:22 +0100
Organization: Old Dog Consulting

Hi,

I'm a bit surprised that there was no follow-up to Lou's email.

Does silence indicate that this was put to bed in Prague and no-one is 
interested in these LSPs?

> So a few of us have been having been discussing the asymmetric work 
> presented in Prague and it seems to me we have an open question on 
> requirements.
>
> It's clear that at least one switching technology (i.e., ethernet/PBB-TE) 
> requires support for bidirectional asymmetric LSPs.

Is this clear? I continue to hear talk of service requirements, but not so 
much of how those services are required to be supported.

The benefits I have heard are:
1. Fewer control plane messages
2. Ease of enforecement of fate-sharing

These are significant, but not dramatic, requirements.

> The question is:
>
> Is the *requirement* for bidirectional asymmetric LSPs:
> (a) a technology specific requirement, or
> (b) one that is common (this is CCAMP after all!) to multiple switching 
> technologies?

CCAMP deals in transport networks. As far as I can see the service 
requirements would be pretty much the same all transport networks and would 
certainly be applicable to packet, L2, and TDM (the latter because TDM will 
be called on to support L2).

> Please keep in mind that service requirements are not the same thing as 
> switching technology requirements.  For example, we have long built 
> bidirectional asymmetric services on unidirectional MPLS LSPs.

Well, exactly!
Perhaps someone can explain why the Ethernet hardware is forced to require 
bidirectional asymmetric LSPs when MPLS is happy without?

> The answer to this question will help determine if we should have a 
> technology specific solution or a generic CCAMP solution (as well as the 
> complexity of the solution.)

We should not take any action that deliberately precludes or makes more 
complex the genericisation (is that an American word?) of the solution 
unless there is a significant difference in simplicity of solutions.

But we should take no action at all unless there is some more evidence of 
support for this work!

Adrian 

Delivery-date: Wed, 11 Apr 2007 14:59:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Heads up : RSVP Error Codes
Date: Wed, 11 Apr 2007 15:19:14 +0100
Organization: Old Dog Consulting

Hi,

You may be interested in this I-D that extends the availability of RSVP 
error codes.

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 09, 2007 8:50 PM
Subject: I-D ACTION:draft-ietf-tsvwg-rsvp-user-error-spec-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Area Working Group Working 
> Group of the IETF.
>
> Title : User Defined Errors for RSVP
> Author(s) : G. Swallow, A. Farrel
> Filename : draft-ietf-tsvwg-rsvp-user-error-spec-00.txt
> Pages : 10
> Date : 2007-4-9
>
>   The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
>   for communicating errors.  That object has a defined format that
>   permits the definition of 256 error codes.  As RSVP has been
>   developed and extended, the convention has been to be conservative in
>   defining new error codes.  Further, no provision for user defined
>   errors exists in RSVP.
>
> This document defines a new RSVP object to permit user defined error
>   values to be communicated.

Delivery-date: Wed, 11 Apr 2007 14:17:41 +0000
Content-class: urn:content-classes:message
Subject: FW: [mpls] Call and Connections
Date: Wed, 11 Apr 2007 09:14:26 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>
Cc: "Anergy Virt" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77C43.B6AA06F8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Redirected from mpls list-
=20
An,
It would be helpful if you add some clarification e.g. are the VC-4
connections using VCAT? As this work is still on-going, you may want to
look at:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.tx
t
Deborah

________________________________

From: Anergy Virt [mailto:[email-masked]]=20
Sent: Wednesday, April 11, 2007 9:51 AM
To: [email-masked]
Subject: [mpls] Call and Connections

Hi

Can anybody explain why the call identifiers for multiple VC4
connections differ with each other when creating an end to end
connection.
For example=20

A ----(UNI)--- B =3D=3D=3D=3D=3D=3D C =3D=3D=3D=3D=3D=3DD =
------(UNI)-----E

In order to support the bandwidth demand in NNI layer 2 parallel VC4
connections are created between B-C and C-D. The connection between two
NNI nodes like B-C differ in their call id. Shouldn't they carry same
call identifier? Is it a bug in implementation of vendors?=20

cheers
an=20

------_=_NextPart_001_01C77C43.B6AA06F8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007>Redirected from mpls =
list-</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007>An,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007>It would be helpful if you add some =
clarification e.g.=20
are the VC-4 connections using VCAT? As this work is still on-going, you =
may=20
want to look at:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lca=
s-02.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-vcat-l=
cas-02.txt</A></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D517040114-11042007>Deborah</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Anergy Virt=20
[mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, April 11, =
2007 9:51=20
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> [mpls] Call and=20
Connections<BR></FONT><BR></DIV>
<DIV></DIV>Hi<BR><BR>Can anybody explain why the call identifiers for =
multiple=20
VC4 connections differ with each other when creating an end to end=20
connection.<BR>For example <BR><BR>A ----(UNI)--- B =3D=3D=3D=3D=3D=3D C =
=3D=3D=3D=3D=3D=3DD=20
------(UNI)-----E<BR><BR>In order to support the bandwidth demand in NNI =
layer 2=20
parallel VC4 connections are created between B-C and C-D. The connection =
between=20
two NNI nodes like B-C differ in their call id. Shouldn't they carry =
same call=20
identifier? Is it a bug in implementation of vendors? =
<BR><BR><BR>cheers<BR>an=20
</BODY></HTML>

------_=_NextPart_001_01C77C43.B6AA06F8--

Envelope-to: [email-masked]
Delivery-date: Wed, 11 Apr 2007 13:18:34 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>
Subject: Protocol Action: 'Generalized MPLS (GMPLS) RSVP-TE  Signaling Extensions in support of Calls' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Wed, 11 Apr 2007 09:16:08 -0400

The IESG has approved the following document:

- 'Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of 
   Calls '
   <draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt> as a Proposed Standard

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

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

Technical Summary
 
   In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   This creates a building block that is useful for other CCAMP
   efforts (GMPLS support for VCAT, GMPLS control of MS-SPRing,
   ASON, ... -- see PROTO writeup). 
 
Working Group Summary
 
   No dissent reported. Some have questioned whether this was needed, 
   but the need is becoming clearer as other CCAMP work progresses. 
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG. There is at least one 
   implementation. Also, the document has been updated based on 
   Security Directorate comments by Magnus NystrÃ¶m, Gen-ART comments
   from Suresh Krishnan, and an IANA question from Yoshiko Chong. 

Note to RFC Editor
 
  please update Section 9.1, paragraph 3 as follows:

  OLD:
    Note, additionally, that the process of independent Call
    establishment, where the Call is set up separately from the LSPs, may
    be used to apply an extra level of authentication and policy for the
    end-to-end LSPs above that which is available with Call-less,
    hop-by-hop LSP setup.

  NEW:
    Note, additionally, that it would be desirable to use the process
    of independent Call establishment, where the Call is set up
    separately from the LSPs, to apply an extra level of authentication
    and policy for the end-to-end LSPs above that which is available
    with Call-less, hop-by-hop LSP setup.  However doing so will
    require additional work to set up security associations between the
    peer and the call manager that meet the requirements of [RFC4107].
    The mechanism described in this document is expected to meet this
    use case when combined with this additional work.  Application of
    this mechanism to the authentication and policy use case prior to
    standardization of a security solution is inappropriate and outside
    the current applicability of the mechanism.

  Also, please update some out of date references. Please
  reference RFC 4302 instead of RFC 2402, and reference RFC 4303
  instead of RFC 2406.

IESG Note

 (Insert IESG Note here)

IANA Note

 (Insert IANA Note here)

Envelope-to: [email-masked]
Delivery-date: Tue, 10 Apr 2007 18:23:11 +0000
Date: Tue, 10 Apr 2007 11:21:09 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4874 on Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4874

        Title:      Exclude Routes - Extension to 
                    Resource ReserVation Protocol-Traffic Engineering 
                    (RSVP-TE) 
        Author:     CY. Lee, A. Farrel,
                    S. De Cnodder
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      27
        Characters: 59569
        Updates:    RFC3209, RFC3473
        See-Also:   

        I-D Tag:    draft-ietf-ccamp-rsvp-te-exclude-route-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4874.txt

This document specifies ways to communicate route exclusions during
path setup using Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
abstract nodes and resources to be explicitly included in a path
setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the
head end, it may be useful to specify and signal abstract nodes and
resources that are to be explicitly excluded from routes.  These
exclusions may apply to the whole path, or to parts of a path between
two abstract nodes specified in an explicit path.  How Shared Risk
Link Groups (SRLGs) can be excluded is also specified in this
document.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Delivery-date: Sun, 08 Apr 2007 12:28:39 +0000
To: Greg Jones <[email-masked]>
Cc: Yoichi Maeda <[email-masked]>, Stephen Trowbridge <[email-masked]>, Kam Lam <[email-masked]>, Scott Bradner <[email-masked]>, Ross Callon <[email-masked]>, Dave Ward <[email-masked]>, CCAMP Mailing List <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>
From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "Cooperative Relationship between ITU-T  SG15 and CCAMP" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Sun, 08 Apr 2007 08:25:56 -0400

Title: Cooperative Relationship between ITU-T SG15 and CCAMP
Submission Date: 2007-04-08
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=318 
Please reply by 2007-06-25

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T SG15(Greg Jones <[email-masked]>)
Cc: Yoichi Maeda <[email-masked]>
Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Scott Bradner <[email-masked]>
Ross Callon <[email-masked]>
Dave Ward <[email-masked]>
CCAMP Mailing List <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For action 
Body: The CCAMP working group of the IETF thanks you for your liaison
entitled "Liaison Statement to CCAMP responding to ccamp liaison
of 21 February 2007". The last paragraphs of your liaison discuss
the cooperative relationship between ITU-T SG15 and the IETF's
CCAMP working group and we would like to respond to these issues
separate from the technical discussions.

Over the last few years we have seen an increase in cooperation
between our organisations, and we believe that this is to the
considerable benefit of the industry. CCAMP has regularly sent a
liaison representative to ITU plenary and interim meetings, and
useful comments and feedback have been received from these 
meetings as a result of review of IETF Internet-Drafts in 
progress. Additionally, Mr. Lyndon Ong has been allocated a
regular slot on the CCAMP meeting agenda at each IETF meeting to
update the working group on the progress of the ITU-T in areas of
interest to CCAMP.

While we consider that the free flow of information and the review
feedback on CCAMP work to be very valuable, we are also conscious
that the mechanisms of the ITU-T and IETF are very different. 
Therefore we make every attempt to avoid wasting your precious
meeting time, and only ask for review when we consider the material
to be stable and pertinent.

In your liaison, you say:

   ITU-T SG 15 has been relying on a collaborative relationship with
   IETF ccamp to provide the protocol support for ASON.  This
   collaborative work should allow the industry to take advantage of
   the different expertise in each of the Standards Development
   Organizations. Q.14/15 has not developed protocol specific
   Recommendations for ASON since 2003, based on an expected
   collaborative technical relationship, in which IETF ccamp would
   provide protocol solutions that fully meet the ITU-T ASON
   requirements.

We appreciate your engagement with this process and we believe that 
it is to the best interests of the industry and to all participants
in both bodies. The liaison process provides a mechanism to engage
between the two bodies, and it is clear that the earlier 
communication occurs, the less the chance of misunderstanding or
parallel development.

In order to describe the IETF's view of the procedures and 
processes for extending and varying IETF protocols, the IETF has
recently published RFC 4775 ("Procedures for Protocol Extensions 
and Variations"). In order to describe the mechanisms by which 
other bodies can influence the development of MPLS and GMPLS 
protocols, the IETF has just consented for publication draft-
andersson-rtg-gmpls-change-08.txt ("Change Process for 
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Protocols and Procedures"). The net effect of these documents is 
to give the ITU-T clear access into the IETF process and to commit
the IETF to work with the ITU-T to develop solutions to requirements
that originate in the ITU-T.

You state further:

   However, the effectiveness of this SDO liaison relationship
   could be improved.

We agree that there is always room for improvements on both sides.
Some issues will arise from differences in established behaviour 
within the two bodies, and we are always grateful when you point 
out opportunities to improve the mechanisms that we have in place.
Although neither the ITU-T nor the IETF is likely to make a major 
change to its operational procedures, there are doubtless very many
small areas where improvements could be made.

One such area of improvement might be to relax the communication 
style and mechanisms allowing a more free and rapid exchange of 
technical opinions amongst the participants. Although this cannot 
replace the liaison relationship as a means for exchanging the 
official and consented views of each body, we could gain a lot from
increasing the level of discussion rather than relying on the 
relatively infrequent use of liaison statements. We would welcome
your suggestions on how to achieve this - the CCAMP mailing list
remains open and might be a suitable vehicle for this type of
communication.

As you go on to say:

   We observe that IETF ccamp has responded to some of the
   technical issues raised by suggesting that the ITU-T participants
   should provide input directly, to the work in ccamp.  We agree
   that having participants involved in both the  ITU-T and IETF
   improves the communication process.  We would like to confirm
   that this individual participation is not being suggested as a
   substitute for the liaison relationship.  A liaison statement or
   ITU-T Recommendation represents the consensus of the members
   of the ITU-T.  An individual participating in the work of ccamp is
   not authorized to represent or negotiate on behalf of the ITU-T.

We understand the points you make. Nevertheless, we would like to 
continue to encourage individual participation. Individuals who are
interested in the development rather than the review of protocol 
solutions would be well advised to bring their ideas to CCAMP early
in the process. In the same way, we would advise individuals 
interested in the work of the ITU-T to become involved there and 
not to wait for the opportunity to review the material when it is 
liaised to the IETF as it nears completion.

You cite a specific area for improvement in your liaison, and we are
grateful for your attempt to isolate specifics since it is far more
easy to learn from examples than from general statements.

   One particular area for improvement of the liaison relationship is
   communicating the disposition of ITU-T comments related to the
   interpretation of ASON requirements.  For example comments
   provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
   RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
   RFC 4652) were not included in the published RFC and the rational
   for this decision has not been communicated.

We are disturbed by your identification of these specific concerns at
this time in our communication. Due to the time that has lapsed since
the events that you mention, it is hard to provide appropriate and 
definitive discussion.

We believe that the discussion of RFC 4258 and lack of response refers 
to a liaison received from SG15 in February 2004. Although the issues 
received full discussion on an open mailing list and included comments
from no fewer than seven regular Q14/15 participants, and although the
design team that produced the final text of the RFC included Q14/15 
participants who could have reported the agreement and rationale back
to Q14/15, we agree that it would have been helpful to liaise the 
outcome of these discussions to you direct.

In a subsequent liaison (COM15-LS18) in April 2004, you stated:

   Q.14/15 would like to thank the IETF CCAMP WG and
   especially the members of the ASON Routing Requirements
   Design Team for their efforts to understand and capture ASON
   Routing Requirements for the future work in IETF.

   Q.14/15 would like to continue cooperative work with IETF,
   extending this to the application of routing protocols to support
   the ASON requirements.

We interpreted these sentences to mean that you were aware of the 
completion of RFC4258 and that you were satisfied with the results.

Review of the material that led to RFC 4652 was first liaised to CCAMP
by SG15 in May 2005 (COM15-LS57-E) in response to a request for review
issued by CCAMP earlier that same month. The liaison from SG15 was 
marked "For Information" and our understanding of this label (as noted
in section 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to
inform the addressee of something, and expects no response." In the 
light of the current situation it would have been wise for the chairs
to have confirmed that this was really the intended purpose of the 
liaison, but we should note that 50% of the author team for RFC 4652 
were regular Q14/15 attendees who could have reported the status and 
decisions (albeit informally) to the Question.

Subsequent liaisons on the material of RFC 4652 included:

   November 2005 (Q12-14 Interim meeting-LS006-E)
   "Q.14/15 ... strongly supports CCAMP's continued work to
   address ASON requirements in the routing protocols."

Your recent liaison concludes:

   ITU-T SG15 continues to be interested in providing clarification or
   validation of IETF ccamp interpretation of the ASON requirements
   and therefore request that in future any documents under
   development that are potentially applicable to ASON be liaised so
   that ITU-T can validate the documents against the ASON
   requirements.

   We look forward to receiving your response and hope that we can
   continue to build a cooperative and productive relationship between
   ccamp and SG 15.

While we cannot promise to send every piece of work that is potentially
applicable to ASON, we can and will liaise all work where there is a
definitive intention of applicability to ASON.

CCAMP continues to be grateful to SG15 for its efforts to ensure that 
the ASON architecture and requirements are correctly interpreted, and
appreciates that this will lead to protocol solutions that are of 
value to the industry.

Best regards,

Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group
Attachment(s):
No document has been attached

Delivery-date: Fri, 06 Apr 2007 13:47:21 +0000
Date: Fri, 06 Apr 2007 09:44:38 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Switching technologies requiring bidirectional asymmetric LSPs?

All,

So a few of us have been having been discussing the asymmetric work 
presented in Prague and it seems to me we have an open question on 
requirements.

It's clear that at least one switching technology (i.e., 
ethernet/PBB-TE) requires support for bidirectional asymmetric 
LSPs.  The question is:

Is the *requirement* for bidirectional asymmetric LSPs:
(a) a technology specific requirement, or
(b) one that is common (this is CCAMP after all!) to multiple 
switching technologies?

Please keep in mind that service requirements are not the same thing 
as switching technology requirements.  For example, we have long 
built bidirectional asymmetric services on unidirectional MPLS LSPs.

The answer to this question will help determine if we should have a 
technology specific solution or a generic CCAMP solution (as well as 
the complexity of the solution.)

Much thanks,
Lou

Delivery-date: Thu, 05 Apr 2007 09:10:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Please publish draft-ietf-ccamp-te-node-cap-05.txt
Date: Thu, 5 Apr 2007 10:09:14 +0100
Organization: Old Dog Consulting

Hi Ross,

draft-ietf-ccamp-te-node-cap-05.txt has completed CCAMP working group last
call and has been updated accordingly.

The CCAMP working group requests publication as a Standards Track RFC.

Proto Write-up according to
https://rtg.ietf.org/area/procedures/proto_wgchair_writeup is found below.

Thanks,
Adrian

===

draft-ietf-ccamp-te-node-cap-05.txt

Adrian Farrel is willing to be Proto Shepherd for this I-D

> 1. Have the chairs personally reviewed this version of
>    the Internet Draft (ID), and in particular, do they
>    believe this ID is ready to forward to the IESG for
>    publication?

This I-D received WG chair review by Adrian prior to WG last call.
The last call mark-ups were checked by Adrian.

The chairs believe this I-D is ready to move forward.

> 2. Has the document had adequate review from both key WG
>    members and key non-WG members? Do you have any
>    concerns about the depth or breadth of the reviews
>    that have been performed?

The document is authored by some key WG members and received constructive
comments from across the WG during its development.

The document was shown to the OSPF and ISIS working groups more than once,
and the last call was notified to the two IGP working groups.

The chairs have no concerns about the depth of review.

> 3. Do you have concerns that the document needs more
>    review from a particular (broader) perspective (e.g.,
>    security, operational complexity, someone familiar
>    with AAA, etc.)?

The chairs have no such concerns.

> 4. Do you have any specific concerns/issues with this
>    document that you believe the ADs and/or IESG should
>    be aware of? For example, perhaps you are
>    uncomfortable with certain parts of the document, or
>    have concerns whether there really is a need for it.
>    In any event, if your issues have been discussed in
>    the WG and the WG has indicated it that it still
>    wishes to advance the document, detail those concerns
>    in the write-up.

The chairs have no such concerns.

> 5. How solid is the WG consensus behind this document?
>    Does it represent the strong concurrence of a few
>    individuals, with others being silent, or does the WG
>    as a whole understand and agree with it?

The working group has been relatively quiet on this work, but the chairs
judge that to be because it is "done and dusted". It is a small protocol
feature that does not need significant debate.

> 6. Has anyone threatened an appeal or otherwise indicated
>    extreme discontent? If so, please summarise the areas
>    of conflict in separate email to the Responsible Area
>    Director.

The chairs have no knowledge of any such issues.

> 7. Have the chairs verified that the document adheres to
>    all of the ID Checklist items ?

Yes, as far as humanly possible.

> 8. Is the document split into normative and informative
>    references? Are there normative references to IDs,
>    where the IDs are not also ready for advancement or
>    are otherwise in an unclear state? (note here that the
>    RFC editor will not publish an RFC with normative
>    references to IDs, it will delay publication until all
>    such IDs are also ready for publication as RFCs.)

The split is good.

There are normative references to the following I-Ds that are believed to be
ahead of this I-D in the process and will complete RFC publication before
this I-D:

There is one normative down-reference. It is believed that the referenced
RFC is in the process of being upgraded to standards track.

RFC 3784 Intermediate System to Intermediate System (IS-IS)
                  Extensions for Traffic Engineering (TE)

There is also a normative reference to the ISIS specification. It is
believed that this is also acceptable.

> 9. What is the intended status of the document? (e.g.,
>    Proposed Standard, Informational?)

Proposed Standard

> 10. For Standards Track and BCP documents, the IESG
>     approval announcement includes a write-up section
>     with the following sections:
>
> a. Technical Summary
>    The relevant information for the technical summary can
>    frequently be found in the abstract and/or
>    introduction of the document. If not, this may be an
>    indication that there are deficiencies in the abstract
>    or introduction.

It is highly desirable to take into account Traffic Engineering (TE) node
capabilities during Multi Protocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) route
selection. For instance, the capability of a Label Switching Router (LSR) to
act as a branch of a Point-To-MultiPoint (P2MP) LSP influences the choice of
LSRs on the route of a P2MP LSP.

This document specifies extensions to the Open Shortest Path First (OSPF)
and Intermediate System-Intermediate System (IS-IS) traffic engineering
extensions for the advertisement of control plane and data plane traffic
engineering node capabilities.

> b. Working Group Summary
>    Was there anything in WG process that is worth noting?
>    For example, was there controversy about particular
>    points, decisions where consensus was particularly
>    rough, etc.

Nothing special. The ISIS working group had some comments about the use of
ISIS terminology that were fixed.

> c. Protocol Quality
>    Are there existing implementations of the protocol?

Two implementations known.

>    Have a significant number of vendors indicated they
>    plan to implement the specification?

No significant discussions on this point, but various vendors have indicated
that they intend to implement some of the features (mixed MPLS and GMPLS
control plane, P2MP MPLS-TE) that will depend on this function.

>    Are there any reviewers that merit special mention as
>    having done a thorough review (i.e., that resulted in
>    important changes or a conclusion that the document
>    had no substantive issues)?

The Acknowledgements section of the I-D recognises Benoit Fondeviole, Adrian
Farrel, Dimitri Papadimitriou, Acee Lindem and David Ward for their useful
comments and suggestions.

Delivery-date: Thu, 05 Apr 2007 08:19:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Thu, 5 Apr 2007 10:17:40 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Diego Caviglia \(GA/ERI\)" <[email-masked]>

Hi Dimitri.

Please, see my answer in-line.

Regards,

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]=20

hello julien

i think we are diverging in this discussion

[JM] I don't believe so. The requirement does not come from a lack in
GMPLS specifications themselves but rather from operational concerns
because, in most cases, GMPLS-controlled networks will co-exist with
legacy networks and legacy procedures.

- imho, the questions are=20

is the proposal intended to detect running data plane failures resulting

from some control plane component e.g. signaling ? or=20
mis-use/mis-configurations triggered by user/management plane/others ?

[JM] I think both could occur, but human mistake is probably the major
factor to deal with. If you are fearing we may be dealing with broken
implementations, I would say it is not the idea.

is the proposal intended to provide near real time mechanism (fast=20
detection) or an off-line mechanism (diagnostic) ? what is the diameter
of=20
the detection/verification such as to ensure proper localisation ?

[JM] Here, I feel that is up to the operator, but in my view it would
rather be a periodical or an on-demand procedure.

what is the expectation from the control plane and mechanism like those=20
enabled by LMP (i.e. why LMP is suitable both in terms of messaging and=20
processing) ?

[JM] As LMP is already used to verify data plane connectivity, I
consider it is an apropriate candidate to support this feature. Anyway,
if you have a more suitable protocol to propose, I think it is not too
late to take it into account.

thanks,
-d.=20

"MEURIC Julien RD-CORE-LAN" <[email-masked]>
Sent by: [email-masked]
04/04/2007 10:44
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Diego
Caviglia=20
\(GA/ERI\)" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel=20
Status I-D

Hi Dimitri.

I must disagree with you. Let us get out of the pure CCAMP context to
come=20
to the real world.

In transmission networks, we will see both control and management planes

being used together for a long time. In transmission networks, operators

are used to making manual operations even if equipments are control=20
plane-enabled: programmed work, configuration of legacy rings where=20
control plane does not exist, maintenance... More generally, one could=20
always find some specific operational cases which need human
intervention=20
but which does not justify the development of a specific control plane=20
feature.
You may try to solve this problem by saying this pool of resource is=20
"purely" (provided  this means something in terms of operations) handled

by the control plane and that other pool is not seen; however, besides
the=20
fact that that kind of partitionning would still be configured manually=20
with possible mistakes, you would have major drawbacks in terms of=20
operations and resource optimization.

What is proposed in the ID is just a mechanism relying on a control
plane=20
protocol to detect *data plane* discrepencies which may occur because of

the cross-connection nature of the circuit-switched world and of the=20
manual operations you will never completely get rid of.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf=20
Of [email-masked]

hi diego

not sure to understand, an automated control plane (at the end the
purpose=20

of this WG) is used to control XC, and other related resource
reservations

now you state that there could be manual operations that fails ??? i
think=20

this simply falls outside the scope of the WG, on the other hand if some

TS are unproper for cross-connection i assume the CP does not even take=20
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are=20
not good or for some reason that TS have been cross-connected by NMS for

error or may for testing at commissioning of the TNE and due to human=20
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good

in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it
would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses
a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link

of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935

Delivery-date: Wed, 04 Apr 2007 19:52:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-te-node-cap-05.txt 
Date: Wed, 04 Apr 2007 15:50:02 -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		: IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-te-node-cap-05.txt
	Pages		: 13
	Date		: 2007-4-4
	
It is highly desired in several cases, to take into account Traffic
   Engineering (TE) node capabilities during Multi Protocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered
   Label Switched Path (TE-LSP)  selection, such as for instance the
   capability to act as a branch Label Switching Router (LSR) of a
   Point-To-MultiPoint (P2MP) LSP. This requires advertising these
   capabilities within the Interior Gateway Protocol (IGP). For that
   purpose, this document specifies Open Shortest Path First (OSPF) and
   Intermediate System-Intermediate System (IS-IS) traffic engineering
   extensions for the advertisement of control plane and data plane
   traffic engineering node capabilities.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-te-node-cap-05.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, 04 Apr 2007 16:34:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>, <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Re: Liaison I(-)D Re: Draft liaison to ITU SG15 on process
Date: Wed, 4 Apr 2007 12:02:58 +0100
Organization: Old Dog Consulting

Hi,

[I think Tom's original mail may not have made it to CCAMP because he used 
an alternate sending address]
----- Original Message ----- 
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Scott Bradner" 
<[email-masked]>
Sent: Wednesday, April 04, 2007 7:59 AM
Subject: Liaison I(-)D Re: Draft liaison to ITU SG15 on process

> Adrian
>
> In your process response, you seem uncertain quite what ITU-T are 
> referring to
> and that is certainly a feeling I know well.  I think we have systemic 
> problem
> of identifying what we are talking about.  Our taxon for work generated in 
> the
> IETF is the I-D and we have a naming convention that I find invaluable. 
> Even
> when someone refers to draft-ietf-ccamp-telekinesis-signalling as 
> telekinetic
> CP, I stand a good chance of finding it in the database, via charter page, 
> draft
> index etc.
>
> But when a liaison is variously referred to as
> Incoming liaisons from ITU-T SG15 Q14
> G.8110.1Amd1file390.doc
> COM 15-LS27-G
>  http://www.olddog.co.uk/incoming.htm
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=7957
> I struggle, and may give up.
>
> If the liaising organisation gives the communication a unique ID - and the 
> ITU-T
> would appear to do that - then it would help me if that were used in all
> references
> to it so as to make it easy to tie the pieces together.  And then we could 
> ask
> IETF tools to make that a searchable and displayable field in the liaison
> database.
>
> In this instance, I think that the SG15 liaison about RFC4258 was the one 
> you
> referred to in a post to the ccamp list dated 1Mar04 but cannot tell.  I 
> think
> too that I looked on your website and could not find anything (access was 
> ok at
> that time) and later looked at the IETF website and found too much.  My 
> notes
> record me trying and giving up in this instance.

Yes, Tom, it would be really good to anchor all correspondence with a unique 
I-D.

The web-based mechanism now (finally) in place at the IETF does record all 
incoming and outgoing liaisons and assign them a unique URL so we can use 
this as the IETF reference. Unfortunately, this discussion goes back several 
years to when the web page was just an archive of liaisons sent by email and 
wasn't always correctly updated.

My ccamp web page for communications is a work in progress. I have started 
linking in responses that we send, and will also be including "unsolicited" 
communications that we send. What I am missing is a clear threading of 
communications.

With regard to the naming of liaisons coming from the ITU-T, I confess that 
I struggle. Sometimes they have a number at the top right hand corner that 
may be a unique identifier (although I am not sure that I see a monotonic 
increasing pattern!), but sometimes the number isn't there (most often when 
the liaison comes from an interim meeting?).

So I guess the most helpful thing we can do is give plenty of 
cross-references. I believe that most correspondence is working well with 
relative short threads and rapid turn-around. It is only the occasional dip 
into the past that causes grief (and I share your pain as I tried to go back 
and piece together the trail in this case).

Cheers,
Adrian

> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
> <[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
> <[email-masked]>
> Sent: Thursday, March 29, 2007 1:21 PM
> Subject: Draft liaison to ITU SG15 on process
>
>
>> Hi,
>>
>> One of the larger issues raised by a recent liaison from ITU-T Study 
>> Group
>> 15 is on process and how we can continue to build a better relationship
>> between SG15 and CCAMP.
>>
>> Here is a draft response.
>>
>> Comments please by end of April 5th.
>>
>> Thanks,
>> Adrian and Deborah
>> ===
>>
>> To: ITU-T SG15
>> From: IETF CCAMP
>> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross 
>> Callon,
>> Dave Ward
>> For Action
>> Deadline: 25th June 2007
>>
>> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP
>>
>> CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
>> responding to ccamp liaison of 21 February 2007". The last paragraphs of
>> your liaison discuss the cooperative relationship between ITU-T SG15 and 
>> the
>> IETF's CCAMP working group and we would like to respond to these issues
>> separate from the technical discussions.
>>
>> Over the last few years we have seen an increase in cooperation between 
>> our
>> organisations, and we believe that this is to the considerable benefit of
>> the industry. CCAMP has regularly sent a liaison representative to ITU
>> plenary and interim meetings, and useful comments and feedback have been
>> received from these meetings as a result of review of IETF 
>> Internet-Drafts
>> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular 
>> slot
>> on the CCAMP meeting agenda at each IETF meeting to update the working 
>> group
>> on the progress of the ITU-T in areas of interest to CCAMP.
>>
>> While we consider that the free flow of information and the review 
>> feedback
>> on CCAMP work to be very valuable, we are also conscious that the 
>> mechanisms
>> of the ITU-T and IETF are very different. Therefore we make every attempt 
>> to
>> avoid wasting your precious meeting time, and only ask for review when we
>> consider the material to be stable and pertinent.
>>
>> In your liaison, you say:
>>
>>      ITU-T SG 15 has been relying on a collaborative relationship with
>>      IETF ccamp to provide the protocol support for ASON.  This
>>      collaborative work should allow the industry to take advantage of
>>      the different expertise in each of the Standards Development
>>      Organizations. Q.14/15 has not developed protocol specific
>>      Recommendations for ASON since 2003, based on an expected
>>      collaborative technical relationship, in which IETF ccamp would
>>      provide protocol solutions that fully meet the ITU-T ASON
>>      requirements.
>>
>> We appreciate your engagement with this process and we believe that it is 
>> to
>> the best interests of the industry and to all participants in both
>> bodies. In order to crystallise this process, the IETF has recently
>> published RFC 4775 ("Procedures for Protocol Extensions and Variations") 
>> and
>> has just consented for publication 
>> draft-andersson-rtg-gmpls-change-08.txt
>> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
>> MPLS (GMPLS) Protocols and Procedures"). The net effect of these 
>> documents
>> is to give the ITU-T clear access into the IETF process and to commit the
>> IETF to work with the ITU-T to develop solutions to requirements that
>> originate in the ITU-T.
>>
>> You state further:
>>
>>      However, the effectiveness of this SDO liaison relationship could
>>      be improved.
>>
>> We agree that there is always room for improvements on both sides. Some
>> issues will arise from differences in established behaviour within the 
>> two
>> bodies, and we are always grateful when you point out opportunities to
>> improve the mechanisms that we have in place. Although neither the ITU-T 
>> nor
>> the IETF is likely to make a major change to its operational procedures,
>> there are doubtless very many small areas where improvements could be 
>> made.
>>
>> One such area of improvement might be to relax the communication style 
>> and
>> mechanisms allowing a more free and rapid exchange of technical opinions
>> amongst the participants. Although this cannot replace the liaison
>> relationship as a means for exchanging the official and consented views 
>> of
>> each body, we could gain a lot from increasing the level of discussion
>> rather than relying on the relatively infrequent use of liaison 
>> statements.
>> We would welcome your suggestions on how to achieve this - the CCAMP 
>> mailing
>> list remains open and might be a suitable vehicle for this type of
>> communication.
>>
>> As you go on to say:
>>
>>      We observe that IETF ccamp has responded to some of the
>>      technical issues raised by suggesting that the ITU-T participants
>>      should provide input directly, to the work in ccamp.  We agree
>>      that having participants involved in both the  ITU-T and IETF
>>      improves the communication process.  We would like to confirm
>>      that this individual participation is not being suggested as a
>>      substitute for the liaison relationship.  A liaison statement or
>>      ITU-T Recommendation represents the consensus of the members
>>      of the ITU-T.  An individual participating in the work of ccamp is
>>      not authorized to represent or negotiate on behalf of the ITU-T.
>>
>> We understand the points you make. Nevertheless, we would like to 
>> continue
>> to encourage individual participation. Individuals who are interested in 
>> the
>> development rather than the review of protocol solutions would be well
>> advised to bring their ideas to CCAMP early in the process. In the same 
>> way,
>> we would advise individuals interested in the work of the ITU-T to become
>> involved there and not to wait for the opportunity to review the material
>> when it is liaised to the IETF as it nears completion.
>>
>> You cite a specific area for improvement in your liaison, and we are
>> grateful for your attempt to isolate specifics since it is far more easy
>> to learn from examples than from general statements.
>>
>>      One particular area for improvement of the liaison relationship is
>>      communicating the disposition of ITU-T comments related to the
>>      interpretation of ASON requirements.  For example comments
>>      provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
>>      RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
>>      RFC 4652) were not included in the published RFC and the rational
>>      for this decision has not been communicated.
>>
>> We are disturbed by your identification of these specific concerns at 
>> this
>> time in our communication. Due to the time that has lapsed since the 
>> events
>> that you mention, it is hard to provide appropriate and definitive
>> discussion.
>>
>> We believe that the discussion of RFC 4258 and lack of response refers to 
>> a
>> liaison received from SG15 in February 2004. Although the issues received
>> full discussion on an open mailing list and included comments from no 
>> fewer
>> than seven regular Q14/15 participants, and although the design team that
>> produced the final text of the RFC included Q14/15 participants who could
>> have reported the agreement and rationale back to Q14/15, we agree that 
>> it
>> would have been helpful to liaise the outcome of these discussions to you
>> direct.
>>
>> In a subsequent liaison (COM15-LS18) in April 2004, where you stated:
>>
>>      Q.14/15 would like to thank the IETF CCAMP WG and
>>      especially the members of the ASON Routing Requirements
>>      Design Team for their efforts to understand and capture ASON
>>      Routing Requirements for the future work in IETF.
>>
>>      Q.14/15 would like to continue cooperative work with IETF,
>>      extending this to the application of routing protocols to support
>>      the ASON requirements.
>>
>> We interpreted these sentences to mean that you were aware of the 
>> completion
>> of RFC4258 and that you were satisfied with the results.
>>
>> Review of the material that led to RFC 4652 was first liaised to CCAMP by
>> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review 
>> issued
>> by CCAMP earlier that same month. The liaison from SG15 was marked "For
>> Information" and our understanding of this label (as noted in section
>> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the
>> addressee of something, and expects no response." In the light of the
>> current situation it would have been wise for the chairs to have 
>> confirmed
>> that this was really the intended purpose of the liaison, but we should 
>> note
>> that 50% of the author team for RFC 4652 were regular Q14/15 attendees 
>> who
>> could have reported the status and decisions (albeit informally) to the
>> Question.
>>
>> Subsequent liaisons on the material of RFC 4652 included:
>>
>>      November 2005 (Q12-14 Interim meeting-LS006-E)
>>      "Q.14/15 ... strongly supports CCAMP's continued work to
>>      address ASON requirements in the routing protocols."
>>
>> Your recent liaison concludes:
>>
>>      ITU-T SG15 continues to be interested in providing clarification or
>>      validation of IETF ccamp interpretation of the ASON requirements
>>      and therefore request that in future any documents under
>>      development that are potentially applicable to ASON be liaised so
>>      that ITU-T can validate the documents against the ASON
>>      requirements.
>>
>>      We look forward to receiving your response and hope that we can
>>      continue to build a cooperative and productive relationship between
>>      ccamp and SG 15.
>>
>> While we cannot promise to send every piece of work that is potentially
>> applicable to ASON, we can and will liaise all work where there is a
>> definitive intention of applicability to ASON.
>>
>> CCAMP continues to be grateful to SG15 for its efforts to ensure that the
>> ASON architecture and requirements are correctly interpreted, and
>> appreciates that this will lead to protocol solutions that are of value 
>> to
>> the industry.
>>
>> Best regards,
>>
>> Adrian Farrel and Deborah Brungard
>> Co-chairs, IETF CCAMP Working Group
>>
>>
>>
>
>
>
> 

Delivery-date: Wed, 04 Apr 2007 14:49:02 +0000
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Cc: [email-masked], "Diego Caviglia \(GA/ERI\)" <[email-masked]>, [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Wed, 4 Apr 2007 16:46:41 +0200

hello julien

i think we are diverging in this discussion - imho, the questions are 

is the proposal intended to detect running data plane failures resulting 
from some control plane component e.g. signaling ? or 
mis-use/mis-configurations triggered by user/management plane/others ?

is the proposal intended to provide near real time mechanism (fast 
detection) or an off-line mechanism (diagnostic) ? what is the diameter of 
the detection/verification such as to ensure proper localisation ?

what is the expectation from the control plane and mechanism like those 
enabled by LMP (i.e. why LMP is suitable both in terms of messaging and 
processing) ?

thanks,
-d. 

"MEURIC Julien RD-CORE-LAN" <[email-masked]>
Sent by: [email-masked]
04/04/2007 10:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Diego Caviglia 
\(GA/ERI\)" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel 
Status I-D

Hi Dimitri.

I must disagree with you. Let us get out of the pure CCAMP context to come 
to the real world.

In transmission networks, we will see both control and management planes 
being used together for a long time. In transmission networks, operators 
are used to making manual operations even if equipments are control 
plane-enabled: programmed work, configuration of legacy rings where 
control plane does not exist, maintenance... More generally, one could 
always find some specific operational cases which need human intervention 
but which does not justify the development of a specific control plane 
feature.
You may try to solve this problem by saying this pool of resource is 
"purely" (provided  this means something in terms of operations) handled 
by the control plane and that other pool is not seen; however, besides the 
fact that that kind of partitionning would still be configured manually 
with possible mistakes, you would have major drawbacks in terms of 
operations and resource optimization.

What is proposed in the ID is just a mechanism relying on a control plane 
protocol to detect *data plane* discrepencies which may occur because of 
the cross-connection nature of the circuit-switched world and of the 
manual operations you will never completely get rid of.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]

hi diego

not sure to understand, an automated control plane (at the end the purpose 

of this WG) is used to control XC, and other related resource reservations

now you state that there could be manual operations that fails ??? i think 

this simply falls outside the scope of the WG, on the other hand if some 
TS are unproper for cross-connection i assume the CP does not even take 
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are 
not good or for some reason that TS have been cross-connected by NMS for 
error or may for testing at commissioning of the TNE and due to human 
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] 

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted 

the i-d refers to the deletion case (2.2), fine but there is cleanup 
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

This was bounced.
 
D

> Hi Dimitri,
>            my understunding of the ID was that it tries to 'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good 
in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of 
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention, 
attempt
> to clean up a partitioned control plane, etc.) we believe that it would 
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one 
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be 
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link 
of
> a
>
> bundle, because the problem cannot be detected from the TE 
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the 
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention, 
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935

Delivery-date: Wed, 04 Apr 2007 12:17:41 +0000
Date: Wed, 04 Apr 2007 20:14:38 +0800
From: Dan Li <[email-masked]>
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
To: [email-masked], "Diego Caviglia (GA/ERI)" <[email-masked]>
Cc: [email-masked], [email-masked]

Hi all,

For case 2.2, as we have described in the draft, I think it's a local policy decision how this mismatched state should be handled. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use. In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures.

Regards,

Dan 

----- Original Message ----- 
From: <[email-masked]>
To: "Diego Caviglia (GA/ERI)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 04, 2007 1:29 AM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

> diego
> 
> > I think that the reason wht timeslot 2 is not usable is out of the
> > scope of the ID.
> 
> but this is kernel of the problem, the origin tells where the solution
> shall be targeted 
> 
> the i-d refers to the deletion case (2.2), fine but there is cleanup 
> timeout interval to free resources in rsvp
> 
> thanks,
> -d.
> 
> 
> 
> 
> 
> "Diego Caviglia \(GA/ERI\)" <[email-masked]>
> Sent by: [email-masked]
> 03/04/2007 13:26
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        Re: Solicit the comments on LMP Data Channel 
> Status I-D
> 
> 
> This was bounced.
>  
> D
>  
> 
> > Hi Dimitri,
> >            my understunding of the ID was that it tries to 'synchronize'
> > the status of the timeslots that are facing the same link.
> >
> > Otherwise downstream NE can choose a timeslot that is not good for the
> > upstream node
> >
> >
> > NE-A                          NE-B
> > Timeslots                     Timeslots
> > 1-OK                          1-OK
> > 2-OK                          2-KO
> > 3-OK                          3-OK
> > 4-OK                          4-OK
> >
> > So NE-A can choose Timeslot 2 because it see it good while is not good 
> in
> > NE-B.  I think that the reason wht timeslot 2 is not usable is out of 
> the
> > scope of the ID.
> >
> > BR
> >
> > Diego
> >
> >
> >
> >
> >
> >
> > [email-masked] on 03/04/2007 11.57.12
> >
> > To:    "Diego Caviglia" <[email-masked]>, Dan Li
> >       <[email-masked]>, ccamp <[email-masked]>
> > cc:
> >
> > Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
> >
> > diego & dan
> >
> > "Since the error condition can arise from a variety of situations
> > (including
> > control plane failure and restart, management plane intervention, 
> attempt
> > to clean up a partitioned control plane, etc.) we believe that it would 
> be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> > Resolution of the problem remains an issue for the management plane."
> >
> > we have three classes of "errors" those outside scope of the CP, those
> > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> > then those that are strictly specific to the LMP and operations
> >
> > only the latter shall be in-scope - all these circular dependencies we
> > are introducing in this control plane are just breaking one of the main
> > design principle of networks
> >
> > -> which are the remaining "situations" ?
> >
> > thanks,
> > -d.
> >
> >
> >
> >
> >
> > "Diego Caviglia" <[email-masked]>
> > 03/04/2007 11:35
> >
> >        To:     "Dan Li <danli"
> >        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> > ""[email-masked], Adrian" <adrian", Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> > ""[email-masked], Snigdho" <Snigdho.Bardalai"
> >        Subject:        Re: Solicit the comments on LMP Data Channel
> > Status I-D
> >
> >
> >
> > Hi Dan,
> >        as stated in Prague I think that the ID addresses a real problem.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > Dan Li <[email-masked]> on 03/04/2007 10.47.58
> >
> > To:    ccamp <[email-masked]>
> > cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
> >       <[email-masked]>, Dimitri Papadimitriou
> >       <[email-masked]>, Julien Meuric
> >       <[email-masked]>, Diego Caviglia
> >       <[email-masked]>, "Bardalai, Snigdho"
> >       <[email-masked]>
> >
> > Subject:    Solicit the comments on LMP Data Channel Status I-D
> >
> > Hi all,
> >
> > In Prague we saw three optical vendors stating that this I-D addresses a
> > real problem that they see in deployed networks. We also saw one 
> operator
> > expressing interest in the work.
> >
> > To summarise the problem that we are addressing:
> >
> > Under some circumstances the opposite ends of data links may get into
> > mismatched states. For example, one end of the data link may be 
> allocated
> > and cross-connected, while the other end is available for use. This
> > represents an error condition.
> >
> > The problem is particularly bad when the data link is a component link 
> of
> > a
> >
> > bundle, because the problem cannot be detected from the TE 
> advertisements.
> > Further, existing LMP mechanisms do not allow us to discover the 
> problem.
> >
> > If left undetected and unresolved, the situation may lead to LSP setup
> > failures or to misconnection of LSPs.
> >
> > Since the error condition can arise from a variety of situations
> > (including
> >
> > control plane failure and restart, management plane intervention, 
> attempt
> > to
> > clean up a partitioned control plane, etc.) we believe that it would be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> >
> > Resolution of the problem remains an issue for the management plane.
> >
> > We would like to hear from people who believe that this is or is not a
> > real
> >
> > problem in the network so that we can judge whether to ask the chairs to
> > make this a WG draft.
> > Best regards,
> >
> >
> > Dan Li
> >
> > Advanced Technology Department
> > Wireline Networking Business Unit
> > Huawei Technologies Co., LTD.
> > Huawei Base, Bantian, Longgang,
> > Shenzhen 518129 P.R.China
> > Tel: +86-755-28973237
> > Fax: +86-755-28972935
> > 
> ***************************************************************************************
> >
> >
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address is
> > listed above. Any use of the information contained herein in any way
> > (including, but not limited to, total or partial disclosure, 
> reproduction,
> > or dissemination) by persons other than the intended recipient(s) is
> > prohibited. If you receive this e-mail in error, please notify the 
> sender
> > by phone or email immediately and delete it!
> > 
> ***************************************************************************************
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 04 Apr 2007 11:57:12 +0000
To: Greg Jones <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Kam Lam <[email-masked]>, Ross Callon <[email-masked]>, Dave Ward <[email-masked]>, Scott Bradner <[email-masked]>, CCAMP Mailing List <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>
From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "VCAT/LCAS Work in CCAMP" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Wed, 04 Apr 2007 07:56:46 -0400

Title: VCAT/LCAS Work in CCAMP
Submission Date: 2007-04-04
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=316 
Please reply by 2007-06-25

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T Q14/15, ITU-T Q11/15(Greg Jones <[email-masked]>)
Cc: Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Ross Callon <[email-masked]>
Dave Ward <[email-masked]>
Scott Bradner <[email-masked]>
CCAMP Mailing List <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For comment 
Body: The CCAMP working group thanks Q14/15 for your liaison "Liaison Statement to
CCAMP regarding work on calls and Vcat/LCAS" dated March 2007.

We are not sure that the Internet-Draft
draft-ietf-ccamp-gmpls-vcat-lcas-01.txt does use mechanisms defined by 
ITU-T SG 15 in Recommendations G.7041 and G.7042. We believe that 
"G.7041 and G.7042" is a typo and you probably meant "G.7042 and
G.7043". Further, the intention or the Internet-Draft is to enable 
the use of such mechanisms in a GMPLS network, not to use the 
mechanisms.

Nevertheless, we note your interest in this work and would welcome your
comments especially with respect to the applicability of this work to an
ASON network.

The current published version of this work can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.txt.

Please note, however, that this Internet-Draft remains work in progress
and the authors plan to continue to make changes to the published
material. Therefore, while we would welcome your comments, we suggest 
that you do not invest heavily in a detailed review at this stage.

We will be happy to liaise future versions of this Internet-Draft to you
as they become available if this is of interest to you.

Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group
Attachment(s):
No document has been attached

Delivery-date: Wed, 04 Apr 2007 11:21:20 +0000
To: Greg Jones <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Kam Lam <[email-masked]>, Ross Callon <[email-masked]>, Dave Ward <[email-masked]>, Scott Bradner <[email-masked]>, CCAMP Mailing List <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>
From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "Multi-Layer Networking (MLN) Work in  CCAMP" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Wed, 04 Apr 2007 07:21:05 -0400

Title: Multi-Layer Networking (MLN) Work in CCAMP
Submission Date: 2007-04-04
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=315 
Please reply by 2007-05-18

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T Q14/15(Greg Jones <[email-masked]>)
Cc: Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Ross Callon <[email-masked]>
Dave Ward <[email-masked]>
Scott Bradner <[email-masked]>
CCAMP Mailing List <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For action 
Body: The CCAMP working group notes your request to review its work on Multi-Layer 
Networking (MLN) as indicated in your liaison "Liaison Statement to CCAMP 
responding to ccamp liaison of 21 February 2007" dated March 2007.

We are nearing completion of our analysis of the requirements for MLN, and 
our evaluation of existing protocols, so now is an appropriate time for you 
review this material, and we would be grateful for your comments on or 
before the deadline marked above.

The requirements work can be found at 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-02.txt
The protocol evaluation is at 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-02.txt

In your review of this material, it may be helpful to pay particular care to 
understand the definition of MLN that is used. It may also be helpful to use 
some of the terminology interpretation presented in RFC4397.

The CCAMP working group also anticipates working on protocol extensions to 
fill the lacunae identified by the protocol evaluation Internet-Draft. An 
individual submission on this subject may be found at 
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-03.txt, 
but the working group has yet to make a decision about whether to accept 
this as the basis for the work.

We note that in a liaison dated February 2004 discussing the signaling 
requirements for ASON and reviewing draft-ietf-ccamp-gmpls-ason-reqts-05.txt 
you said:

    11. G.8080 defines the ASON control plane as applying to a
        single layer.  Some examples in the draft involve multiple
        layers.  While not precluded by implementations, a suggested
        replacement example is contained in the marked up copy that
        is single layer.

Could you please confirm your current view of the definition of the ASON 
control plane in G.8080. Does the ASON control plane now apply to more than 
one layer? Could you please provide references to the appropriate sections 
of your Recommendations.

Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group
Attachment(s):
No document has been attached

Delivery-date: Wed, 04 Apr 2007 11:16:34 +0000
To: Greg Jones <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Kam Lam <[email-masked]>, Ross Callon <[email-masked]>, Dave Ward <[email-masked]>, Scott Bradner <[email-masked]>, CCAMP Mailing List <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>, Adrian Farrel <[email-masked]>, Deborah Brungard <[email-masked]>
From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "Call/Connection Separation in ASON and  GMPLS" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Wed, 04 Apr 2007 07:14:53 -0400

Title: Call/Connection Separation in ASON and GMPLS
Submission Date: 2007-04-04
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=314 
Please reply by 2007-05-11

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T Q14/15(Greg Jones <[email-masked]>)
Cc: Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Ross Callon <[email-masked]>
Dave Ward <[email-masked]>
Scott Bradner <[email-masked]>
CCAMP Mailing List <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For comment 
Body: The CCAMP working group of the IETF thanks you for your liaison "Liaison
Statement to CCAMP responding to ccamp liaison of 21 February 2007"
(Q14/15-LS1-E) dated March 2007.

This liaison continues a discussion on the logical separation of calls and
connections. The substance of this conversation is as follows:

SG15 to CCAMP
COM15-LS126-E dated November 2006
     2.0 Call/Connection architecture and realization approaches
         Attachment 2 below provides further elaboration of application
         scenarios that illustrate G.8080 call/connection control
         component interactions.  The G.8080 architecture may be
         employed to support various call control realization
         approaches.  It should be noted that the architecture does not
         dictate any particular implementation and we would request that
         any solution not impose such limitations.  We observe that
         Section 3.2 of <draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt>
         explicitly prohibits logical call/connection control
         separation; i.e., call communications "piggy-backing" on
         connection communications.

CCAMP to SG15
Dated 21st February 2007
     Regarding your comments on 2.0
     It is important to recognize that [this draft] introduces Call
     mechanisms into GMPLS as a generic tool. As noted in Section 2,
     while the mechanisms of this document meet the requirements in
     RFC 4139, they are intended to have wider applicability than 
     ASON. RFC 4139 details the requirements for ASON.

     The application of the GMPLS Call to the ASON architecture in
     order to satisfy the requirements for conveying ASON Call 
     information across a GMPLS interface and for managing ASON
     Calls at a GMPLS UNI or GMPLS ENNI will require a new 
     Applicability Draft.

     Thus, section 3.2 of this document does not imply anything 
     about ASON, and certainly not that ASON requires full and
     logical call/connection separation.

     We understand that ASON Calls may be implemented through 
     full call/connection separation (as in G.7713.3) or 
     call/connection 'piggybacking' as in G.7713.2. Please
     confirm that our interpretation of G.8080 and G.7713 is 
     correct.

SG15 to CCAMP
Q14/15-LS1-E dated March 2007
     Regarding call and connection separation the liaison states:
     "We understand that ASON Calls may be implemented
     through full call/connection separation (as in G.7713.3) or
     call/connection 'piggybacking' as in G.7713.2. Please
     confirm that our interpretation of G.8080 and G.7713 is
     correct."  ASON requires full logical separation of the call
     and connection which may be implemented with separate
     or piggybacked call and connection signalling.

We would like to complete this discussion by reiterating that
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt defines mechanisms that
provide full and logical Call/Connection separation. Your initial
interpretation of section 3.2 of draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt
was incorrect and the text states now (and stated then) that "Full and
logical Call and Connection separation is required."

If you have any further concerns about how call and connection separation is
achieved in this work, please do not hesitate to contact us.

Best regards,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP working group
Attachment(s):
No document has been attached

Delivery-date: Wed, 04 Apr 2007 08:57:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Wed, 4 Apr 2007 09:56:46 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

We in BT would also agree with you Julien...a CP is useful (noting that
signalling and routing functions don't have to be lumped together) but
the MP is always essential.

regards, Neil

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of MEURIC Julien=20
> RD-CORE-LAN
> Sent: 04 April 2007 09:45
> To: [email-masked]; Diego Caviglia (GA/ERI)
> Cc: [email-masked]
> Subject: RE: Solicit the comments on LMP Data Channel Status I-D
>=20
>=20
> Hi Dimitri.
>=20
> I must disagree with you. Let us get out of the pure CCAMP=20
> context to come to the real world.
>=20
> In transmission networks, we will see both control and=20
> management planes being used together for a long time. In=20
> transmission networks, operators are used to making manual=20
> operations even if equipments are control plane-enabled:=20
> programmed work, configuration of legacy rings where control=20
> plane does not exist, maintenance... More generally, one=20
> could always find some specific operational cases which need=20
> human intervention but which does not justify the development=20
> of a specific control plane feature. You may try to solve=20
> this problem by saying this pool of resource is "purely"=20
> (provided  this means something in terms of operations)=20
> handled by the control plane and that other pool is not seen;=20
> however, besides the fact that that kind of partitionning=20
> would still be configured manually with possible mistakes,=20
> you would have major drawbacks in terms of operations and=20
> resource optimization.
>=20
> What is proposed in the ID is just a mechanism relying on a=20
> control plane protocol to detect *data plane* discrepencies=20
> which may occur because of the cross-connection nature of the=20
> circuit-switched world and of the manual operations you will=20
> never completely get rid of.
>=20
> Regards,
>=20
> Julien
>=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
>=20
> hi diego
>=20
> not sure to understand, an automated control plane (at the=20
> end the purpose=20
> of this WG) is used to control XC, and other related resource=20
> reservations
>=20
> now you state that there could be manual operations that=20
> fails ??? i think=20
> this simply falls outside the scope of the WG, on the other=20
> hand if some=20
> TS are unproper for cross-connection i assume the CP does not=20
> even take=20
> them into account, as label are downstream assigned where is=20
> the issue ?
>=20
> thanks,
> - d.
>=20
>=20
>=20
>=20
>=20
> "Diego Caviglia \(GA/ERI\)" <[email-masked]>
>=20
> Hi Dimitri,
>            there can an HW problem with the unit and some of=20
> its TS are=20
> not good or for some reason that TS have been cross-connected=20
> by NMS for=20
> error or may for testing at commissioning of the TNE and due to human=20
> error have not been deleted and so on....
>=20
> BR
>=20
> Diego
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]=20
>=20
> diego
>=20
> > I think that the reason wht timeslot 2 is not usable is out of the=20
> > scope of the ID.
>=20
> but this is kernel of the problem, the origin tells where the=20
> solution shall be targeted=20
>=20
> the i-d refers to the deletion case (2.2), fine but there is cleanup=20
> timeout interval to free resources in rsvp
>=20
> thanks,
> -d.
>=20
>=20
>=20
>=20
>=20
> "Diego Caviglia \(GA/ERI\)" <[email-masked]>
>=20
> This was bounced.
> =20
> D
> =20
>=20
> > Hi Dimitri,
> >            my understunding of the ID was that it tries to=20
> > 'synchronize' the status of the timeslots that are facing the same=20
> > link.
> >
> > Otherwise downstream NE can choose a timeslot that is not=20
> good for the=20
> > upstream node
> >
> >
> > NE-A                          NE-B
> > Timeslots                     Timeslots
> > 1-OK                          1-OK
> > 2-OK                          2-KO
> > 3-OK                          3-OK
> > 4-OK                          4-OK
> >
> > So NE-A can choose Timeslot 2 because it see it good while=20
> is not good
> in
> > NE-B.  I think that the reason wht timeslot 2 is not usable=20
> is out of
> the
> > scope of the ID.
> >
> > BR
> >
> > Diego
> >
> >
> >
> >
> >
> >
> > [email-masked] on 03/04/2007 11.57.12
> >
> > diego & dan
> >
> > "Since the error condition can arise from a variety of situations=20
> > (including control plane failure and restart, management plane=20
> > intervention,
> attempt
> > to clean up a partitioned control plane, etc.) we believe that it=20
> > would
> be
> > useful to have optional extensions to LMP to detect and report the=20
> > problem. Resolution of the problem remains an issue for the=20
> management=20
> > plane."
> >
> > we have three classes of "errors" those outside scope of=20
> the CP, those=20
> > resulting from CP operations=20
> (bug-fixing/mis-use/mis-config/etc.) and=20
> > then those that are strictly specific to the LMP and operations
> >
> > only the latter shall be in-scope - all these circular=20
> dependencies we=20
> > are introducing in this control plane are just breaking one of the=20
> > main design principle of networks
> >
> > -> which are the remaining "situations" ?
> >
> > thanks,
> > -d.
> >
> >
> >
> >
> >
> > "Diego Caviglia" <[email-masked]>
> > 03/04/2007 11:35
> >
> >
> > Hi Dan,
> >        as stated in Prague I think that the ID addresses a real=20
> > problem.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > Dan Li <[email-masked]> on 03/04/2007 10.47.58
> >
> >
> > Hi all,
> >
> > In Prague we saw three optical vendors stating that this=20
> I-D addresses=20
> > a real problem that they see in deployed networks. We also saw one
> operator
> > expressing interest in the work.
> >
> > To summarise the problem that we are addressing:
> >
> > Under some circumstances the opposite ends of data links=20
> may get into=20
> > mismatched states. For example, one end of the data link may be
> allocated
> > and cross-connected, while the other end is available for use. This=20
> > represents an error condition.
> >
> > The problem is particularly bad when the data link is a=20
> component link
> of
> > a
> >
> > bundle, because the problem cannot be detected from the TE
> advertisements.
> > Further, existing LMP mechanisms do not allow us to discover the
> problem.
> >
> > If left undetected and unresolved, the situation may lead=20
> to LSP setup=20
> > failures or to misconnection of LSPs.
> >
> > Since the error condition can arise from a variety of situations=20
> > (including
> >
> > control plane failure and restart, management plane intervention,
> attempt
> > to
> > clean up a partitioned control plane, etc.) we believe that=20
> it would=20
> > be useful to have optional extensions to LMP to detect and=20
> report the=20
> > problem.
> >
> > Resolution of the problem remains an issue for the management plane.
> >
> > We would like to hear from people who believe that this is=20
> or is not a=20
> > real
> >
> > problem in the network so that we can judge whether to ask=20
> the chairs=20
> > to make this a WG draft. Best regards,
> >
> >
> > Dan Li
> >
> > Advanced Technology Department
> > Wireline Networking Business Unit
> > Huawei Technologies Co., LTD.
> > Huawei Base, Bantian, Longgang,
> > Shenzhen 518129 P.R.China
> > Tel: +86-755-28973237
> > Fax: +86-755-28972935
>=20
>=20

Delivery-date: Wed, 04 Apr 2007 08:45:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Wed, 4 Apr 2007 10:44:35 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Cc: <[email-masked]>

Hi Dimitri.

I must disagree with you. Let us get out of the pure CCAMP context to =
come to the real world.

In transmission networks, we will see both control and management planes =
being used together for a long time. In transmission networks, operators =
are used to making manual operations even if equipments are control =
plane-enabled: programmed work, configuration of legacy rings where =
control plane does not exist, maintenance... More generally, one could =
always find some specific operational cases which need human =
intervention but which does not justify the development of a specific =
control plane feature.
You may try to solve this problem by saying this pool of resource is =
"purely" (provided  this means something in terms of operations) handled =
by the control plane and that other pool is not seen; however, besides =
the fact that that kind of partitionning would still be configured =
manually with possible mistakes, you would have major drawbacks in terms =
of operations and resource optimization.

What is proposed in the ID is just a mechanism relying on a control =
plane protocol to detect *data plane* discrepencies which may occur =
because of the cross-connection nature of the circuit-switched world and =
of the manual operations you will never completely get rid of.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of [email-masked]

hi diego

not sure to understand, an automated control plane (at the end the =
purpose=20
of this WG) is used to control XC, and other related resource =
reservations

now you state that there could be manual operations that fails ??? i =
think=20
this simply falls outside the scope of the WG, on the other hand if some =

TS are unproper for cross-connection i assume the CP does not even take=20
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are=20
not good or for some reason that TS have been cross-connected by NMS for =

error or may for testing at commissioning of the TNE and due to human=20
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to =
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good =

in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it =
would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the =
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real =
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses =
a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link =

of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would =
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs =
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935

Delivery-date: Wed, 04 Apr 2007 08:32:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Wed, 4 Apr 2007 10:30:58 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Cc: <[email-masked]>

Hi Dimitri.

I agree case 2.2 might be borderline: this single specific case may be
not enough to trigger the proposed solution, but since there are other
drivers, the mechanism introduced could help solving that issue also.

Cheers,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good

in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it
would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses
a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link

of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935

Delivery-date: Wed, 04 Apr 2007 07:41:26 +0000
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Wed, 4 Apr 2007 09:40:53 +0200

diego

what you are stating is that changing the CP state of some local resources =

(at granularity not advertized to neighbors via routing) MAY require=20
re-sync with neighbors such as to prevent label mismatch in case you are=20
enforcing same label in both directions=20

but we have already the min/max reservable subobject in LMP (hence it is a =

pure TS mismatch that you try to detect)=20

on the other side:

as TS where not visible to LMP i fail to see why do not re-sync label=20
space that can be used via signaling on the upstream node then ?

in case of explicit label routing your technique won't work anyway

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
04/04/2007 09:27
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel=20
Status I-D

Hi Dimitri,
           If you are in a SONET/SDH environment I'm pretty sure you'll=20
use bidirectional LSP with upstream and downstream label set to the same=20
value.=20

In that condition labels are chosen by upstream node.

Not sure to get your point.  The possible failures I've highlighted in my=20
e-mail are already managed by CP.  OSPF-TE will advertise that the=20
available bw of, say a STM4 with a 'broken' TS, is not 4 VC4 and 1 VC4=5F4c=
=20
but is 3 VC4 and 0 VC4=5F4c.  The problem is that, for scalability reason, =

it is not advertised which VC4 is not usable.

In my understanding the ID tries to address that case, sharing information =

about which TS is good and which is not at link level.

Ciao

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20
Sent: mercoled=EC 4 aprile 2007 9.19
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D

hi diego

not sure to understand, an automated control plane (at the end the purpose =

of this WG) is used to control XC, and other related resource reservations

now you state that there could be manual operations that fails ??? i think =

this simply falls outside the scope of the WG, on the other hand if some=20
TS are unproper for cross-connection i assume the CP does not even take=20
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
04/04/2007 09:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel=20
Status I-D

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are=20
not good or for some reason that TS have been cross-connected by NMS for=20
error or may for testing at commissioning of the TNE and due to human=20
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20
Sent: marted=EC 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Re: Solicit the comments on LMP Data Channel=20
Status I-D

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to 'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good=20
in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link=20
of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
>=20
***************************************************************************=
************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure,=20
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the=20
sender
> by phone or email immediately and delete it!
>=20
***************************************************************************=
************

Delivery-date: Wed, 04 Apr 2007 07:27:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Wed, 4 Apr 2007 09:27:34 +0200
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Dimitri,
           If you are in a SONET/SDH environment I'm pretty sure you'll =
use bidirectional LSP with upstream and downstream label set to the same =
value. =20

In that condition labels are chosen by upstream node.

Not sure to get your point.  The possible failures I've highlighted in =
my e-mail are already managed by CP.  OSPF-TE will advertise that the =
available bw of, say a STM4 with a 'broken' TS, is not 4 VC4 and 1 =
VC4_4c but is 3 VC4 and 0 VC4_4c.  The problem is that, for scalability =
reason, it is not advertised which VC4 is not usable.

In my understanding the ID tries to address that case, sharing =
information about which TS is good and which is not at link level.

Ciao

Diego

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]=20
Sent: mercoled=EC 4 aprile 2007 9.19
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D

hi diego

not sure to understand, an automated control plane (at the end the =
purpose=20
of this WG) is used to control XC, and other related resource =
reservations

now you state that there could be manual operations that fails ??? i =
think=20
this simply falls outside the scope of the WG, on the other hand if some =

TS are unproper for cross-connection i assume the CP does not even take=20
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
04/04/2007 09:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel=20
Status I-D

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are=20
not good or for some reason that TS have been cross-connected by NMS for =

error or may for testing at commissioning of the TNE and due to human=20
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20
Sent: marted=EC 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Re: Solicit the comments on LMP Data Channel=20
Status I-D

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to =
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good =

in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it =
would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the =
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" =
<dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real =
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses =
a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link =

of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would =
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs =
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
>=20
*************************************************************************=
**************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address =
is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure,=20
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the=20
sender
> by phone or email immediately and delete it!
>=20
*************************************************************************=
**************

Delivery-date: Wed, 04 Apr 2007 07:20:03 +0000
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Wed, 4 Apr 2007 09:19:25 +0200

hi diego

not sure to understand, an automated control plane (at the end the purpose =

of this WG) is used to control XC, and other related resource reservations

now you state that there could be manual operations that fails ??? i think =

this simply falls outside the scope of the WG, on the other hand if some=20
TS are unproper for cross-connection i assume the CP does not even take=20
them into account, as label are downstream assigned where is the issue ?

thanks,
- d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
04/04/2007 09:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: Solicit the comments on LMP Data Channel=20
Status I-D

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are=20
not good or for some reason that TS have been cross-connected by NMS for=20
error or may for testing at commissioning of the TNE and due to human=20
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked]=20
[mailto:[email-masked]]=20
Sent: marted=EC 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Re: Solicit the comments on LMP Data Channel=20
Status I-D

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to 'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good=20
in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link=20
of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
>=20
***************************************************************************=
************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure,=20
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the=20
sender
> by phone or email immediately and delete it!
>=20
***************************************************************************=
************

Delivery-date: Wed, 04 Apr 2007 07:08:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
Date: Wed, 4 Apr 2007 09:05:25 +0200
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Dimitri,
           there can an HW problem with the unit and some of its TS are =
not good or for some reason that TS have been cross-connected by NMS for =
error or may for testing at commissioning of the TNE and due to human =
error have not been deleted and so on....

BR

Diego

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]=20
Sent: marted=EC 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted=20

the i-d refers to the deletion case (2.2), fine but there is cleanup=20
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Re: Solicit the comments on LMP Data Channel=20
Status I-D

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to =
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good =

in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of=20
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention,=20
attempt
> to clean up a partitioned control plane, etc.) we believe that it =
would=20
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the =
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" =
<dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real =
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses =
a
> real problem that they see in deployed networks. We also saw one=20
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be=20
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link =

of
> a
>
> bundle, because the problem cannot be detected from the TE=20
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the=20
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention,=20
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would =
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs =
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
>=20
*************************************************************************=
**************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address =
is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure,=20
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the=20
sender
> by phone or email immediately and delete it!
>=20
*************************************************************************=
**************

Delivery-date: Tue, 03 Apr 2007 19:40:36 +0000
Content-class: urn:content-classes:message
Subject: RE: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt 
Date: Tue, 3 Apr 2007 14:37:37 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This ends the WG Last Call. We'll forward it on to the IESG.
Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Monday, March 05, 2007 3:19 PM
To: [email-masked]
Subject: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt=20

Hi,

This is the start of the WG Last Call for this document. In
consideration of the meeting week, we will extend the Last Call until
March 30th. Please email the authors and the list with any comments,
concerns, or corrections.

Thanks,
Deborah and Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, February 20, 2007 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.

	Title		: A Per-domain path computation method for=20
                          establishing Inter-domain Traffic=20
                          Engineering (TE) Label Switched Paths (LSPs)
	Author(s)	: J. Vasseur, et al.
	Filename	:
draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt
	Pages		: 21
	Date		: 2007-2-20
=09
This document specifies a per-domain path computation technique for
   establishing inter-domain Traffic Engineering (TE) Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
   Paths (LSPs).  In this document a domain refers to a collection of
   network elements within a common sphere of address management or path
   computational responsibility such as IGP areas and Autonomous
   Systems.  Per-domain computation applies where the full path of an
   inter-domain TE LSP cannot be or is not determined at the ingress
   node of the TE LSP, and is not signaled across domain boundaries.
   This is most likely to arise owing to TE visibility limitations.  The
   signaling message indicates the destination and nodes up to the next
   domain boundary.  It may also indicate further domain boundaries or
   domain identifiers.  The path through each domain, possibly including
   the choice of exit point from the domain, must be determined within
   the domain.

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

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-pd-path-comp-04.txt".
=09
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.

Delivery-date: Tue, 03 Apr 2007 19:37:21 +0000
Content-class: urn:content-classes:message
Subject: RE: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Date: Tue, 3 Apr 2007 14:35:38 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This ends the WG Last Call. We'll forward it on to the IESG.
Thanks,
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Monday, March 05, 2007 3:13 PM
To: [email-masked]
Subject: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt=20

Hi,

This is the start of the WG Last Call for this document. In
consideration of the meeting week, we will extend the Last Call until
March 30th. Please email the authors and the list with any comments,
concerns, or corrections.

Thanks,
Deborah and Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, March 01, 2007 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-05.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.

	Title		: Inter domain Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE
extensions
	Author(s)	: A. Ayyangar, et al.
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt
	Pages		: 21
	Date		: 2007-3-1
=09
This document describes procedures and protocol extensions for the
   use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
   signaling in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
   non-packet networks to support the establishment and maintenance of
   Label Switched Paths that cross domain boundaries.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP routing areas, and GMPLS overlay networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-t
e-05.txt

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-rsvp-te-05.txt".
=09
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.

Delivery-date: Tue, 03 Apr 2007 19:35:14 +0000
Content-class: urn:content-classes:message
Subject: RE: WG Last Call: draft-ietf-ccamp-lsp-stitching-05.txt 
Date: Tue, 3 Apr 2007 14:32:31 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This ends the WG Last Call. We'll forward it on to the IESG.
Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Monday, March 05, 2007 3:08 PM
To: [email-masked]
Subject: FW: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt=20

Hi,

This is the start of the WG Last Call for this document. In
consideration of the meeting week, we will extend the Last Call until
March 30th. Please email the authors and the list with any comments,
concerns or corrections.

Thanks,
Deborah and Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, March 01, 2007 6:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.

	Title		: Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
	Author(s)	: A. Ayyangar, et al.
	Filename	: draft-ietf-ccamp-lsp-stitching-05.txt
	Pages		: 19
	Date		: 2007-3-1
=09
In certain scenarios, there may be a need to combine together several
   Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
   Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
   all traffic from one constituent LSP is switched onto the next LSP.
   We will refer to this as "LSP stitching", the key requirement being
   that a constituent LSP not be allocated to more than one e2e LSP.
   The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

   This document describes extensions to the existing GMPLS signaling
   protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs,
   and describes how the LSPs can be managed using the GMPLS signaling
   and routing protocols.

   It may be possible to configure a GMPLS node to switch the traffic
   from an LSP for which it is the egress, to another LSP for which it
   is the ingress, without requiring any signaling or routing extensions
   whatsoever, completely transparent to other nodes.  This will also
   result in LSP stitching in the data plane.  However, this document
   does not cover this scenario of LSP stitching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-05.tx
t

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-lsp-stitching-05.txt".
=09
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.

Delivery-date: Tue, 03 Apr 2007 17:29:29 +0000
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Tue, 3 Apr 2007 19:29:07 +0200

diego

> I think that the reason wht timeslot 2 is not usable is out of the
> scope of the ID.

but this is kernel of the problem, the origin tells where the solution
shall be targeted 

the i-d refers to the deletion case (2.2), fine but there is cleanup 
timeout interval to free resources in rsvp

thanks,
-d.

"Diego Caviglia \(GA/ERI\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
 
        To:     <[email-masked]>
        cc: 
        Subject:        Re: Solicit the comments on LMP Data Channel 
Status I-D

This was bounced.
 
D

> Hi Dimitri,
>            my understunding of the ID was that it tries to 'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good 
in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of 
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention, 
attempt
> to clean up a partitioned control plane, etc.) we believe that it would 
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one 
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be 
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link 
of
> a
>
> bundle, because the problem cannot be detected from the TE 
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the 
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention, 
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
> 
***************************************************************************************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, 
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the 
sender
> by phone or email immediately and delete it!
> 
***************************************************************************************

Delivery-date: Tue, 03 Apr 2007 17:25:10 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "Dan Li" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Tue, 3 Apr 2007 19:23:06 +0200

hi adrian

i am simply pointing out that using LMP as a watch dog for signaling
and routing components bug-fix is a non starter, and errors resulting
from their mis-use but also the errors resulting from the concurrent 
control of the resource / component set falls into the same category

we are left with errors resulting from de-synchronization of the CP
status of data channels - in which condition - can this occur ? and
in which condition there is no resulting information that can not be
used to detect them ?

referring to the draft 2.1 and 2.3 are errors due to the fact the CP
is not in the chain and 2.2 is the fundamental reason for RSVP (soft
state)

so my question what remains ?

thanks,
-d.

"Adrian Farrel" <[email-masked]>
03/04/2007 12:16
Please respond to "Adrian Farrel"
 
        To:     "Diego Caviglia" <[email-masked]>, "Dan Li" 
<[email-masked]>, "ccamp" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc: 
        Subject:        Re: Solicit the comments on LMP Data Channel 
Status I-D

Hi Dimitri,

If I understand you correctly, you are saying that only problems caused by 

the control plane should be detected and/or reported by the control plane. 

Is that what you said?

If so, how do you account for using LMP to verify link configuration, or 
RSVP-TE to report data plane faults?

But perhaps you are simply saying that the control plane should not be 
engineered to handle defects in the control plane (especially 
implementation 
defects). I would agree with you on that point, but I don't think that is 
what Dan is proposing. As far as I understand it, he is covering the case 
where the control plane cannot correctly tidy up after itself, or where 
there has been a misconfiguration through the management plane.

Note that he is not proposing automatic correction of such situations, but 

rather a mechanism for detecting them and reporting them.

A
----- Original Message ----- 
From: <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Dan Li" 
<[email-masked]>; "ccamp" <[email-masked]>
Sent: Tuesday, April 03, 2007 10:57 AM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention, 
attempt
> to clean up a partitioned control plane, etc.) we believe that it would 
be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one 
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be 
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link 
of
> a
>
> bundle, because the problem cannot be detected from the TE 
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the 
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention, 
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
> 
***************************************************************************************
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, 
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the 
sender
> by phone or email immediately and delete it!
> 
***************************************************************************************

Delivery-date: Tue, 03 Apr 2007 13:24:32 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Re: Draft liaison to ITU SG15 on process
Date: Tue, 3 Apr 2007 10:42:34 +0200

Adrian

Yes, a subtle change but for me, better.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>; <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
<[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
<[email-masked]>
Sent: Monday, April 02, 2007 7:37 PM
Subject: Re: Draft liaison to ITU SG15 on process

> Thanks Tom,
>
> How about if the relevant paragraph read...
>
> We appreciate your engagement with this process and we believe that it is to
> the best interests of the industry and to all participants in both
> bodies. The liaison process provides a mechanism to engage between the two
> bodies, and it is clear that the earlier communication occurs, the less the
> chance of misunderstanding or parallel development.
>
> In order to describe the IETF's view of the procedures and processes for
> extending and varying IETF protocols, the IETF has recently published RFC
> 4775 ("Procedures for Protocol Extensions and Variations"). In order to
> describe the mechanisms by which other bodies can influence the development
> of MPLS and GMPLS protocols, the IETF has just consented for publication
> draft-andersson-rtg-gmpls-change-08.txt ("Change Process for Multiprotocol
> Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and
> Procedures"). The net effect of these documents is to give the ITU-T clear
> access into the IETF process and to commit the IETF to work with the ITU-T
> to develop solutions to requirements that originate in the ITU-T.
>
>
> Adrian
>
> ----- Original Message -----
> From: "tom.petch" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
> <[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
> <[email-masked]>
> Sent: Monday, April 02, 2007 5:09 PM
> Subject: Re: Draft liaison to ITU SG15 on process
>
>
> > Adrian
> >
> > No doubt you are familiar with RFC4775, to which you refer, but I would
> > suggest
> > that it may not be of much assistance in this case.
> >
> > It is written in IETF-speak and, as such, may be impenetrable to those
> > who are not already involved in the IETF, and, after spending much of the
> > first
> > eight
> > pages telling people to find an AD/WG and submit an I-D, then mentions in
> > passing that where a liaison exists, then that should be used; which is
> > the case
> > here.
> >
> > So I would suggest amending the reference to it, using it as an example of
> > the
> > IETF's wishes for other SDOs to engage but pointing out that, as it says,
> > as
> > long as we have a liaison, then that is the best place to engage; and as
> > early
> > in the process as possible.
> >
> > I think that the failures, such as they are, arise because of a tendency
> > to
> > produce the polished article, but too late, whereas a back of the fag
> > packet a
> > few months earlier would have been more productive. But this liaison may
> > not be
> > the right place to express more of  that point of view than you are
> > already
> > doing.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Adrian Farrel" <[email-masked]>
> > To: <[email-masked]>
> > Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
> > <[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
> > <[email-masked]>
> > Sent: Thursday, March 29, 2007 1:21 PM
> > Subject: Draft liaison to ITU SG15 on process
> >
> >
> >> Hi,
> >>
> >> One of the larger issues raised by a recent liaison from ITU-T Study
> >> Group
> >> 15 is on process and how we can continue to build a better relationship
> >> between SG15 and CCAMP.
> >>
> >> Here is a draft response.
> >>
> >> Comments please by end of April 5th.
> >>
> >> Thanks,
> >> Adrian and Deborah
> >> ===
> >>
> >> To: ITU-T SG15
> >> From: IETF CCAMP
> >> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross
> >> Callon,
> >> Dave Ward
> >> For Action
> >> Deadline: 25th June 2007
> >>
> >> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP
> >>
> >> CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
> >> responding to ccamp liaison of 21 February 2007". The last paragraphs of
> >> your liaison discuss the cooperative relationship between ITU-T SG15 and
> >> the
> >> IETF's CCAMP working group and we would like to respond to these issues
> >> separate from the technical discussions.
> >>
> >> Over the last few years we have seen an increase in cooperation between
> >> our
> >> organisations, and we believe that this is to the considerable benefit of
> >> the industry. CCAMP has regularly sent a liaison representative to ITU
> >> plenary and interim meetings, and useful comments and feedback have been
> >> received from these meetings as a result of review of IETF
> >> Internet-Drafts
> >> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular
> >> slot
> >> on the CCAMP meeting agenda at each IETF meeting to update the working
> >> group
> >> on the progress of the ITU-T in areas of interest to CCAMP.
> >>
> >> While we consider that the free flow of information and the review
> >> feedback
> >> on CCAMP work to be very valuable, we are also conscious that the
> >> mechanisms
> >> of the ITU-T and IETF are very different. Therefore we make every attempt
> >> to
> >> avoid wasting your precious meeting time, and only ask for review when we
> >> consider the material to be stable and pertinent.
> >>
> >> In your liaison, you say:
> >>
> >>      ITU-T SG 15 has been relying on a collaborative relationship with
> >>      IETF ccamp to provide the protocol support for ASON.  This
> >>      collaborative work should allow the industry to take advantage of
> >>      the different expertise in each of the Standards Development
> >>      Organizations. Q.14/15 has not developed protocol specific
> >>      Recommendations for ASON since 2003, based on an expected
> >>      collaborative technical relationship, in which IETF ccamp would
> >>      provide protocol solutions that fully meet the ITU-T ASON
> >>      requirements.
> >>
> >> We appreciate your engagement with this process and we believe that it is
> >> to
> >> the best interests of the industry and to all participants in both
> >> bodies. In order to crystallise this process, the IETF has recently
> >> published RFC 4775 ("Procedures for Protocol Extensions and Variations")
> >> and
> >> has just consented for publication
> >> draft-andersson-rtg-gmpls-change-08.txt
> >> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
> >> MPLS (GMPLS) Protocols and Procedures"). The net effect of these
> >> documents
> >> is to give the ITU-T clear access into the IETF process and to commit the
> >> IETF to work with the ITU-T to develop solutions to requirements that
> >> originate in the ITU-T.
> >>
> >> You state further:
> >>
> >>      However, the effectiveness of this SDO liaison relationship could
> >>      be improved.
> >>
> >> We agree that there is always room for improvements on both sides. Some
> >> issues will arise from differences in established behaviour within the
> >> two
> >> bodies, and we are always grateful when you point out opportunities to
> >> improve the mechanisms that we have in place. Although neither the ITU-T
> >> nor
> >> the IETF is likely to make a major change to its operational procedures,
> >> there are doubtless very many small areas where improvements could be
> >> made.
> >>
> >> One such area of improvement might be to relax the communication style
> >> and
> >> mechanisms allowing a more free and rapid exchange of technical opinions
> >> amongst the participants. Although this cannot replace the liaison
> >> relationship as a means for exchanging the official and consented views
> >> of
> >> each body, we could gain a lot from increasing the level of discussion
> >> rather than relying on the relatively infrequent use of liaison
> >> statements.
> >> We would welcome your suggestions on how to achieve this - the CCAMP
> >> mailing
> >> list remains open and might be a suitable vehicle for this type of
> >> communication.
> >>
> >> As you go on to say:
> >>
> >>      We observe that IETF ccamp has responded to some of the
> >>      technical issues raised by suggesting that the ITU-T participants
> >>      should provide input directly, to the work in ccamp.  We agree
> >>      that having participants involved in both the  ITU-T and IETF
> >>      improves the communication process.  We would like to confirm
> >>      that this individual participation is not being suggested as a
> >>      substitute for the liaison relationship.  A liaison statement or
> >>      ITU-T Recommendation represents the consensus of the members
> >>      of the ITU-T.  An individual participating in the work of ccamp is
> >>      not authorized to represent or negotiate on behalf of the ITU-T.
> >>
> >> We understand the points you make. Nevertheless, we would like to
> >> continue
> >> to encourage individual participation. Individuals who are interested in
> >> the
> >> development rather than the review of protocol solutions would be well
> >> advised to bring their ideas to CCAMP early in the process. In the same
> >> way,
> >> we would advise individuals interested in the work of the ITU-T to become
> >> involved there and not to wait for the opportunity to review the material
> >> when it is liaised to the IETF as it nears completion.
> >>
> >> You cite a specific area for improvement in your liaison, and we are
> >> grateful for your attempt to isolate specifics since it is far more easy
> >> to learn from examples than from general statements.
> >>
> >>      One particular area for improvement of the liaison relationship is
> >>      communicating the disposition of ITU-T comments related to the
> >>      interpretation of ASON requirements.  For example comments
> >>      provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
> >>      RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
> >>      RFC 4652) were not included in the published RFC and the rational
> >>      for this decision has not been communicated.
> >>
> >> We are disturbed by your identification of these specific concerns at
> >> this
> >> time in our communication. Due to the time that has lapsed since the
> >> events
> >> that you mention, it is hard to provide appropriate and definitive
> >> discussion.
> >>
> >> We believe that the discussion of RFC 4258 and lack of response refers to
> >> a
> >> liaison received from SG15 in February 2004. Although the issues received
> >> full discussion on an open mailing list and included comments from no
> >> fewer
> >> than seven regular Q14/15 participants, and although the design team that
> >> produced the final text of the RFC included Q14/15 participants who could
> >> have reported the agreement and rationale back to Q14/15, we agree that
> >> it
> >> would have been helpful to liaise the outcome of these discussions to you
> >> direct.
> >>
> >> In a subsequent liaison (COM15-LS18) in April 2004, where you stated:
> >>
> >>      Q.14/15 would like to thank the IETF CCAMP WG and
> >>      especially the members of the ASON Routing Requirements
> >>      Design Team for their efforts to understand and capture ASON
> >>      Routing Requirements for the future work in IETF.
> >>
> >>      Q.14/15 would like to continue cooperative work with IETF,
> >>      extending this to the application of routing protocols to support
> >>      the ASON requirements.
> >>
> >> We interpreted these sentences to mean that you were aware of the
> >> completion
> >> of RFC4258 and that you were satisfied with the results.
> >>
> >> Review of the material that led to RFC 4652 was first liaised to CCAMP by
> >> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review
> >> issued
> >> by CCAMP earlier that same month. The liaison from SG15 was marked "For
> >> Information" and our understanding of this label (as noted in section
> >> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the
> >> addressee of something, and expects no response." In the light of the
> >> current situation it would have been wise for the chairs to have
> >> confirmed
> >> that this was really the intended purpose of the liaison, but we should
> >> note
> >> that 50% of the author team for RFC 4652 were regular Q14/15 attendees
> >> who
> >> could have reported the status and decisions (albeit informally) to the
> >> Question.
> >>
> >> Subsequent liaisons on the material of RFC 4652 included:
> >>
> >>      November 2005 (Q12-14 Interim meeting-LS006-E)
> >>      "Q.14/15 ... strongly supports CCAMP's continued work to
> >>      address ASON requirements in the routing protocols."
> >>
> >> Your recent liaison concludes:
> >>
> >>      ITU-T SG15 continues to be interested in providing clarification or
> >>      validation of IETF ccamp interpretation of the ASON requirements
> >>      and therefore request that in future any documents under
> >>      development that are potentially applicable to ASON be liaised so
> >>      that ITU-T can validate the documents against the ASON
> >>      requirements.
> >>
> >>      We look forward to receiving your response and hope that we can
> >>      continue to build a cooperative and productive relationship between
> >>      ccamp and SG 15.
> >>
> >> While we cannot promise to send every piece of work that is potentially
> >> applicable to ASON, we can and will liaise all work where there is a
> >> definitive intention of applicability to ASON.
> >>
> >> CCAMP continues to be grateful to SG15 for its efforts to ensure that the
> >> ASON architecture and requirements are correctly interpreted, and
> >> appreciates that this will lead to protocol solutions that are of value
> >> to
> >> the industry.
> >>
> >> Best regards,
> >>
> >> Adrian Farrel and Deborah Brungard
> >> Co-chairs, IETF CCAMP Working Group
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>

Delivery-date: Tue, 03 Apr 2007 11:27:59 +0000
Content-class: urn:content-classes:message
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
Date: Tue, 3 Apr 2007 13:26:32 +0200
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: <[email-masked]>

This was bounced.
=20
D
=20

> Hi Dimitri,
>            my understunding of the ID was that it tries to =
'synchronize'
> the status of the timeslots that are facing the same link.
>
> Otherwise downstream NE can choose a timeslot that is not good for the
> upstream node
>
>
> NE-A                          NE-B
> Timeslots                     Timeslots
> 1-OK                          1-OK
> 2-OK                          2-KO
> 3-OK                          3-OK
> 4-OK                          4-OK
>
> So NE-A can choose Timeslot 2 because it see it good while is not good =
in
> NE-B.  I think that the reason wht timeslot 2 is not usable is out of =
the
> scope of the ID.
>
> BR
>
> Diego
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> cc:
>
> Subject:    Re: Solicit the comments on LMP Data Channel Status I-D
>
> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention, =
attempt
> to clean up a partitioned control plane, etc.) we believe that it =
would be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the =
main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" =
<dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real =
problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses =
a
> real problem that they see in deployed networks. We also saw one =
operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be =
allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link =
of
> a
>
> bundle, because the problem cannot be detected from the TE =
advertisements.
> Further, existing LMP mechanisms do not allow us to discover the =
problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention, =
attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would =
be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs =
to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
> =
*************************************************************************=
**************
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address =
is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, =
reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the =
sender
> by phone or email immediately and delete it!
> =
*************************************************************************=
**************

Delivery-date: Tue, 03 Apr 2007 10:36:53 +0000
Date: Tue, 03 Apr 2007 18:30:06 +0800
From: Dan Li <[email-masked]>
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
To: Adrian Farrel <[email-masked]>, Diego Caviglia <[email-masked]>, ccamp <[email-masked]>, [email-masked]

Hi Dimitri,

I think Adrian is right. In the draft section 1, it clearly states:

"This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found."

We just want to report the mismatch issue, but not trying to do the automatic correction.

Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Dan Li" <[email-masked]>; "ccamp" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 03, 2007 6:16 PM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

> Hi Dimitri,
> 
> If I understand you correctly, you are saying that only problems caused by 
> the control plane should be detected and/or reported by the control plane. 
> Is that what you said?
> 
> If so, how do you account for using LMP to verify link configuration, or 
> RSVP-TE to report data plane faults?
> 
> But perhaps you are simply saying that the control plane should not be 
> engineered to handle defects in the control plane (especially implementation 
> defects). I would agree with you on that point, but I don't think that is 
> what Dan is proposing. As far as I understand it, he is covering the case 
> where the control plane cannot correctly tidy up after itself, or where 
> there has been a misconfiguration through the management plane.
> 
> Note that he is not proposing automatic correction of such situations, but 
> rather a mechanism for detecting them and reporting them.
> 
> A
> ----- Original Message ----- 
> From: <[email-masked]>
> To: "Diego Caviglia" <[email-masked]>; "Dan Li" 
> <[email-masked]>; "ccamp" <[email-masked]>
> Sent: Tuesday, April 03, 2007 10:57 AM
> Subject: Re: Solicit the comments on LMP Data Channel Status I-D
> 
> 
> > diego & dan
> >
> > "Since the error condition can arise from a variety of situations
> > (including
> > control plane failure and restart, management plane intervention, attempt
> > to clean up a partitioned control plane, etc.) we believe that it would be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> > Resolution of the problem remains an issue for the management plane."
> >
> > we have three classes of "errors" those outside scope of the CP, those
> > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> > then those that are strictly specific to the LMP and operations
> >
> > only the latter shall be in-scope - all these circular dependencies we
> > are introducing in this control plane are just breaking one of the main
> > design principle of networks
> >
> > -> which are the remaining "situations" ?
> >
> > thanks,
> > -d.
> >
> >
> > "Diego Caviglia" <[email-masked]>
> > 03/04/2007 11:35
> >
> >        To:     "Dan Li <danli"
> >        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> > ""[email-masked], Adrian" <adrian", Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> > ""[email-masked], Snigdho" <Snigdho.Bardalai"
> >        Subject:        Re: Solicit the comments on LMP Data Channel
> > Status I-D
> >
> >
> >
> > Hi Dan,
> >        as stated in Prague I think that the ID addresses a real problem.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > Dan Li <[email-masked]> on 03/04/2007 10.47.58
> >
> > To:    ccamp <[email-masked]>
> > cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
> >       <[email-masked]>, Dimitri Papadimitriou
> >       <[email-masked]>, Julien Meuric
> >       <[email-masked]>, Diego Caviglia
> >       <[email-masked]>, "Bardalai, Snigdho"
> >       <[email-masked]>
> >
> > Subject:    Solicit the comments on LMP Data Channel Status I-D
> >
> > Hi all,
> >
> > In Prague we saw three optical vendors stating that this I-D addresses a
> > real problem that they see in deployed networks. We also saw one operator
> > expressing interest in the work.
> >
> > To summarise the problem that we are addressing:
> >
> > Under some circumstances the opposite ends of data links may get into
> > mismatched states. For example, one end of the data link may be allocated
> > and cross-connected, while the other end is available for use. This
> > represents an error condition.
> >
> > The problem is particularly bad when the data link is a component link of
> > a
> >
> > bundle, because the problem cannot be detected from the TE advertisements.
> > Further, existing LMP mechanisms do not allow us to discover the problem.
> >
> > If left undetected and unresolved, the situation may lead to LSP setup
> > failures or to misconnection of LSPs.
> >
> > Since the error condition can arise from a variety of situations
> > (including
> >
> > control plane failure and restart, management plane intervention, attempt
> > to
> > clean up a partitioned control plane, etc.) we believe that it would be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> >
> > Resolution of the problem remains an issue for the management plane.
> >
> > We would like to hear from people who believe that this is or is not a
> > real
> >
> > problem in the network so that we can judge whether to ask the chairs to
> > make this a WG draft.
> > Best regards,
> >
> >
> > Dan Li
> >
> > Advanced Technology Department
> > Wireline Networking Business Unit
> > Huawei Technologies Co., LTD.
> > Huawei Base, Bantian, Longgang,
> > Shenzhen 518129 P.R.China
> > Tel: +86-755-28973237
> > Fax: +86-755-28972935
> > ***************************************************************************************
> >
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address is
> > listed above. Any use of the information contained herein in any way
> > (including, but not limited to, total or partial disclosure, reproduction,
> > or dissemination) by persons other than the intended recipient(s) is
> > prohibited. If you receive this e-mail in error, please notify the sender
> > by phone or email immediately and delete it!
> > ***************************************************************************************
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 
> 
> 
> 

Delivery-date: Tue, 03 Apr 2007 10:18:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, "Dan Li" <[email-masked]>, "ccamp" <[email-masked]>, <[email-masked]>
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
Date: Tue, 3 Apr 2007 11:16:23 +0100
Organization: Old Dog Consulting

Hi Dimitri,

If I understand you correctly, you are saying that only problems caused by 
the control plane should be detected and/or reported by the control plane. 
Is that what you said?

If so, how do you account for using LMP to verify link configuration, or 
RSVP-TE to report data plane faults?

But perhaps you are simply saying that the control plane should not be 
engineered to handle defects in the control plane (especially implementation 
defects). I would agree with you on that point, but I don't think that is 
what Dan is proposing. As far as I understand it, he is covering the case 
where the control plane cannot correctly tidy up after itself, or where 
there has been a misconfiguration through the management plane.

Note that he is not proposing automatic correction of such situations, but 
rather a mechanism for detecting them and reporting them.

A
----- Original Message ----- 
From: <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Dan Li" 
<[email-masked]>; "ccamp" <[email-masked]>
Sent: Tuesday, April 03, 2007 10:57 AM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

> diego & dan
>
> "Since the error condition can arise from a variety of situations
> (including
> control plane failure and restart, management plane intervention, attempt
> to clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
> Resolution of the problem remains an issue for the management plane."
>
> we have three classes of "errors" those outside scope of the CP, those
> resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> then those that are strictly specific to the LMP and operations
>
> only the latter shall be in-scope - all these circular dependencies we
> are introducing in this control plane are just breaking one of the main
> design principle of networks
>
> -> which are the remaining "situations" ?
>
> thanks,
> -d.
>
>
> "Diego Caviglia" <[email-masked]>
> 03/04/2007 11:35
>
>        To:     "Dan Li <danli"
>        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> ""[email-masked], Adrian" <adrian", Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> ""[email-masked], Snigdho" <Snigdho.Bardalai"
>        Subject:        Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
>
> Hi Dan,
>        as stated in Prague I think that the ID addresses a real problem.
>
> BR
>
> Diego
>
>
>
> Dan Li <[email-masked]> on 03/04/2007 10.47.58
>
> To:    ccamp <[email-masked]>
> cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
>       <[email-masked]>, Dimitri Papadimitriou
>       <[email-masked]>, Julien Meuric
>       <[email-masked]>, Diego Caviglia
>       <[email-masked]>, "Bardalai, Snigdho"
>       <[email-masked]>
>
> Subject:    Solicit the comments on LMP Data Channel Status I-D
>
> Hi all,
>
> In Prague we saw three optical vendors stating that this I-D addresses a
> real problem that they see in deployed networks. We also saw one operator
> expressing interest in the work.
>
> To summarise the problem that we are addressing:
>
> Under some circumstances the opposite ends of data links may get into
> mismatched states. For example, one end of the data link may be allocated
> and cross-connected, while the other end is available for use. This
> represents an error condition.
>
> The problem is particularly bad when the data link is a component link of
> a
>
> bundle, because the problem cannot be detected from the TE advertisements.
> Further, existing LMP mechanisms do not allow us to discover the problem.
>
> If left undetected and unresolved, the situation may lead to LSP setup
> failures or to misconnection of LSPs.
>
> Since the error condition can arise from a variety of situations
> (including
>
> control plane failure and restart, management plane intervention, attempt
> to
> clean up a partitioned control plane, etc.) we believe that it would be
> useful to have optional extensions to LMP to detect and report the
> problem.
>
> Resolution of the problem remains an issue for the management plane.
>
> We would like to hear from people who believe that this is or is not a
> real
>
> problem in the network so that we can judge whether to ask the chairs to
> make this a WG draft.
> Best regards,
>
>
> Dan Li
>
> Advanced Technology Department
> Wireline Networking Business Unit
> Huawei Technologies Co., LTD.
> Huawei Base, Bantian, Longgang,
> Shenzhen 518129 P.R.China
> Tel: +86-755-28973237
> Fax: +86-755-28972935
> ***************************************************************************************
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
> ***************************************************************************************
>
>
>
>
>
>
>
>
>
>
> 

Delivery-date: Tue, 03 Apr 2007 09:58:35 +0000
To: "Diego Caviglia" <[email-masked]>, Dan Li <[email-masked]>, ccamp <[email-masked]>
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
From: [email-masked]
Date: Tue, 3 Apr 2007 11:57:12 +0200

diego & dan

"Since the error condition can arise from a variety of situations 
(including
control plane failure and restart, management plane intervention, attempt
to clean up a partitioned control plane, etc.) we believe that it would be
useful to have optional extensions to LMP to detect and report the 
problem.
Resolution of the problem remains an issue for the management plane."

we have three classes of "errors" those outside scope of the CP, those 
resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and 
then those that are strictly specific to the LMP and operations

only the latter shall be in-scope - all these circular dependencies we
are introducing in this control plane are just breaking one of the main
design principle of networks

-> which are the remaining "situations" ?

thanks,
-d.

"Diego Caviglia" <[email-masked]>
03/04/2007 11:35
 
        To:     "Dan Li <danli"
        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"", 
""[email-masked], Adrian" <adrian", Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric", 
""[email-masked], Snigdho" <Snigdho.Bardalai"
        Subject:        Re: Solicit the comments on LMP Data Channel 
Status I-D

Hi Dan,
        as stated in Prague I think that the ID addresses a real problem.

BR

Diego

Dan Li <[email-masked]> on 03/04/2007 10.47.58

To:    ccamp <[email-masked]>
cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
       <[email-masked]>, Dimitri Papadimitriou
       <[email-masked]>, Julien Meuric
       <[email-masked]>, Diego Caviglia
       <[email-masked]>, "Bardalai, Snigdho"
       <[email-masked]>

Subject:    Solicit the comments on LMP Data Channel Status I-D

Hi all,

In Prague we saw three optical vendors stating that this I-D addresses a
real problem that they see in deployed networks. We also saw one operator
expressing interest in the work.

To summarise the problem that we are addressing:

Under some circumstances the opposite ends of data links may get into
mismatched states. For example, one end of the data link may be allocated
and cross-connected, while the other end is available for use. This
represents an error condition.

The problem is particularly bad when the data link is a component link of 
a

bundle, because the problem cannot be detected from the TE advertisements.
Further, existing LMP mechanisms do not allow us to discover the problem.

If left undetected and unresolved, the situation may lead to LSP setup
failures or to misconnection of LSPs.

Since the error condition can arise from a variety of situations 
(including

control plane failure and restart, management plane intervention, attempt
to
clean up a partitioned control plane, etc.) we believe that it would be
useful to have optional extensions to LMP to detect and report the 
problem.

Resolution of the problem remains an issue for the management plane.

We would like to hear from people who believe that this is or is not a 
real

problem in the network so that we can judge whether to ask the chairs to
make this a WG draft.
Best regards,

Dan Li

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28973237
Fax: +86-755-28972935
***************************************************************************************

This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!
***************************************************************************************

Delivery-date: Tue, 03 Apr 2007 08:56:25 +0000
Date: Tue, 03 Apr 2007 16:47:58 +0800
From: Dan Li <[email-masked]>
Subject: Solicit the comments on LMP Data Channel Status I-D
To: ccamp <[email-masked]>
Cc: "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, Julien Meuric <[email-masked]>, Diego Caviglia <[email-masked]>, "Bardalai, Snigdho" <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg)
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT

Hi all,

In Prague we saw three optical vendors stating that this I-D addresses a 
real problem that they see in deployed networks. We also saw one operator 
expressing interest in the work.

To summarise the problem that we are addressing:

Under some circumstances the opposite ends of data links may get into 
mismatched states. For example, one end of the data link may be allocated 
and cross-connected, while the other end is available for use. This 
represents an error condition.

The problem is particularly bad when the data link is a component link of a 
bundle, because the problem cannot be detected from the TE advertisements. 
Further, existing LMP mechanisms do not allow us to discover the problem.

If left undetected and unresolved, the situation may lead to LSP setup 
failures or to misconnection of LSPs.

Since the error condition can arise from a variety of situations (including 
control plane failure and restart, management plane intervention, attempt to 
clean up a partitioned control plane, etc.) we believe that it would be 
useful to have optional extensions to LMP to detect and report the problem. 
Resolution of the problem remains an issue for the management plane.

We would like to hear from people who believe that this is or is not a real 
problem in the network so that we can judge whether to ask the chairs to 
make this a WG draft.

Best regards,

Dan Li

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28973237
Fax: +86-755-28972935
***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

--Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg)
Content-type: text/html; charset=Windows-1252
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=windows-1252">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>In Prague we saw three optical vendors stating that this I-D addresses a 
<BR>real problem that they see in deployed networks. We also saw one operator 
<BR>expressing interest in the work.<BR><BR>To summarise the problem that we are 
addressing:<BR><BR>Under some circumstances the opposite ends of data links may 
get into <BR>mismatched states. For example, one end of the data link may be 
allocated <BR>and cross-connected, while the other end is available for use. 
This <BR>represents an error condition.<BR><BR>The problem is particularly bad 
when the data link is a component link of a <BR>bundle, because the problem 
cannot be detected from the TE advertisements. <BR>Further, existing LMP 
mechanisms do not allow us to discover the problem.<BR><BR>If left undetected 
and unresolved, the situation may lead to LSP setup <BR>failures or to 
misconnection of LSPs.<BR><BR>Since the error condition can arise from a variety 
of situations (including <BR>control plane failure and restart, management plane 
intervention, attempt to <BR>clean up a partitioned control plane, etc.) we 
believe that it would be <BR>useful to have optional extensions to LMP to detect 
and report the problem. <BR>Resolution of the problem remains an issue for the 
management plane.<BR><BR>We would like to hear from people who believe that this 
is or is not a real <BR>problem in the network so that we can judge whether to 
ask the chairs to <BR>make this a WG draft.<BR></DIV>
<DIV>Best regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan Li</DIV>
<DIV>&nbsp;</DIV>
<DIV>Advanced Technology Department<BR>Wireline Networking Business 
Unit<BR>Huawei Technologies Co., LTD.<BR>Huawei Base, Bantian, 
Longgang,<BR>Shenzhen 518129 P.R.China<BR>Tel: +86-755-28973237<BR>Fax: 
+86-755-28972935<BR>***************************************************************************************<BR>This 
e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use 
of the information contained herein in any way (including, but not limited to, 
total or partial disclosure, reproduction, or dissemination) by persons other 
than the intended recipient(s) is prohibited. If you receive this e-mail in 
error, please notify the sender by phone or email immediately and delete 
it!<BR>***************************************************************************************<BR></DIV></BODY></HTML>

--Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg)--

Delivery-date: Mon, 02 Apr 2007 22:52:07 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-02.txt 
Date: Mon, 02 Apr 2007 18:50:02 -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		: Operating Virtual Concatenation (VCAT) and 
                          the Link Capacity Adjustment Scheme (LCAS) 
                          with Generalized Multi-Protocol Label Switching (GMPLS)
	Author(s)	: G. Bernstein, et al.
	Filename	: draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
	Pages		: 16
	Date		: 2007-4-2
	
This document describes requirements for, and use of, the Generalized 
   Multi-Protocol Label Switching (GMPLS) control plane in conjunction 
   with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 
   mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 
   which can be used for hitless dynamic resizing of the inverse 
   multiplex group.  These techniques apply to the Optical Transport 
   Network (OTN), Synchronous Optical Network (SONET), Synchronous 
   Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) 
   signals.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-02.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 02 Apr 2007 17:38:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>, <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Re: Draft liaison to ITU SG15 on process
Date: Mon, 2 Apr 2007 18:37:35 +0100
Organization: Old Dog Consulting

Thanks Tom,

How about if the relevant paragraph read...

We appreciate your engagement with this process and we believe that it is to 
the best interests of the industry and to all participants in both
bodies. The liaison process provides a mechanism to engage between the two 
bodies, and it is clear that the earlier communication occurs, the less the 
chance of misunderstanding or parallel development.

In order to describe the IETF's view of the procedures and processes for 
extending and varying IETF protocols, the IETF has recently published RFC 
4775 ("Procedures for Protocol Extensions and Variations"). In order to 
describe the mechanisms by which other bodies can influence the development 
of MPLS and GMPLS protocols, the IETF has just consented for publication 
draft-andersson-rtg-gmpls-change-08.txt ("Change Process for Multiprotocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and 
Procedures"). The net effect of these documents is to give the ITU-T clear 
access into the IETF process and to commit the IETF to work with the ITU-T 
to develop solutions to requirements that originate in the ITU-T.

Adrian

----- Original Message ----- 
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon" 
<[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner" 
<[email-masked]>
Sent: Monday, April 02, 2007 5:09 PM
Subject: Re: Draft liaison to ITU SG15 on process

> Adrian
>
> No doubt you are familiar with RFC4775, to which you refer, but I would 
> suggest
> that it may not be of much assistance in this case.
>
> It is written in IETF-speak and, as such, may be impenetrable to those
> who are not already involved in the IETF, and, after spending much of the 
> first
> eight
> pages telling people to find an AD/WG and submit an I-D, then mentions in
> passing that where a liaison exists, then that should be used; which is 
> the case
> here.
>
> So I would suggest amending the reference to it, using it as an example of 
> the
> IETF's wishes for other SDOs to engage but pointing out that, as it says, 
> as
> long as we have a liaison, then that is the best place to engage; and as 
> early
> in the process as possible.
>
> I think that the failures, such as they are, arise because of a tendency 
> to
> produce the polished article, but too late, whereas a back of the fag 
> packet a
> few months earlier would have been more productive. But this liaison may 
> not be
> the right place to express more of  that point of view than you are 
> already
> doing.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
> <[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
> <[email-masked]>
> Sent: Thursday, March 29, 2007 1:21 PM
> Subject: Draft liaison to ITU SG15 on process
>
>
>> Hi,
>>
>> One of the larger issues raised by a recent liaison from ITU-T Study 
>> Group
>> 15 is on process and how we can continue to build a better relationship
>> between SG15 and CCAMP.
>>
>> Here is a draft response.
>>
>> Comments please by end of April 5th.
>>
>> Thanks,
>> Adrian and Deborah
>> ===
>>
>> To: ITU-T SG15
>> From: IETF CCAMP
>> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross 
>> Callon,
>> Dave Ward
>> For Action
>> Deadline: 25th June 2007
>>
>> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP
>>
>> CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
>> responding to ccamp liaison of 21 February 2007". The last paragraphs of
>> your liaison discuss the cooperative relationship between ITU-T SG15 and 
>> the
>> IETF's CCAMP working group and we would like to respond to these issues
>> separate from the technical discussions.
>>
>> Over the last few years we have seen an increase in cooperation between 
>> our
>> organisations, and we believe that this is to the considerable benefit of
>> the industry. CCAMP has regularly sent a liaison representative to ITU
>> plenary and interim meetings, and useful comments and feedback have been
>> received from these meetings as a result of review of IETF 
>> Internet-Drafts
>> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular 
>> slot
>> on the CCAMP meeting agenda at each IETF meeting to update the working 
>> group
>> on the progress of the ITU-T in areas of interest to CCAMP.
>>
>> While we consider that the free flow of information and the review 
>> feedback
>> on CCAMP work to be very valuable, we are also conscious that the 
>> mechanisms
>> of the ITU-T and IETF are very different. Therefore we make every attempt 
>> to
>> avoid wasting your precious meeting time, and only ask for review when we
>> consider the material to be stable and pertinent.
>>
>> In your liaison, you say:
>>
>>      ITU-T SG 15 has been relying on a collaborative relationship with
>>      IETF ccamp to provide the protocol support for ASON.  This
>>      collaborative work should allow the industry to take advantage of
>>      the different expertise in each of the Standards Development
>>      Organizations. Q.14/15 has not developed protocol specific
>>      Recommendations for ASON since 2003, based on an expected
>>      collaborative technical relationship, in which IETF ccamp would
>>      provide protocol solutions that fully meet the ITU-T ASON
>>      requirements.
>>
>> We appreciate your engagement with this process and we believe that it is 
>> to
>> the best interests of the industry and to all participants in both
>> bodies. In order to crystallise this process, the IETF has recently
>> published RFC 4775 ("Procedures for Protocol Extensions and Variations") 
>> and
>> has just consented for publication 
>> draft-andersson-rtg-gmpls-change-08.txt
>> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
>> MPLS (GMPLS) Protocols and Procedures"). The net effect of these 
>> documents
>> is to give the ITU-T clear access into the IETF process and to commit the
>> IETF to work with the ITU-T to develop solutions to requirements that
>> originate in the ITU-T.
>>
>> You state further:
>>
>>      However, the effectiveness of this SDO liaison relationship could
>>      be improved.
>>
>> We agree that there is always room for improvements on both sides. Some
>> issues will arise from differences in established behaviour within the 
>> two
>> bodies, and we are always grateful when you point out opportunities to
>> improve the mechanisms that we have in place. Although neither the ITU-T 
>> nor
>> the IETF is likely to make a major change to its operational procedures,
>> there are doubtless very many small areas where improvements could be 
>> made.
>>
>> One such area of improvement might be to relax the communication style 
>> and
>> mechanisms allowing a more free and rapid exchange of technical opinions
>> amongst the participants. Although this cannot replace the liaison
>> relationship as a means for exchanging the official and consented views 
>> of
>> each body, we could gain a lot from increasing the level of discussion
>> rather than relying on the relatively infrequent use of liaison 
>> statements.
>> We would welcome your suggestions on how to achieve this - the CCAMP 
>> mailing
>> list remains open and might be a suitable vehicle for this type of
>> communication.
>>
>> As you go on to say:
>>
>>      We observe that IETF ccamp has responded to some of the
>>      technical issues raised by suggesting that the ITU-T participants
>>      should provide input directly, to the work in ccamp.  We agree
>>      that having participants involved in both the  ITU-T and IETF
>>      improves the communication process.  We would like to confirm
>>      that this individual participation is not being suggested as a
>>      substitute for the liaison relationship.  A liaison statement or
>>      ITU-T Recommendation represents the consensus of the members
>>      of the ITU-T.  An individual participating in the work of ccamp is
>>      not authorized to represent or negotiate on behalf of the ITU-T.
>>
>> We understand the points you make. Nevertheless, we would like to 
>> continue
>> to encourage individual participation. Individuals who are interested in 
>> the
>> development rather than the review of protocol solutions would be well
>> advised to bring their ideas to CCAMP early in the process. In the same 
>> way,
>> we would advise individuals interested in the work of the ITU-T to become
>> involved there and not to wait for the opportunity to review the material
>> when it is liaised to the IETF as it nears completion.
>>
>> You cite a specific area for improvement in your liaison, and we are
>> grateful for your attempt to isolate specifics since it is far more easy
>> to learn from examples than from general statements.
>>
>>      One particular area for improvement of the liaison relationship is
>>      communicating the disposition of ITU-T comments related to the
>>      interpretation of ASON requirements.  For example comments
>>      provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
>>      RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
>>      RFC 4652) were not included in the published RFC and the rational
>>      for this decision has not been communicated.
>>
>> We are disturbed by your identification of these specific concerns at 
>> this
>> time in our communication. Due to the time that has lapsed since the 
>> events
>> that you mention, it is hard to provide appropriate and definitive
>> discussion.
>>
>> We believe that the discussion of RFC 4258 and lack of response refers to 
>> a
>> liaison received from SG15 in February 2004. Although the issues received
>> full discussion on an open mailing list and included comments from no 
>> fewer
>> than seven regular Q14/15 participants, and although the design team that
>> produced the final text of the RFC included Q14/15 participants who could
>> have reported the agreement and rationale back to Q14/15, we agree that 
>> it
>> would have been helpful to liaise the outcome of these discussions to you
>> direct.
>>
>> In a subsequent liaison (COM15-LS18) in April 2004, where you stated:
>>
>>      Q.14/15 would like to thank the IETF CCAMP WG and
>>      especially the members of the ASON Routing Requirements
>>      Design Team for their efforts to understand and capture ASON
>>      Routing Requirements for the future work in IETF.
>>
>>      Q.14/15 would like to continue cooperative work with IETF,
>>      extending this to the application of routing protocols to support
>>      the ASON requirements.
>>
>> We interpreted these sentences to mean that you were aware of the 
>> completion
>> of RFC4258 and that you were satisfied with the results.
>>
>> Review of the material that led to RFC 4652 was first liaised to CCAMP by
>> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review 
>> issued
>> by CCAMP earlier that same month. The liaison from SG15 was marked "For
>> Information" and our understanding of this label (as noted in section
>> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the
>> addressee of something, and expects no response." In the light of the
>> current situation it would have been wise for the chairs to have 
>> confirmed
>> that this was really the intended purpose of the liaison, but we should 
>> note
>> that 50% of the author team for RFC 4652 were regular Q14/15 attendees 
>> who
>> could have reported the status and decisions (albeit informally) to the
>> Question.
>>
>> Subsequent liaisons on the material of RFC 4652 included:
>>
>>      November 2005 (Q12-14 Interim meeting-LS006-E)
>>      "Q.14/15 ... strongly supports CCAMP's continued work to
>>      address ASON requirements in the routing protocols."
>>
>> Your recent liaison concludes:
>>
>>      ITU-T SG15 continues to be interested in providing clarification or
>>      validation of IETF ccamp interpretation of the ASON requirements
>>      and therefore request that in future any documents under
>>      development that are potentially applicable to ASON be liaised so
>>      that ITU-T can validate the documents against the ASON
>>      requirements.
>>
>>      We look forward to receiving your response and hope that we can
>>      continue to build a cooperative and productive relationship between
>>      ccamp and SG 15.
>>
>> While we cannot promise to send every piece of work that is potentially
>> applicable to ASON, we can and will liaise all work where there is a
>> definitive intention of applicability to ASON.
>>
>> CCAMP continues to be grateful to SG15 for its efforts to ensure that the
>> ASON architecture and requirements are correctly interpreted, and
>> appreciates that this will lead to protocol solutions that are of value 
>> to
>> the industry.
>>
>> Best regards,
>>
>> Adrian Farrel and Deborah Brungard
>> Co-chairs, IETF CCAMP Working Group
>>
>>
>>
>
>
>
> 

Delivery-date: Mon, 02 Apr 2007 17:37:05 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Re: Draft liaison to ITU SG15 on process
Date: Mon, 2 Apr 2007 18:32:21 +0200

Adrian

No doubt you are familiar with RFC4775, to which you refer, but I would suggest
that it may not be of much assistance in this case.

It is written in IETF-speak and, as such, may be impenetrable to those
who are not already involved in the IETF, and, after spending much of the first
eight
pages telling people to find an AD/WG and submit an I-D, then mentions in
passing that where a liaison exists, then that should be used; which is the case
here.

So I would suggest amending the reference to it, using it as an example of the
IETF's wishes for other SDOs to engage but pointing out that, as it says, as
long as we have a liaison, then that is the best place to engage; and as early
in the process as possible.

I think that the failures, such as they are, arise because of a tendency to
produce the polished article, but too late, whereas a back of the fag packet a
few months earlier would have been more productive. But this liaison may not be
the right place to express more of  that point of view than you are already
doing.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
<[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
<[email-masked]>
Sent: Thursday, March 29, 2007 1:21 PM
Subject: Draft liaison to ITU SG15 on process

> Hi,
>
> One of the larger issues raised by a recent liaison from ITU-T Study Group
> 15 is on process and how we can continue to build a better relationship
> between SG15 and CCAMP.
>
> Here is a draft response.
>
> Comments please by end of April 5th.
>
> Thanks,
> Adrian and Deborah
> ===
>
> To: ITU-T SG15
> From: IETF CCAMP
> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross Callon,
> Dave Ward
> For Action
> Deadline: 25th June 2007
>
> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP
>
> CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
> responding to ccamp liaison of 21 February 2007". The last paragraphs of
> your liaison discuss the cooperative relationship between ITU-T SG15 and the
> IETF's CCAMP working group and we would like to respond to these issues
> separate from the technical discussions.
>
> Over the last few years we have seen an increase in cooperation between our
> organisations, and we believe that this is to the considerable benefit of
> the industry. CCAMP has regularly sent a liaison representative to ITU
> plenary and interim meetings, and useful comments and feedback have been
> received from these meetings as a result of review of IETF Internet-Drafts
> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular slot
> on the CCAMP meeting agenda at each IETF meeting to update the working group
> on the progress of the ITU-T in areas of interest to CCAMP.
>
> While we consider that the free flow of information and the review feedback
> on CCAMP work to be very valuable, we are also conscious that the mechanisms
> of the ITU-T and IETF are very different. Therefore we make every attempt to
> avoid wasting your precious meeting time, and only ask for review when we
> consider the material to be stable and pertinent.
>
> In your liaison, you say:
>
>      ITU-T SG 15 has been relying on a collaborative relationship with
>      IETF ccamp to provide the protocol support for ASON.  This
>      collaborative work should allow the industry to take advantage of
>      the different expertise in each of the Standards Development
>      Organizations. Q.14/15 has not developed protocol specific
>      Recommendations for ASON since 2003, based on an expected
>      collaborative technical relationship, in which IETF ccamp would
>      provide protocol solutions that fully meet the ITU-T ASON
>      requirements.
>
> We appreciate your engagement with this process and we believe that it is to
> the best interests of the industry and to all participants in both
> bodies. In order to crystallise this process, the IETF has recently
> published RFC 4775 ("Procedures for Protocol Extensions and Variations") and
> has just consented for publication draft-andersson-rtg-gmpls-change-08.txt
> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
> MPLS (GMPLS) Protocols and Procedures"). The net effect of these documents
> is to give the ITU-T clear access into the IETF process and to commit the
> IETF to work with the ITU-T to develop solutions to requirements that
> originate in the ITU-T.
>
> You state further:
>
>      However, the effectiveness of this SDO liaison relationship could
>      be improved.
>
> We agree that there is always room for improvements on both sides. Some
> issues will arise from differences in established behaviour within the two
> bodies, and we are always grateful when you point out opportunities to
> improve the mechanisms that we have in place. Although neither the ITU-T nor
> the IETF is likely to make a major change to its operational procedures,
> there are doubtless very many small areas where improvements could be made.
>
> One such area of improvement might be to relax the communication style and
> mechanisms allowing a more free and rapid exchange of technical opinions
> amongst the participants. Although this cannot replace the liaison
> relationship as a means for exchanging the official and consented views of
> each body, we could gain a lot from increasing the level of discussion
> rather than relying on the relatively infrequent use of liaison statements.
> We would welcome your suggestions on how to achieve this - the CCAMP mailing
> list remains open and might be a suitable vehicle for this type of
> communication.
>
> As you go on to say:
>
>      We observe that IETF ccamp has responded to some of the
>      technical issues raised by suggesting that the ITU-T participants
>      should provide input directly, to the work in ccamp.  We agree
>      that having participants involved in both the  ITU-T and IETF
>      improves the communication process.  We would like to confirm
>      that this individual participation is not being suggested as a
>      substitute for the liaison relationship.  A liaison statement or
>      ITU-T Recommendation represents the consensus of the members
>      of the ITU-T.  An individual participating in the work of ccamp is
>      not authorized to represent or negotiate on behalf of the ITU-T.
>
> We understand the points you make. Nevertheless, we would like to continue
> to encourage individual participation. Individuals who are interested in the
> development rather than the review of protocol solutions would be well
> advised to bring their ideas to CCAMP early in the process. In the same way,
> we would advise individuals interested in the work of the ITU-T to become
> involved there and not to wait for the opportunity to review the material
> when it is liaised to the IETF as it nears completion.
>
> You cite a specific area for improvement in your liaison, and we are
> grateful for your attempt to isolate specifics since it is far more easy
> to learn from examples than from general statements.
>
>      One particular area for improvement of the liaison relationship is
>      communicating the disposition of ITU-T comments related to the
>      interpretation of ASON requirements.  For example comments
>      provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
>      RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
>      RFC 4652) were not included in the published RFC and the rational
>      for this decision has not been communicated.
>
> We are disturbed by your identification of these specific concerns at this
> time in our communication. Due to the time that has lapsed since the events
> that you mention, it is hard to provide appropriate and definitive
> discussion.
>
> We believe that the discussion of RFC 4258 and lack of response refers to a
> liaison received from SG15 in February 2004. Although the issues received
> full discussion on an open mailing list and included comments from no fewer
> than seven regular Q14/15 participants, and although the design team that
> produced the final text of the RFC included Q14/15 participants who could
> have reported the agreement and rationale back to Q14/15, we agree that it
> would have been helpful to liaise the outcome of these discussions to you
> direct.
>
> In a subsequent liaison (COM15-LS18) in April 2004, where you stated:
>
>      Q.14/15 would like to thank the IETF CCAMP WG and
>      especially the members of the ASON Routing Requirements
>      Design Team for their efforts to understand and capture ASON
>      Routing Requirements for the future work in IETF.
>
>      Q.14/15 would like to continue cooperative work with IETF,
>      extending this to the application of routing protocols to support
>      the ASON requirements.
>
> We interpreted these sentences to mean that you were aware of the completion
> of RFC4258 and that you were satisfied with the results.
>
> Review of the material that led to RFC 4652 was first liaised to CCAMP by
> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review issued
> by CCAMP earlier that same month. The liaison from SG15 was marked "For
> Information" and our understanding of this label (as noted in section
> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the
> addressee of something, and expects no response." In the light of the
> current situation it would have been wise for the chairs to have confirmed
> that this was really the intended purpose of the liaison, but we should note
> that 50% of the author team for RFC 4652 were regular Q14/15 attendees who
> could have reported the status and decisions (albeit informally) to the
> Question.
>
> Subsequent liaisons on the material of RFC 4652 included:
>
>      November 2005 (Q12-14 Interim meeting-LS006-E)
>      "Q.14/15 ... strongly supports CCAMP's continued work to
>      address ASON requirements in the routing protocols."
>
> Your recent liaison concludes:
>
>      ITU-T SG15 continues to be interested in providing clarification or
>      validation of IETF ccamp interpretation of the ASON requirements
>      and therefore request that in future any documents under
>      development that are potentially applicable to ASON be liaised so
>      that ITU-T can validate the documents against the ASON
>      requirements.
>
>      We look forward to receiving your response and hope that we can
>      continue to build a cooperative and productive relationship between
>      ccamp and SG 15.
>
> While we cannot promise to send every piece of work that is potentially
> applicable to ASON, we can and will liaise all work where there is a
> definitive intention of applicability to ASON.
>
> CCAMP continues to be grateful to SG15 for its efforts to ensure that the
> ASON architecture and requirements are correctly interpreted, and
> appreciates that this will lead to protocol solutions that are of value to
> the industry.
>
> Best regards,
>
> Adrian Farrel and Deborah Brungard
> Co-chairs, IETF CCAMP Working Group
>
>
>

Delivery-date: Mon, 02 Apr 2007 17:24:42 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ross Callon" <[email-masked]>, "Dave Ward" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Re: Draft liaison to ITU SG15 on process
Date: Mon, 2 Apr 2007 18:09:55 +0200

Adrian

No doubt you are familiar with RFC4775, to which you refer, but I would suggest
that it may not be of much assistance in this case.

It is written in IETF-speak and, as such, may be impenetrable to those
who are not already involved in the IETF, and, after spending much of the first
eight
pages telling people to find an AD/WG and submit an I-D, then mentions in
passing that where a liaison exists, then that should be used; which is the case
here.

So I would suggest amending the reference to it, using it as an example of the
IETF's wishes for other SDOs to engage but pointing out that, as it says, as
long as we have a liaison, then that is the best place to engage; and as early
in the process as possible.

I think that the failures, such as they are, arise because of a tendency to
produce the polished article, but too late, whereas a back of the fag packet a
few months earlier would have been more productive. But this liaison may not be
the right place to express more of  that point of view than you are already
doing.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>; "Ross Callon"
<[email-masked]>; "Dave Ward" <[email-masked]>; "Scott Bradner"
<[email-masked]>
Sent: Thursday, March 29, 2007 1:21 PM
Subject: Draft liaison to ITU SG15 on process

> Hi,
>
> One of the larger issues raised by a recent liaison from ITU-T Study Group
> 15 is on process and how we can continue to build a better relationship
> between SG15 and CCAMP.
>
> Here is a draft response.
>
> Comments please by end of April 5th.
>
> Thanks,
> Adrian and Deborah
> ===
>
> To: ITU-T SG15
> From: IETF CCAMP
> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross Callon,
> Dave Ward
> For Action
> Deadline: 25th June 2007
>
> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP
>
> CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
> responding to ccamp liaison of 21 February 2007". The last paragraphs of
> your liaison discuss the cooperative relationship between ITU-T SG15 and the
> IETF's CCAMP working group and we would like to respond to these issues
> separate from the technical discussions.
>
> Over the last few years we have seen an increase in cooperation between our
> organisations, and we believe that this is to the considerable benefit of
> the industry. CCAMP has regularly sent a liaison representative to ITU
> plenary and interim meetings, and useful comments and feedback have been
> received from these meetings as a result of review of IETF Internet-Drafts
> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular slot
> on the CCAMP meeting agenda at each IETF meeting to update the working group
> on the progress of the ITU-T in areas of interest to CCAMP.
>
> While we consider that the free flow of information and the review feedback
> on CCAMP work to be very valuable, we are also conscious that the mechanisms
> of the ITU-T and IETF are very different. Therefore we make every attempt to
> avoid wasting your precious meeting time, and only ask for review when we
> consider the material to be stable and pertinent.
>
> In your liaison, you say:
>
>      ITU-T SG 15 has been relying on a collaborative relationship with
>      IETF ccamp to provide the protocol support for ASON.  This
>      collaborative work should allow the industry to take advantage of
>      the different expertise in each of the Standards Development
>      Organizations. Q.14/15 has not developed protocol specific
>      Recommendations for ASON since 2003, based on an expected
>      collaborative technical relationship, in which IETF ccamp would
>      provide protocol solutions that fully meet the ITU-T ASON
>      requirements.
>
> We appreciate your engagement with this process and we believe that it is to
> the best interests of the industry and to all participants in both
> bodies. In order to crystallise this process, the IETF has recently
> published RFC 4775 ("Procedures for Protocol Extensions and Variations") and
> has just consented for publication draft-andersson-rtg-gmpls-change-08.txt
> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
> MPLS (GMPLS) Protocols and Procedures"). The net effect of these documents
> is to give the ITU-T clear access into the IETF process and to commit the
> IETF to work with the ITU-T to develop solutions to requirements that
> originate in the ITU-T.
>
> You state further:
>
>      However, the effectiveness of this SDO liaison relationship could
>      be improved.
>
> We agree that there is always room for improvements on both sides. Some
> issues will arise from differences in established behaviour within the two
> bodies, and we are always grateful when you point out opportunities to
> improve the mechanisms that we have in place. Although neither the ITU-T nor
> the IETF is likely to make a major change to its operational procedures,
> there are doubtless very many small areas where improvements could be made.
>
> One such area of improvement might be to relax the communication style and
> mechanisms allowing a more free and rapid exchange of technical opinions
> amongst the participants. Although this cannot replace the liaison
> relationship as a means for exchanging the official and consented views of
> each body, we could gain a lot from increasing the level of discussion
> rather than relying on the relatively infrequent use of liaison statements.
> We would welcome your suggestions on how to achieve this - the CCAMP mailing
> list remains open and might be a suitable vehicle for this type of
> communication.
>
> As you go on to say:
>
>      We observe that IETF ccamp has responded to some of the
>      technical issues raised by suggesting that the ITU-T participants
>      should provide input directly, to the work in ccamp.  We agree
>      that having participants involved in both the  ITU-T and IETF
>      improves the communication process.  We would like to confirm
>      that this individual participation is not being suggested as a
>      substitute for the liaison relationship.  A liaison statement or
>      ITU-T Recommendation represents the consensus of the members
>      of the ITU-T.  An individual participating in the work of ccamp is
>      not authorized to represent or negotiate on behalf of the ITU-T.
>
> We understand the points you make. Nevertheless, we would like to continue
> to encourage individual participation. Individuals who are interested in the
> development rather than the review of protocol solutions would be well
> advised to bring their ideas to CCAMP early in the process. In the same way,
> we would advise individuals interested in the work of the ITU-T to become
> involved there and not to wait for the opportunity to review the material
> when it is liaised to the IETF as it nears completion.
>
> You cite a specific area for improvement in your liaison, and we are
> grateful for your attempt to isolate specifics since it is far more easy
> to learn from examples than from general statements.
>
>      One particular area for improvement of the liaison relationship is
>      communicating the disposition of ITU-T comments related to the
>      interpretation of ASON requirements.  For example comments
>      provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
>      RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
>      RFC 4652) were not included in the published RFC and the rational
>      for this decision has not been communicated.
>
> We are disturbed by your identification of these specific concerns at this
> time in our communication. Due to the time that has lapsed since the events
> that you mention, it is hard to provide appropriate and definitive
> discussion.
>
> We believe that the discussion of RFC 4258 and lack of response refers to a
> liaison received from SG15 in February 2004. Although the issues received
> full discussion on an open mailing list and included comments from no fewer
> than seven regular Q14/15 participants, and although the design team that
> produced the final text of the RFC included Q14/15 participants who could
> have reported the agreement and rationale back to Q14/15, we agree that it
> would have been helpful to liaise the outcome of these discussions to you
> direct.
>
> In a subsequent liaison (COM15-LS18) in April 2004, where you stated:
>
>      Q.14/15 would like to thank the IETF CCAMP WG and
>      especially the members of the ASON Routing Requirements
>      Design Team for their efforts to understand and capture ASON
>      Routing Requirements for the future work in IETF.
>
>      Q.14/15 would like to continue cooperative work with IETF,
>      extending this to the application of routing protocols to support
>      the ASON requirements.
>
> We interpreted these sentences to mean that you were aware of the completion
> of RFC4258 and that you were satisfied with the results.
>
> Review of the material that led to RFC 4652 was first liaised to CCAMP by
> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review issued
> by CCAMP earlier that same month. The liaison from SG15 was marked "For
> Information" and our understanding of this label (as noted in section
> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the
> addressee of something, and expects no response." In the light of the
> current situation it would have been wise for the chairs to have confirmed
> that this was really the intended purpose of the liaison, but we should note
> that 50% of the author team for RFC 4652 were regular Q14/15 attendees who
> could have reported the status and decisions (albeit informally) to the
> Question.
>
> Subsequent liaisons on the material of RFC 4652 included:
>
>      November 2005 (Q12-14 Interim meeting-LS006-E)
>      "Q.14/15 ... strongly supports CCAMP's continued work to
>      address ASON requirements in the routing protocols."
>
> Your recent liaison concludes:
>
>      ITU-T SG15 continues to be interested in providing clarification or
>      validation of IETF ccamp interpretation of the ASON requirements
>      and therefore request that in future any documents under
>      development that are potentially applicable to ASON be liaised so
>      that ITU-T can validate the documents against the ASON
>      requirements.
>
>      We look forward to receiving your response and hope that we can
>      continue to build a cooperative and productive relationship between
>      ccamp and SG 15.
>
> While we cannot promise to send every piece of work that is potentially
> applicable to ASON, we can and will liaise all work where there is a
> definitive intention of applicability to ASON.
>
> CCAMP continues to be grateful to SG15 for its efforts to ensure that the
> ASON architecture and requirements are correctly interpreted, and
> appreciates that this will lead to protocol solutions that are of value to
> the industry.
>
> Best regards,
>
> Adrian Farrel and Deborah Brungard
> Co-chairs, IETF CCAMP Working Group
>
>
>

Delivery-date: Sun, 01 Apr 2007 13:14:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Huub van Helvoort" <[email-masked]>
Cc: "Lam, Hing-Kam \(Kam\)" <[email-masked]>, <[email-masked]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Date: Sun, 1 Apr 2007 12:03:17 +0100
Organization: Old Dog Consulting

Thanks,

I'll do that.

A
----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Lam, Hing-Kam (Kam)" <[email-masked]>; <[email-masked]>
Sent: Saturday, March 31, 2007 10:23 PM
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT

> Hello Adrian,
> 
> You wondered:
> 
>> Huub, Kam,
>> 
>> Should we also liaise the VCAT/LCAS work to Q11/15?
>> 
>> Or is it enough to send it to SG15 and let the TSB work out who should 
>> get it?
> 
> Since you already know that both Q14 and Q11 are involved
> you may as well direct the liaison to both questions.
> 
> Cheers, Huub.
> 
> 
>