Subject: Re: Draft liaison to ITU-T SG 15 : VCAT

From: <[email-masked]>
Date: Thu, 29 Mar 2007 7:37:34 +0000

Hello Adrian,

I agree with what you propose, apart from a small
editorial change, see in-line [hvh]

Cheers, Huub.
------------------------------

> Here is the second draft liaison to go to ITU-T SG15.
> 
> Again, comments by end of 3rd April, please.
> 
> (Plenty more to follow, but we will try to turn them out a few at a time.)
> 
> Thanks,
> Adrian and Deborah
> 
> ===
> 
> To: ITU-T SG15
> From: IETF CCAMP
> Cc: Stephen Trowbridge; Kam Lam; Scott Bradner; Ross Callon; Dave Ward
> Subject: VCAT/LCAS Work in CCAMP
> For Comment
> Deadline: 25th June 2007
> 
> The CCAMP working group thanks you 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 the intention is 
> to enable the use of such mechanisms in a GMPLS network

[hvh] recommendation G.7041 does not contain any VCAT/LCAS
mechanism (it is the GFP definition), G.7042 is the generic LCAS definition. PDH VCAT is defined in G.7043, SDH/SONET VCAT in G.707 and OTN VCAT in G.709.
G.7042, G.7043, G.707 and G.709 are referenced in draft-ietf-ccamp-gmpls-vcat-lcas-01
I propose to remove G.7041 or replace it by G.7043.
(yes, it is in the original SG15 liaison text, but it is not
necessary to repeat the typo)
 
> 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-01.txt.
> Please note, however, that a new version of this draft is currently being 
> prepared by the authors that makes extensive 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 liaise future versions of this Internet-Draft to you as they become 
> available.
> 
> Best regards,
> Adrian Farrel and Deborah Brungard
> Co-chairs, IETF CCAMP Working Group

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Mar 2007 12:39:36 +0100

Thanks Huub,

I will make changes accordingly.

A
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>; "Dave Ward" <[email-masked]>; "Ross 
Callon" <[email-masked]>; "Brungard, Deborah A, ALABS" 
<[email-masked]>
Sent: Thursday, March 29, 2007 8:37 AM
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT

> mechanism (it is the GFP definition), G.7042 is the generic LCAS 
> definition. PDH VCAT is defined in G.7043, SDH/SONET VCAT in G.707 and OTN 
> VCAT in G.709.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Mar 2007 15:46:09 +0100

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?

Thanks,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 31 Mar 2007 23:23:40 +0200

Hello Adrian,

You wondered:

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

Delivery-date: Sat, 31 Mar 2007 21:26:59 +0000
Date: Sat, 31 Mar 2007 23:23:40 +0200
From: Huub van Helvoort <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: "Lam, Hing-Kam \(Kam\)" <[email-masked]>,  [email-masked]
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT

Hello Adrian,

You wondered:

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

Delivery-date: Fri, 30 Mar 2007 18:13:01 +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]>, Deborah Brungard <[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, "New CCAMP RFCs Published" 
Reply-To: Adrian Farrel <[email-masked]>
Date: Fri, 30 Mar 2007 14:10:30 -0400

Title: New CCAMP RFCs Published
Submission Date: 2007-03-30
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=310 

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T SG15(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]>
Deborah Brungard <[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 would like to inform you of
the publication of three new RFCs (Request for Comment) that may
be relevant to your work.

RFC 4801
Title
    Definitions of Textual Conventions for Generalized 
    Multiprotocol Label Switching (GMPLS) Management
Abstract
   This document defines a Management Information Base (MIB) 
   module that contains textual conventions (TCs) to represent
   commonly used Generalized Multiprotocol Label Switching 
   (GMPLS) management information.  The intent is that these 
   textual conventions will be imported and used in GMPLS-
   related MIB modules that would otherwise define their own 
   representations.

RFC 4802
Title
   Generalized Multiprotocol Label Switching (GMPLS) Traffic
   Engineering Management Information Base
Abstract
   This memo defines a portion of the Management Information
   Base (MIB) for use with network management protocols in 
   the Internet community. In particular, it describes managed
   objects for Generalized Multiprotocol Label Switching 
   (GMPLS)-based traffic engineering.

RFC 4803
Title
   Generalized Multiprotocol Label Switching (GMPLS)
   Label Switching Router (LSR) Management Information Base
Abstract
   This memo defines a portion of the Management Information 
   Base (MIB) for use with network management protocols in 
   the Internet community. In particular, it describes managed
   objects to configure and/or monitor a Generalized 
   Multiprotocol Label Switching (GMPLS) Label Switching
   Router (LSR).

All IETF RFCs can be downloaded for free from
http://www.ietf.org/rfc.html

The current work plan and progress status of the CCAMP working group can
be viewed at http://www.ietf.org/html.charters/ccamp-charter.html

As always, the CCAMP working group welcomes questions and discussion
about all of its work from individuals or organisations.

The CCAMP mailing list is open to anyone. Details of subscription can be
found on the CCAMP charter page.

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

Delivery-date: Thu, 29 Mar 2007 22:38:57 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: DISCUSS: draft-ietf-ccamp-gmpls-rsvp-te-call 
Date: Thu, 29 Mar 2007 23:36:30 +0100
Organization: Old Dog Consulting

Hi,

I think we may have reached closure on the security issues with the Call 
I-D.

Adrian
----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2007 5:55 PM
Subject: DISCUSS: draft-ietf-ccamp-gmpls-rsvp-te-call

> Discuss:
> [This discuss does actually have its roots in my previous discuss.  I 
> realize it is not obvious.  There have been a lot of side discussions]
>
> One use case of the call concept raises security concerns.  In
> particular, calls are being proposed so that you can authenticate to a
> call server using an end-to-end notify, get some policy goop and that
> goop can be used for policy decisions like whether to accept your
> call.  The problem is that this creates a situation where new security
> associtaions are required that for the most part typically do not come
> up in RSVP today even though end-to-end notify is already supported.
> That triggers RFC 4107 analysis and a very high probability that
> mandatory automated key management is required.  We don't want to
> block this document on that.
>
>
> I propose the following:
>
> 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 RFC 4107.
>   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.

Delivery-date: Thu, 29 Mar 2007 15:44:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
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]>
Subject: Another draft liaison to SG15: Call/Connection Separation
Date: Thu, 29 Mar 2007 15:53:41 +0100
Organization: Old Dog Consulting

Hi,

A small liaison just to close down on a technical point.

Comments by end of Tuesday 3rd April, please.

Adrian and Deborah

===

To: ITU-T SG15
Cc: Stephen Trowbridge; Kam Lam; Ross Callon; Dave Ward; Scott Bradner
Subject: Call/Connection Separation in ASON and GMPLS
For Comment
Deadline: 11th May 2007

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 - LS 1 - 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
COM 15 - LS 126 - E dated November 2006
     1. 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

Delivery-date: Thu, 29 Mar 2007 14:50:15 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Date: Thu, 29 Mar 2007 15:46:09 +0100
Organization: Old Dog Consulting

Huub, Kam,

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>; "Dave Ward" <[email-masked]>; "Ross 

> editorial change, see in-line [hvh]

Delivery-date: Thu, 29 Mar 2007 11:40:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Date: Thu, 29 Mar 2007 12:39:36 +0100
Organization: Old Dog Consulting

Thanks Huub,

A
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>; "Dave Ward" <[email-masked]>; "Ross 

> editorial change, see in-line [hvh]

Delivery-date: Thu, 29 Mar 2007 11:34:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
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]>
Subject: Draft liaison to ITU SG15 on process
Date: Thu, 29 Mar 2007 12:21:43 +0100
Organization: Old Dog Consulting

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,

Delivery-date: Thu, 29 Mar 2007 11:34:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
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]>
Subject: Update: Draft liaison to ITU-T SG15 : MLN work
Date: Thu, 29 Mar 2007 12:27:17 +0100
Organization: Old Dog Consulting

Someone more awake than I has noticed that a liaison from SG15 in February 
2004 appeared to say that MLN was not of interest to ASON. Although things 
have probably moved on since then, we should check to find out the current 
situation.

So the draft changes as follows...

To: ITU-T SG15
Cc: Stephen Trowbridge; Kam Lam; Scott Bradner; Ross Callon; Dave Ward
Subject: Multi-Layer Networking (MLN) Work in CCAMP
For Action
Deadline: 18th May 2007

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,

Delivery-date: Thu, 29 Mar 2007 07:39:02 +0000
Date: Thu, 29 Mar 2007 7:37:34 +0000
From:  <[email-masked]>
To: [email-masked], Adrian Farrel <[email-masked]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Cc: Scott Bradner <[email-masked]>, Dave Ward <[email-masked]>,  Ross Callon <[email-masked]>,  "Brungard, Deborah A, ALABS" <[email-masked]>
Sensitivity: Normal

Hello Adrian,

Cheers, Huub.

 
> Co-chairs, IETF CCAMP Working Group 

Delivery-date: Thu, 29 Mar 2007 06:26:05 +0000
Date: Thu, 29 Mar 2007 02:24:35 -0400
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
From: Monique Morrow <[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]>

Looks fine  - thanks again!

/m

On 28/3/07 3:26 pm, "Adrian Farrel" <[email-masked]> wrote:

> Hi,

Delivery-date: Thu, 29 Mar 2007 06:25:57 +0000
Date: Thu, 29 Mar 2007 02:23:48 -0400
Subject: Re: Draft liaison to ITU-T SG15 : MLN work
From: Monique Morrow <[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]>

Looks ok Adrian!

/m

On 28/3/07 3:22 pm, "Adrian Farrel" <[email-masked]> wrote:

> Hi,
> 
> Here is the first of a series of proposed liaisons to ITU-T Study Group 15.
> 
> Please comment by end of business 3rd April.
> 
> Thanks,
> Adrian and Deborah
> ====
> To: ITU-T SG15
> Subject: Multi-Layer Networking (MLN) Work in CCAMP
> For Action
> Deadline: 18th May 2007
> 
> 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-extens
> ions-03.txt, 
> but the working group has yet to make a decision about whether to accept
> this as the basis for the work.
> 
> Best regards,

Delivery-date: Wed, 28 Mar 2007 19:54:05 +0000
Content-class: urn:content-classes:message
Subject: Draft minutes - Session II
Date: Wed, 28 Mar 2007 14:52:53 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Here's the minutes of the second session, much thanks to the great notes
of Giles Heron, Julien Meuric, and Tomonori Takeda. Please check them,
comment on missing items or corrections, and start to work on the items
identified (e.g. liaisons).
=20
Thanks,
Deborah and Adrian
=20
--------------------------------
=20
Sixty-eight IETF, Prague, March 2007

Tuesday, March 20, 2007
1300-1500 Afternoon Session I
RTG     ccamp     Common Control and Measurement Plane WG

CCAMP Working Group Agenda Session II
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CHAIRS: Adrian Farrel=20
        Deborah Brungard=20

Note takers: Giles Heron, Julien Meuric, Tomonori Takeda
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
0. Administrivia (chairs) [5, 5/120]

Slides

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

Agenda agreed.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1. Control plane requirements for GELS (Loa and Don) [30, 35/120]

Slides

Background reading
  - draft-andersson-gels-exp-rsvp-te-01.txt
  - draft-fedyk-gmpls-ethernet-pbb-te-00.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Don - Fedyk draft (PBB-TE) is rev of PBT draft.  Tracking IEEE work on
      data plane. Project will be approved imminently in IEEE.  Done in
      appendix as data plane is IEEE-defined.  IETF just defining how to
      use GMPLS for control.

Loa - Andersson draft (GELS-EXP-RSVP-TE) is updated post comments.  Not
      just doc of an experimental implentation (not impl. this version
      yet).  Use GMPLS for "all" modes of connection types (where "all"
      is P2P - not using yet for P2MP though have soln).  Variance with
      Fedyk is have more than one label type.

Don - GELS concluded that needed IEEE data plane.   IEEE doing 802.1Qay.
      IEEE projects are rolled up into larger specs - so Qay will be
      rolled up into Q spec.

Loa - Acreo did 802.1Q-based implementation.  Describes certain
      conditions that we operate under.  Works for 802.1Q.

Don - trying to define superset that will work for other defined
      switching paradigms.

Don - presented "Conventional Ethernet Bridging" and then "Configured
      Ethernet Bridging" where STP is removed and configure connections
      instead. So now have data plane and management plane.  Finally
      GELS - where GMPLS is used to add back the missing control
      plane...

Loa - I looked at Don's pictures and didn't understand them until I
      slept on it!

Don - there is a std for partitioning the VLAN space as part of existing
      project on shortest path bridging...  So will be an official way
      to do it.

Dimitri - when I looked at your "triangle" diagrams.   Issue is we have
          some 802.1 impacts.  Cross-correlation in terms of what you
          can do even if you segment the VLAN space.  That will be the
          major points in terms of getting this accepted by IEEE.

Loa - yes, agree is important to record interactions.  But what has
      happened to me repeatedly is that when I come up with a problem
      and tell the IEEE guys they tell me there's an ongoing project
      that will fix the problem...
      that also needs to be part of documentation...

Don - diagram where remove CP dependencies is part of an IEEE project...

Don - back to GELS motives.  Dave Allen has draft on PW interworking
      with PBT.

Loa - we have draft using MPLS with some G-MPLS extensions on top of L2
      Ethernet and optical L1.  Takes about an hour to learn to
      configure all 3 layers.  If you want to run different layers in
      "augmented" mode where can request services from lower layers you
      have good automatic support here with GMPLS.

Don - We separated components so could e.g. use management plane with
      signalling.  So limited IP control plane for signalling.

Loa - need to be careful not to get packet forwarding through the
      control plane!

Don - LMP is like a superset of 802.1AB link management.  So can
      leverage AB and use LMP.

Stewart - did I hear "sending control plane traffic through the data
          plane"?

Loa - no the reverse.

Stewart - well we mix the two all the time in the IP world

Loa - CP is not dimensioned here to handle data plane traffic.  If you
      don't get costs on links you'll advertise the CP links into the
      data plane.

Adrian - issue is that is bad to send data traffic down control "
         channel", not control "plane"

Kireeti - issue here is that GMPLS is out-of-band, MPLS is in-band CP.

Zafar - how do you solve this?  In GMPLS we normally have completely
        separated CP network and data network.  So no way data can get
        into control network.

Loa - problem here is how do you define "completely different".  Is
      totally separated in that no other IP connectivity between
      Ethernet LSRS than control plane but rides on same wavelengths
      etc.

Adrian - could use one fibre for control and one for data?  Alternative
         seems to be to implement the LSRs correctly so they don't
         forward data on control channel.

Loa - so this is the issue of vendors' routers + inexperience setting up
      IP networks.

Dimitri - problem here is that always left flexibility as to how to
          route the IP traffic.  Not been work in CCAMP since inception.
          Something unintelligable...

Loa - model we used for other data planes works quite well...

Don - GELS axioms.  Some discussion on list on asymmetric b/w
      reservation.  Idea is to fully exploit what Ethernet data plane
      can do - hence choice of VID configuration or VID+MAC
      configuration...

Dimitri - PBB-TE being done in IEEE.  Not speaking about labels in IEEE?

Don - yes, don't call things "labels" in IEEE.

Dimitri - we know IEEE will speak of bridging.  Are we forward looking
          about what IEEE will do?

Don - we took details of what IEEE is doing out, partly because is not
      an official project yet.

Adrian - assumption is that if we go back to IEEE and say we've started
         on a CP to control this sort of switching and they say "no",
         then we'll stop.

Dimitri - if PBB-TE is bridging with TE then doesn't it mean this sort
          of config is acceptable for bridging.

Loa - yes you can do this from a management station.

Loa - ATM forum talked about ATM headers.  It was only in IETF that we
      talked about ATM labels.

Dimitri - we know PBB is operating.  We don't know about PBB-TE at this
          point. Would like more info on how their initial framework is
          detailed.

Dave - given that PBB and PBB-TE can work together we won't alter the
       semantics of MAC addresses.

Don - pretty far along.  Point is taken that we're not defining a data
      plane here but are using a defined one.

Loa - we know how .1Q, .1ad, .1ah etc. work.  Will be amendments to .1Q.
      If we expect something new to turn up we have to consider that
      now.  But according to IEEE credo all new standards will be
      backwards-compatible.

Dimitri - are we relying on backwards-compatibility of bridging to make
          these steps now?

Don - yes.

Don - (Types of LSPs).  Been looking at P2P and P2MP in our draft.  Loa
      can talk to the other aspects.  Terminology differences.

Loa - there is shared forwarding in .1Q.  Rely on source address to have
      an identity that is extended to exactly where things are going.
      In our mindset we drop the source address (not sure is right thing
      to do).  So then have a MP2P LSP.  Is largely overlapping with
      what Don talks about as P2P.  We have done experiments on MP2MP
      LSP.  Standard IEEE VLAN.  Same VLAN configured on multiple ports
      and turn on learning/STP etc. once set up.  But basically a
      standard VLAN.  Possible to configure it pretty quickly with
      scripts etc. (as need to reset testbed several times a day).

Igor - my understanding of PBB is single source.

Loa - not implemented PBT.  What I've done is .1Q plus a couple of
      deltas we find in most switches.

Igor - so don't require single source for the connection...

Loa - only use VLAN ID and dest address to point to an LSP.

George -  When you say .1Q do you mean .1ad Provider Bridges?  Are you
          doing QinQ?

Loa - no.  Just using one Q tag.  Though the next step is QinQ.  Behaves
      the same way as the start of an MPLS tunnel.  Set it up and put
      traffic in.

Kireeti - what signalling do you use for MP2P and MP2MP LSPs?
          Signalling or provisioning?

Loa - All signalled except MP2MP (which is set up with a script - mgmt
      plane).

Kireeti - so what signalling do you use for MP2P?  Do you swap VLANs?

Loa - no, same VLAN through LSP.  That's one of the differences with
      what we did earlier.

Don - changes we need in Gen label request for Ethernet.

Dimitri - Quesiton on MP2P techniques.  Is Loa's implemantation
          compatible with Don's?

Loa - need to compare and clarify.  We can do P2P with MAC and dest addr
      and then allow or not allow merging.  Need to sort out terminology
      for shared forwarding.

Don - our view of MP2P is shared forwarding.  Two independent LSPs that
      share the same label at the merge point.  No difference
      signalling-wise if they don't share the label.

Kireeti - so basically MP2P LSP is multiple P2P LSPs that happen to
          share the last few hops.

Igor - is MP2P same as N x P2P which merge at same destination.

Don - "shared forwarding" is two individual LSPs sharing same tail-end
       label.

George - do all sources use same dest address?  And how do you avoid
         paths that criss-cross?

Loa - criss-cross can be solved in routing protocol.  Once you merge you
      merge.

George - so not sending explicit path in RSVP message.

Loa - send explicit path to merge point, but once resolve is same as an
      existing path we allow you to merge onto it unless we set that you
      can't do it.

Adrian - George and I need to work on this.  MP2P-TE needs to be solved
         in a generalised way for MPLS, GMPLS and GELS.

George - this sounds a little non-standard as compared to what RSVP-TE
         does at the moment.

Loa - I admit to that.

George - so you have full ERO and then if you hit a merge point and
         merge is allowed then you merge?

Loa - yes.  And don't have b/w reservations.  If TSPEC is the same can
      merge.

Don - shared forwarding is a limited version of merging.  No merging of
      b/w etc.  More definition required around this term in the
      documentation.

Loa - what you can accuse me of is using RSVP-TE in an LDP fashion.  We
      admit this is not standard.  We are building our experimental
      platform.  If what we do is good then fine, of not will change
      it...

Loa - this slide (Gen Label Request) is additions, not changes.

Don - using Dimitri's T-spec as a good starting point.

Don - 2 diags stolen from Dave Allen as to where this is applicable:
      1) PBB net with edge and core bridges offering a native Ethernet
         VLAN over the top.  Looks like VPLS but is all native Ethernet.
      2) case like a PW for aggregation.

Loa - my comparible picture shows network from "above" and "the side".
      Yellow part is GELS.  So have MPLS over GELS over X?  X !=3D =
optical
      switches in this testbed.

Igor - you said GELS could help for optical networks.

Loa - was a bit more careful than that.  When we get people into our
      network we want to do test incorporation.  Want to help people
      understand the idea.  The operational paradigms of the layers are
      very close.  If you want inter-layer signalling that works over
      UNI.

Igor - so in your opinion the CP similarity helps integration.

Loa - yes, helps operational side at least.

Igor - so people need to learn less?  If familiar with optical CP can
       learn Ethernet CP?

Igor - you also said GELS helped interwork configured Ethernet with
       MPLS. What did you mean?  I read it as it helps by removing MPLS.
       Is that correct?

Don - is interfacing Ethernet MAN to an MPLS network.

Igor - I don't see MPLS here.

Don - is in the WAN.

Dimitri - Where does the LSP start and finish in these diagrams?  Is it
          an S-PVC mode or an SVC mode.

Loa - in our network Ethernet LSP starts at Ethernet I/F of the IP
      router. Optical LSP starts on Optical interface of Ethenret
      switch.

Dimitri - is is always a switched mode from access to S-PE?

Don - in this case would have a PW that could be terminated or stitched.
      You can always choose to terminate and then ?

Dimitri - this is one of the limitations in UNI deployments today.  Do
          we gain something by only having a switched mode that goes
          router to router, or do we need a mode that goes edge to edge.
          So from ingress PE to egress PE that doesn't impact the IP
          routers (S-PVC mode rather than SVC mode).  When I look at
          usage of GMPLS we may need to consider both modes.

Adrian - don't see anything in protocol that prohibits either mode.  If
         something shows up then should flag it as we need to keep both
         modes available.

Dimitri - asking other way round.  If we only have switched mode then
          can only deploy GMPLS on nodes that today aren't able to do
          it.  I'm stating about our experience of deployment...  That's
          a concern.  Let's look at today's access nodes...

Loa - I've kind of lost the Q?  I suggest you write the Q down and put
      it on the list...

Don - we don't need to add that much to GMPLS.  Next step is to add a
      milestone for WG charter for experimental GELS spec (Loa's
      suggestion).  Add milestone to develop a spec for GELS
      signalling/routing (combined suggestion).

Adrian - at all future meets GELS will be at end of agenda and you can
         carry on in your own time.  Think we're premature for milestone
         requests.  Both of you can continue experimental work, but
         doesn't come into WG quite yet.  Rules still apply as to how to
         bring stuff into WG.  Consider yourselves lucky that you were
         allowed to present this.  Rules say that if you believe you
         have an IEEE-conformant data plane then we liase to IEEE and
         say that we wish to control it, is that ok?

Loa - brought 802.1Q.

Adrian - just say "please" ;-)  let's talk offline, I need to understand
         the dataplane we're liasing a request about...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
2. ARP over GMPLS (Zafar) [10, 45/120]

Slides

Background reading
  - draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Zafar went over the slides, explaining changes and requesting to be a
WG I-D. Suggest to use tunnel interface address for ARP request.

Lou - Why is it different from other p-to-p link between routers?

Zafar - This is ethernet, so need ARP.

Lou - It exists without GMPLS, right? Is your solution applicable to
      those spaces?

Zafar - We never have two addresses for the same physical address, this
        is what you see in GMPLS.

Lou - The issue of p-to-p ethernet is new for some router vendors?

Zafar - Typically we don't use unnumbered ethernet IF. The second point
        is that we typically don't use two addresses.

Lou - The first point is just unnumbered ethernet, and some vendors
      don't understand it. Sounds like it is not CCAMP issue.

Zafar - Why? We are using signaling.

Lou - That is the second problem.

Lou - The second problem sounds like GMPLS stuff. But it seems just a
      broken implementation.

Zafar - It is unclear implementation.

Lou - What category do you intend for this I-D?

Zafar - BCP.

Igor - Where does the optical LSP start and end?

Zafar - Between routers.
Igor - Where is the ethernet connection?

Zafar - It is also netween routers

Igor - What type of connection?

Dimitri - Good point. You can carry anything over optical LSP, so need
          to be sure whether we want to say framing etc.

Deborah - Good discussion. Igor raised a good question - is the
          connection optical or ethernet. Take it to the list.

Adrian - (To Zafar) Please drive the discussion so we get progress
         before the next IETF.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
3. Traffic Engineering Extensions to OSPF in support of inter-AS TE
(Mach Chen) [10, 55/120]

Slides

Background reading
  - draft-chen-ccamp-ospf-interas-te-extension-01.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Mach went over the slides, explaining motivations and protocol
extensions.

Yakov - Overlap with OSPF auto-discovery in L1VPN. Encourage you to look
        at L1VPN WG.

JP - You say this is mandatory for BRPC, please clarify in which case
     you may need it. Can you also make sure you do a cut and paste of
     the "not to do" slide into the draft.  The draft is fine.  Want to
     make sure that the draft tells us what we're not trying to do to
     prevent people coming up with silly ideas. Are you writing down in
     the document that not doing TE aggregation?

Mach - Yes.

Acee - Could you replace extensions to OSPF to extensions to OSPF-TE?
       Add OSPFv3 for refernece as well. This should be applicable to
       both, but need to define if that is the case. Also not sure I
       agree that it should be bundled with L1VPN autodiscovery.

Stewart Bryant - The reason for ASs and BGP, etc, is for info hiding.
                 Can we make sure that you are not feeding private
                 information?

Adrian - doesn't that follow from saying that don't share TE info
         outside AS?

Stewart- Yes, but need to be v. strict...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
4. Bidirectional LSPs with asymmetric bandwidth requirements
(Attila) [10, 65/120]

Slides

Background reading
  - draft-takacs-asym-bw-lsp-00.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Attila went over the slides explaining motivations, options for
achieving this, and futher works.

Zafar - can you explain why you need both LSPs to follow the same route?

Attila - in some scenarios is beneficial to do that for management and a
couple of other issues.

Zafar - think Q is back to requirements of draft.  I think you need to
        spell out more on the application why you need same path.

Julien - I agree that co-routed asymmetrical services is needed.  But
         you may have missed possible scenario where you could associate
         bidirectional LSP at ingress.

Lou - I think Zafar has a good point.  Before we jump into
      implementation need to say that this is a needed service and that
      what we have today is not sufficient.  We did bidirectional
      symmetric service because the transport network needed it.  if we
      don't have such a transport network then what we have here may be
      sufficient.

Attila - this extension is an optional optimisation.  Not a requirement

Lou - so need to enumerate the cases where it's useful and what the
      benefit is.

Rowen Soloman - sometimes bundling 2 unidirectional LSPs and doing low
                level config of egress traffic management is complex.
                but want to see a relationship between this new object
                and CAC funtionality.  When do you go to CAC to reserve
                b/w for the alternate direction?  When is error sent if
                there's insufficient b/w.

Attila - this is implementation Q.

Rowen - would like to see recommendation.

Igor - like to see whether we need such service.  If have service that
       is symmetrical in all contexts except b/w then this might be
       reasonable.  The reason for bidirectional LSP wasn't just driven
       by technology but also by benefits in setup time and recovery.
       Much easier to handle one bidirectional LSP than a combination of
       two LSPs.

Attila - so summary is: do we have a strong use-case for this?  Need
         mailing list discussion.

Lucy - need to think about P2MP as an application.

Dimitri - What is P2MP asymetric bidirectional LSP about?

Lucy - Discuss offline.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
5. Data Channel Status using LMP (Dan) [10, 75/120]

Slides

Background reading
  - draft-li-ccamp-confirm-data-channel-status-01.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Dan went over the slides, explaining changes and protocol extensions

Adrian - We don't have many people doing LMP here, but two on this
         draft. Who in the room read this? -> 5
         Any strong feeling against? None, but...

Zafar - Raised some concern

Dan - Have you read this I-D?

Zafar - Some comments. Personally not sure about requirements. Not sure
        if the group has enough interest to solve this problem.

Adrian- we do have to be sure we're solving a problem that needs
        solving. Just because vendors are on the draft doesn't mean they
        intend to implement and deploy.  Would like feedback from
        carriers as to whether this is a real problem and whether they'd
        look to LMP to solve it.

Diego - We have implemented LMP. This draft solves a real problem.

Julien - Feel that this is an interesting issue to solve. This may be
         specific to transmission devices. Not really issue for packet
         networks.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
6. LSP Dynamical Provisioning Performance Metrics in GMPLS Networks
(Guoying Zhang) [10, 85/120]

Slides

Background reading
  - draft-xie-ccamp-lsp-dppm-00.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Guoying went over the slides, explaining motivations and open issues.

Adrian - is this project alive, or complete?  Is the draft + the
         research  finished?

Guoying - project is still going.  Want to do work on e.g. multipoint
          LSPs and rerouting.

Adrian - feedback you want from group is questions, also what else the
         group would like measured?

Guoying - also whether the group thinks this is useful.

Adrian - please comment/discuss on mic or on list.

Zafar - why is graceful release delay important?

Guoying - why graceful, or why release?

Zafar - why is graceful release delay important?

Guoying - release delay is important as both setup and release impact
          the application performance.  if release is not good then
          won't meet requirements.  So need to define performance for
          release.  Only looking at graceful release here as forced
          release will cause problems anyway...

Lucy - when you talk about control plane management, is that just
       signalling or also data plane setup?

Guoying - only CP setup time today. Issues with control/data sync.
          hard to measure the sync.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
7. Transport Resource Management and Time-Based Bandwidth Services
(Lucy Yong) [10, 95/120]

Slides

Background reading
  - draft-yong-ccamp-ason-gmpls-autobw-service-00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Lucy went over the slides, explaining motivations and asking the group
whether this is interesting.

Dimitri - what shall we standardise here?

Lucy - we need to have a CP that can handle reservation.

Dimitri - is there something today that prevents you using this model?
          What do we need to standardise here (where we work on
          protocols)?

Adrian - yes, we do protocols.  In order to decide if we need a protocol
         we need to see what architecture we're trying to build.  If we
         can solve the architecture with existing protocols then we're
         done.  If we need new protocol then we need to do it (either in
         CCAMP or elesewhere).  But before we even define the arch we
         need to answer Lucy's Q of whether this is something we need to
         solve.

Lucy - I don't think the current protocol and architecture lets you do
       this.

Dimitri - what prevents us today from saying we'd establish a connection
          at a given point in time?

Lucy - all three options today don't work.

Zafar - can't see what we need beyond what GMPLS provides.

Lucy - your connection request doesn't have a future time in it.

Zafar - there are so many ways you could do it.  Nothing to do with
        protocol.

Lucy - carriers currently rely on management plane to do it.  If we have
       a CP then how do we combine them?

Zafar - local decision?

Lucy - A network resource you need to reserve.  Signalling doesn't let
       you know time.

Zafar - can take offline...

Rowen - you do signalling to future allocate resources? So do you keep
        full state of future services?

Lucy - we can work that out in implementation.

Rowen - do you keep states in network for services that aren't running?
        That's a major scaling issue.

Lucy - that's an implementation issue.

George - It's a major scaling issue in building a switch.  Also issues
         in terms of recovering stuff in event of failure.  Better to
         leave stuff in the mgmt system and have CP as a slave.

Lucy - we already have PCE etc. so don't need to embed this in the nodes

George - when pull out of network, it is mgmt plane.

Lucy - PCE is out of network but is CP.

George - PCE isn't part of GMPLS CP.  Not suggesting we put this in
         routing and signalling?  E.g. signal with RSVP-TE ahead of
         time?

Lucy - there are different ways to implement this, not suggesting one
       here.

George - don't think is good idea to put this in the switches.  Topology
         may change between making request and reserving it.  So not
         very useful to embed the info too close to where you're going
         to deploy it.

Lucy - I agree.

George - two things need to happen before we consider this.  (1) need to
         hear from SPs that it's a real need.  Not many SPs want to keep
         dark fibre around to light up instantaneously.  (2) need to
         clarify the architecture in terms of what is control and what
         is management...

Gert - we have application like this running for two years.  Never had
       req. from service provider to put anything in the control plane.
       So doubt if this is useful...

Dimitri - I have one question.  where shall I put the resource
          management state.  If I don't see a cost/benefit ratio which
          is better than what we do today then won't do it.  There is a
          temptation to make the control plane have all the features of
          the management plane - really dangerous as end up with a
          distributed management plane...

Adrian - Keep hearing people say don't put mgmt plane in CP.  I think I
         heard Lucy say that too. So we all agreed...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
8. CCAMP Liaison responses (chairs) [25, 120/120]
  - OIF Signaling for MEF Requirements
  - OIF VLAN ID Requirements
  - OIF Interworking Cookbook
  - SG15 Related

Slides

Background reading
  - CCAMP incoming correspondence
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Dropped from the agenda due to lack of time.
Adrian - please look at slides on liaison work.

------_=_NextPart_001_01C77172.ACFFD779
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=3D335084319-28032007>Here's =
the minutes=20
of the second session, much thanks to the great notes of Giles Heron, =
Julien=20
Meuric, and Tomonori Takeda. Please check them, comment on missing items =
or=20
corrections, and start to work on the items identified (e.g.=20
liaisons).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D335084319-28032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D335084319-28032007>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D335084319-28032007>Deborah and=20
Adrian</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D335084319-28032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D335084319-28032007>--------------------------------</SPAN></FONT>=
</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D335084319-28032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D335084319-28032007>Sixty-eight IETF,=20
Prague, March 2007<BR><BR>Tuesday, March 20, 2007<BR>1300-1500 Afternoon =
Session=20
I<BR>RTG&nbsp;&nbsp;&nbsp;&nbsp; ccamp&nbsp;&nbsp;&nbsp;&nbsp; Common =
Control=20
and Measurement Plane WG<BR><BR>CCAMP Working Group Agenda Session=20
II<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>CHAIRS: Adrian Farrel=20
<[email-masked]><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Deborah=20
Brungard <[email-masked]><BR><BR>Note takers: Giles Heron, Julien =
Meuric,=20
Tomonori =
Takeda<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<BR>0. Administrivia (chairs) [5,=20
5/120]<BR><BR>Slides<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR>Agenda=20
agreed.<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>1.=20
Control plane requirements for GELS (Loa and Don) [30,=20
35/120]<BR><BR>Slides<BR><BR>Background reading<BR>&nbsp; -=20
draft-andersson-gels-exp-rsvp-te-01.txt<BR>&nbsp; -=20
draft-fedyk-gmpls-ethernet-pbb-te-00.txt<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR>Don=20
- Fedyk draft (PBB-TE) is rev of PBT draft.&nbsp; Tracking IEEE work=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; data plane. Project will be =
approved=20
imminently in IEEE.&nbsp; Done in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
appendix as=20
data plane is IEEE-defined.&nbsp; IETF just defining how=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use GMPLS for control.<BR><BR>Loa - =

Andersson draft (GELS-EXP-RSVP-TE) is updated post comments.&nbsp;=20
Not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; just doc of an experimental =
implentation=20
(not impl. this version<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; yet).&nbsp; =
Use GMPLS=20
for "all" modes of connection types (where=20
"all"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is P2P - not using yet for P2MP =
though=20
have soln).&nbsp; Variance with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fedyk =
is have=20
more than one label type.<BR><BR>Don - GELS concluded that needed IEEE =
data=20
plane.&nbsp;&nbsp; IEEE doing =
802.1Qay.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IEEE=20
projects are rolled up into larger specs - so Qay will=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rolled up into Q spec.<BR><BR>Loa - =
Acreo=20
did 802.1Q-based implementation.&nbsp; Describes=20
certain<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; conditions that we operate=20
under.&nbsp; Works for 802.1Q.<BR><BR>Don - trying to define superset =
that will=20
work for other defined<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; switching=20
paradigms.<BR><BR>Don - presented "Conventional Ethernet Bridging" and =
then=20
"Configured<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ethernet Bridging" where =
STP is=20
removed and configure connections<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
instead. So=20
now have data plane and management plane.&nbsp;=20
Finally<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GELS - where GMPLS is used to =
add back=20
the missing control<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
plane...<BR><BR>Loa - I=20
looked at Don's pictures and didn't understand them until=20
I<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slept on it!<BR><BR>Don - there is a =
std for=20
partitioning the VLAN space as part of=20
existing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; project on shortest path=20
bridging...&nbsp; So will be an official =
way<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
to do it.<BR><BR>Dimitri - when I looked at your "triangle"=20
diagrams.&nbsp;&nbsp; Issue is we=20
have<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; some =
802.1=20
impacts.&nbsp; Cross-correlation in terms of what=20
you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can do =
even if you=20
segment the VLAN space.&nbsp; That will be=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; major =
points in=20
terms of getting this accepted by IEEE.<BR><BR>Loa - yes, agree is =
important to=20
record interactions.&nbsp; But what =
has<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
happened to me repeatedly is that when I come up with a=20
problem<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and tell the IEEE guys they =
tell me=20
there's an ongoing project<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that will =
fix the=20
problem...<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that also needs to be part =
of=20
documentation...<BR><BR>Don - diagram where remove CP dependencies is =
part of an=20
IEEE project...<BR><BR>Don - back to GELS motives.&nbsp; Dave Allen has =
draft on=20
PW interworking<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with PBT.<BR><BR>Loa - =
we have=20
draft using MPLS with some G-MPLS extensions on top of=20
L2<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ethernet and optical L1.&nbsp; =
Takes about=20
an hour to learn to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configure all 3=20
layers.&nbsp; If you want to run different layers=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "augmented" mode where can request =
services=20
from lower layers you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have good =
automatic=20
support here with GMPLS.<BR><BR>Don - We separated components so could =
e.g. use=20
management plane with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
signalling.&nbsp; So=20
limited IP control plane for signalling.<BR><BR>Loa - need to be careful =
not to=20
get packet forwarding through the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
control=20
plane!<BR><BR>Don - LMP is like a superset of 802.1AB link =
management.&nbsp; So=20
can<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leverage AB and use =
LMP.<BR><BR>Stewart -=20
did I hear "sending control plane traffic through the=20
data<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
plane"?<BR><BR>Loa - no the reverse.<BR><BR>Stewart - well we mix the =
two all=20
the time in the IP world<BR><BR>Loa - CP is not dimensioned here to =
handle data=20
plane traffic.&nbsp; If you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; don't get =
costs on=20
links you'll advertise the CP links into =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
data plane.<BR><BR>Adrian - issue is that is bad to send data traffic =
down=20
control "<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channel", =
not=20
control "plane"<BR><BR>Kireeti - issue here is that GMPLS is =
out-of-band, MPLS=20
is in-band CP.<BR><BR>Zafar - how do you solve this?&nbsp; In GMPLS we =
normally=20
have completely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separated =
CP=20
network and data network.&nbsp; So no way data can=20
get<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; into control=20
network.<BR><BR>Loa - problem here is how do you define "completely=20
different".&nbsp; Is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; totally separated =
in that=20
no other IP connectivity between<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Ethernet LSRS=20
than control plane but rides on same=20
wavelengths<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; etc.<BR><BR>Adrian - could =
use one=20
fibre for control and one for data?&nbsp;=20
Alternative<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; seems to =
be to=20
implement the LSRs correctly so they=20
don't<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forward data =
on=20
control channel.<BR><BR>Loa - so this is the issue of vendors' routers + =

inexperience setting up<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP=20
networks.<BR><BR>Dimitri - problem here is that always left flexibility =
as to=20
how to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; route =
the IP=20
traffic.&nbsp; Not been work in CCAMP since=20
inception.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Something=20
unintelligable...<BR><BR>Loa - model we used for other data planes works =
quite=20
well...<BR><BR>Don - GELS axioms.&nbsp; Some discussion on list on =
asymmetric=20
b/w<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reservation.&nbsp; Idea is to =
fully=20
exploit what Ethernet data plane<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can =
do -=20
hence choice of VID configuration or =
VID+MAC<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
configuration...<BR><BR>Dimitri - PBB-TE being done in IEEE.&nbsp; Not =
speaking=20
about labels in IEEE?<BR><BR>Don - yes, don't call things "labels" in=20
IEEE.<BR><BR>Dimitri - we know IEEE will speak of bridging.&nbsp; Are we =
forward=20
looking<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about =
what=20
IEEE will do?<BR><BR>Don - we took details of what IEEE is doing out, =
partly=20
because is not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an official project=20
yet.<BR><BR>Adrian - assumption is that if we go back to IEEE and say =
we've=20
started<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on a CP to =
control=20
this sort of switching and they say=20
"no",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then we'll=20
stop.<BR><BR>Dimitri - if PBB-TE is bridging with TE then doesn't it =
mean this=20
sort<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of config =
is=20
acceptable for bridging.<BR><BR>Loa - yes you can do this from a =
management=20
station.<BR><BR>Loa - ATM forum talked about ATM headers.&nbsp; It was =
only in=20
IETF that we<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; talked about ATM=20
labels.<BR><BR>Dimitri - we know PBB is operating.&nbsp; We don't know =
about=20
PBB-TE at this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
point.=20
Would like more info on how their initial framework=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
detailed.<BR><BR>Dave - given that PBB and PBB-TE can work together we =
won't=20
alter the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; semantics of MAC=20
addresses.<BR><BR>Don - pretty far along.&nbsp; Point is taken that =
we're not=20
defining a data<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; plane here but are =
using a=20
defined one.<BR><BR>Loa - we know how .1Q, .1ad, .1ah etc. work.&nbsp; =
Will be=20
amendments to .1Q.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If we expect =
something new=20
to turn up we have to consider that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
now.&nbsp;=20
But according to IEEE credo all new standards will=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
backwards-compatible.<BR><BR>Dimitri - are=20
we relying on backwards-compatibility of bridging to=20
make<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; these =
steps=20
now?<BR><BR>Don - yes.<BR><BR>Don - (Types of LSPs).&nbsp; Been looking =
at P2P=20
and P2MP in our draft.&nbsp; Loa<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can =
talk to=20
the other aspects.&nbsp; Terminology differences.<BR><BR>Loa - there is =
shared=20
forwarding in .1Q.&nbsp; Rely on source address to=20
have<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an identity that is extended to =
exactly=20
where things are going.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In our mindset =
we drop=20
the source address (not sure is right =
thing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to=20
do).&nbsp; So then have a MP2P LSP.&nbsp; Is largely overlapping=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; what Don talks about as =
P2P.&nbsp; We=20
have done experiments on MP2MP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LSP.&nbsp;=20
Standard IEEE VLAN.&nbsp; Same VLAN configured on multiple=20
ports<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and turn on learning/STP etc. =
once set=20
up.&nbsp; But basically a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; standard =
VLAN.&nbsp;=20
Possible to configure it pretty quickly =
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
scripts etc. (as need to reset testbed several times a day).<BR><BR>Igor =
- my=20
understanding of PBB is single source.<BR><BR>Loa - not implemented =
PBT.&nbsp;=20
What I've done is .1Q plus a couple of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
deltas=20
we find in most switches.<BR><BR>Igor - so don't require single source =
for the=20
connection...<BR><BR>Loa - only use VLAN ID and dest address to point to =
an=20
LSP.<BR><BR>George -&nbsp; When you say .1Q do you mean .1ad Provider=20
Bridges?&nbsp; Are =
you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
doing QinQ?<BR><BR>Loa - no.&nbsp; Just using one Q tag.&nbsp; Though =
the next=20
step is QinQ.&nbsp; Behaves<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the same =
way as=20
the start of an MPLS tunnel.&nbsp; Set it up and=20
put<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; traffic in.<BR><BR>Kireeti - what=20
signalling do you use for MP2P and MP2MP=20
LSPs?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Signalling or=20
provisioning?<BR><BR>Loa - All signalled except MP2MP (which is set up =
with a=20
script - mgmt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; plane).<BR><BR>Kireeti - =
so what=20
signalling do you use for MP2P?&nbsp; Do you swap VLANs?<BR><BR>Loa - =
no, same=20
VLAN through LSP.&nbsp; That's one of the differences=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; what we did earlier.<BR><BR>Don - =
changes=20
we need in Gen label request for Ethernet.<BR><BR>Dimitri - Quesiton on =
MP2P=20
techniques.&nbsp; Is Loa's=20
implemantation<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

compatible with Don's?<BR><BR>Loa - need to compare and clarify.&nbsp; =
We can do=20
P2P with MAC and dest addr<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and then =
allow or=20
not allow merging.&nbsp; Need to sort out=20
terminology<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for shared =
forwarding.<BR><BR>Don=20
- our view of MP2P is shared forwarding.&nbsp; Two independent LSPs=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; share the same label at the merge =

point.&nbsp; No difference<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
signalling-wise if=20
they don't share the label.<BR><BR>Kireeti - so basically MP2P LSP is =
multiple=20
P2P LSPs that happen=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; share the =
last few=20
hops.<BR><BR>Igor - is MP2P same as N x P2P which merge at same=20
destination.<BR><BR>Don - "shared forwarding" is two individual LSPs =
sharing=20
same tail-end<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
label.<BR><BR>George - do=20
all sources use same dest address?&nbsp; And how do you=20
avoid<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; paths that=20
criss-cross?<BR><BR>Loa - criss-cross can be solved in routing =
protocol.&nbsp;=20
Once you merge you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
merge.<BR><BR>George - so=20
not sending explicit path in RSVP message.<BR><BR>Loa - send explicit =
path to=20
merge point, but once resolve is same as =
an<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
existing path we allow you to merge onto it unless we set that=20
you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can't do it.<BR><BR>Adrian - =
George and I=20
need to work on this.&nbsp; MP2P-TE needs to be=20
solved<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in a =
generalised way=20
for MPLS, GMPLS and GELS.<BR><BR>George - this sounds a little =
non-standard as=20
compared to what =
RSVP-TE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
does at the moment.<BR><BR>Loa - I admit to that.<BR><BR>George - so you =
have=20
full ERO and then if you hit a merge point=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; merge is allowed =
then=20
you merge?<BR><BR>Loa - yes.&nbsp; And don't have b/w =
reservations.&nbsp; If=20
TSPEC is the same can<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
merge.<BR><BR>Don -=20
shared forwarding is a limited version of merging.&nbsp; No merging=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b/w etc.&nbsp; More definition =
required=20
around this term in the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
documentation.<BR><BR>Loa - what you can accuse me of is using RSVP-TE =
in an LDP=20
fashion.&nbsp; We<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; admit this is not=20
standard.&nbsp; We are building our=20
experimental<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; platform.&nbsp; If what =
we do is=20
good then fine, of not will change<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
it...<BR><BR>Loa - this slide (Gen Label Request) is additions, not=20
changes.<BR><BR>Don - using Dimitri's T-spec as a good starting=20
point.<BR><BR>Don - 2 diags stolen from Dave Allen as to where this is=20
applicable:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) PBB net with edge and =
core=20
bridges offering a native=20
Ethernet<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VLAN over =
the=20
top.&nbsp; Looks like VPLS but is all native=20
Ethernet.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) case like a PW for=20
aggregation.<BR><BR>Loa - my comparible picture shows network from =
"above" and=20
"the side".<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yellow part is GELS.&nbsp; =
So have=20
MPLS over GELS over X?&nbsp; X !=3D =
optical<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
switches in this testbed.<BR><BR>Igor - you said GELS could help for =
optical=20
networks.<BR><BR>Loa - was a bit more careful than that.&nbsp; When we =
get=20
people into our<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; network we want to do =
test=20
incorporation.&nbsp; Want to help =
people<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
understand the idea.&nbsp; The operational paradigms of the layers=20
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; very close.&nbsp; If you want =
inter-layer=20
signalling that works over<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
UNI.<BR><BR>Igor -=20
so in your opinion the CP similarity helps integration.<BR><BR>Loa - =
yes, helps=20
operational side at least.<BR><BR>Igor - so people need to learn =
less?&nbsp; If=20
familiar with optical CP can<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
learn=20
Ethernet CP?<BR><BR>Igor - you also said GELS helped interwork =
configured=20
Ethernet with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS. What did you =

mean?&nbsp; I read it as it helps by removing=20
MPLS.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Is that =
correct?<BR><BR>Don - is=20
interfacing Ethernet MAN to an MPLS network.<BR><BR>Igor - I don't see =
MPLS=20
here.<BR><BR>Don - is in the WAN.<BR><BR>Dimitri - Where does the LSP =
start and=20
finish in these diagrams?&nbsp; Is=20
it<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an S-PVC =
mode or an=20
SVC mode.<BR><BR>Loa - in our network Ethernet LSP starts at Ethernet =
I/F of the=20
IP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; router. Optical LSP starts on =
Optical=20
interface of Ethenret<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
switch.<BR><BR>Dimitri -=20
is is always a switched mode from access to S-PE?<BR><BR>Don - in this =
case=20
would have a PW that could be terminated or=20
stitched.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; You can always choose to =
terminate=20
and then ?<BR><BR>Dimitri - this is one of the limitations in UNI =
deployments=20
today.&nbsp; =
Do<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we=20
gain something by only having a switched mode that=20
goes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; router to =
router,=20
or do we need a mode that goes edge to=20
edge.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So from =
ingress=20
PE to egress PE that doesn't impact the=20
IP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; routers =
(S-PVC mode=20
rather than SVC mode).&nbsp; When I look=20
at<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; usage of =
GMPLS we=20
may need to consider both modes.<BR><BR>Adrian - don't see anything in =
protocol=20
that prohibits either mode.&nbsp;=20
If<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; something shows =
up then=20
should flag it as we need to keep=20
both<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; modes=20
available.<BR><BR>Dimitri - asking other way round.&nbsp; If we only =
have=20
switched mode =
then<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can=20
only deploy GMPLS on nodes that today aren't able to=20
do<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it.&nbsp; =
I'm=20
stating about our experience of deployment...&nbsp;=20
That's<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=20
concern.&nbsp; Let's look at today's access nodes...<BR><BR>Loa - I've =
kind of=20
lost the Q?&nbsp; I suggest you write the Q down and=20
put<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it on the list...<BR><BR>Don - we =
don't=20
need to add that much to GMPLS.&nbsp; Next step is to add=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; milestone for WG charter for =
experimental=20
GELS spec (Loa's<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; suggestion).&nbsp; =
Add=20
milestone to develop a spec for GELS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
signalling/routing (combined suggestion).<BR><BR>Adrian - at all future =
meets=20
GELS will be at end of agenda and you=20
can<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; carry on in your =
own=20
time.&nbsp; Think we're premature for=20
milestone<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
requests.&nbsp;=20
Both of you can continue experimental work,=20
but<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; doesn't come =
into WG=20
quite yet.&nbsp; Rules still apply as to how=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bring stuff into=20
WG.&nbsp; Consider yourselves lucky that you=20
were<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; allowed to =
present=20
this.&nbsp; Rules say that if you believe=20
you<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have an =
IEEE-conformant=20
data plane then we liase to IEEE=20
and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; say that we wish =
to=20
control it, is that ok?<BR><BR>Loa - brought 802.1Q.<BR><BR>Adrian - =
just say=20
"please" ;-)&nbsp; let's talk offline, I need to=20
understand<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
dataplane=20
we're liasing a request=20
about...<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>2.=20
ARP over GMPLS (Zafar) [10, 45/120]<BR><BR>Slides<BR><BR>Background=20
reading<BR>&nbsp; -=20
draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt<BR>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<BR><BR>Zafar=20
went over the slides, explaining changes and requesting to be a<BR>WG =
I-D.=20
Suggest to use tunnel interface address for ARP request.<BR><BR>Lou - =
Why is it=20
different from other p-to-p link between routers?<BR><BR>Zafar - This is =

ethernet, so need ARP.<BR><BR>Lou - It exists without GMPLS, right? Is =
your=20
solution applicable to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; those=20
spaces?<BR><BR>Zafar - We never have two addresses for the same physical =

address, this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is what you =
see in=20
GMPLS.<BR><BR>Lou - The issue of p-to-p ethernet is new for some router=20
vendors?<BR><BR>Zafar - Typically we don't use unnumbered ethernet IF. =
The=20
second point<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is that we =
typically=20
don't use two addresses.<BR><BR>Lou - The first point is just unnumbered =

ethernet, and some vendors<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; don't =
understand=20
it. Sounds like it is not CCAMP issue.<BR><BR>Zafar - Why? We are using=20
signaling.<BR><BR>Lou - That is the second problem.<BR><BR>Lou - The =
second=20
problem sounds like GMPLS stuff. But it seems just=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; broken implementation.<BR><BR>Zafar =
- It is=20
unclear implementation.<BR><BR>Lou - What category do you intend for =
this=20
I-D?<BR><BR>Zafar - BCP.<BR><BR>Igor - Where does the optical LSP start =
and=20
end?<BR><BR>Zafar - Between routers.<BR>Igor - Where is the ethernet=20
connection?<BR><BR>Zafar - It is also netween routers<BR><BR>Igor - What =
type of=20
connection?<BR><BR>Dimitri - Good point. You can carry anything over =
optical=20
LSP, so need<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to be=20
sure whether we want to say framing etc.<BR><BR>Deborah - Good =
discussion. Igor=20
raised a good question - is=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connection =
optical=20
or ethernet. Take it to the list.<BR><BR>Adrian - (To Zafar) Please =
drive the=20
discussion so we get=20
progress<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; before the =
next=20
IETF.<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>3.=20
Traffic Engineering Extensions to OSPF in support of inter-AS =
TE<BR>(Mach Chen)=20
[10, 55/120]<BR><BR>Slides<BR><BR>Background reading<BR>&nbsp; -=20
draft-chen-ccamp-ospf-interas-te-extension-01.txt<BR>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>=
<BR>Mach=20
went over the slides, explaining motivations and=20
protocol<BR>extensions.<BR><BR>Yakov - Overlap with OSPF auto-discovery =
in=20
L1VPN. Encourage you to =
look<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at=20
L1VPN WG.<BR><BR>JP - You say this is mandatory for BRPC, please clarify =
in=20
which case<BR>&nbsp;&nbsp;&nbsp;&nbsp; you may need it. Can you also =
make sure=20
you do a cut and paste of<BR>&nbsp;&nbsp;&nbsp;&nbsp; the "not to do" =
slide into=20
the draft.&nbsp; The draft is fine.&nbsp; Want =
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
make sure that the draft tells us what we're not trying to do=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp; prevent people coming up with silly =
ideas. Are=20
you writing down in<BR>&nbsp;&nbsp;&nbsp;&nbsp; the document that not =
doing TE=20
aggregation?<BR><BR>Mach - Yes.<BR><BR>Acee - Could you replace =
extensions to=20
OSPF to extensions to OSPF-TE?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Add=20
OSPFv3 for refernece as well. This should be applicable=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; both, but need to define if =
that is=20
the case. Also not sure I<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; agree =
that it=20
should be bundled with L1VPN autodiscovery.<BR><BR>Stewart Bryant - The =
reason=20
for ASs and BGP, etc, is for info=20
hiding.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Can we make sure that you are not feeding=20
private<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
information?<BR><BR>Adrian - doesn't that follow from saying that don't =
share TE=20
info<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; outside=20
AS?<BR><BR>Stewart- Yes, but need to be v.=20
strict...<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>4.=20
Bidirectional LSPs with asymmetric bandwidth requirements<BR>(Attila) =
[10,=20
65/120]<BR><BR>Slides<BR><BR>Background reading<BR>&nbsp; -=20
draft-takacs-asym-bw-lsp-00.txt<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR>Attila=20
went over the slides explaining motivations, options for<BR>achieving =
this, and=20
futher works.<BR><BR>Zafar - can you explain why you need both LSPs to =
follow=20
the same route?<BR><BR>Attila - in some scenarios is beneficial to do =
that for=20
management and a<BR>couple of other issues.<BR><BR>Zafar - think Q is =
back to=20
requirements of draft.&nbsp; I think you need=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; spell out more on the=20
application why you need same path.<BR><BR>Julien - I agree that =
co-routed=20
asymmetrical services is needed.&nbsp;=20
But<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you may have =
missed=20
possible scenario where you could=20
associate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
bidirectional LSP=20
at ingress.<BR><BR>Lou - I think Zafar has a good point.&nbsp; Before we =
jump=20
into<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementation need to say that =
this is a=20
needed service and that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; what we have =
today is=20
not sufficient.&nbsp; We did =
bidirectional<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
symmetric service because the transport network needed it.&nbsp; if=20
we<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; don't have such a transport network =
then=20
what we have here may be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
sufficient.<BR><BR>Attila - this extension is an optional =
optimisation.&nbsp;=20
Not a requirement<BR><BR>Lou - so need to enumerate the cases where it's =
useful=20
and what the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; benefit is.<BR><BR>Rowen =
Soloman=20
- sometimes bundling 2 unidirectional LSPs and doing=20
low<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
level config of egress traffic management is=20
complex.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
but want to see a relationship between this new=20
object<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
and CAC funtionality.&nbsp; When do you go to CAC to=20
reserve<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
b/w for the alternate direction?&nbsp; When is error sent=20
if<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
there's insufficient b/w.<BR><BR>Attila - this is implementation =
Q.<BR><BR>Rowen=20
- would like to see recommendation.<BR><BR>Igor - like to see whether we =
need=20
such service.&nbsp; If have service =
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
is symmetrical in all contexts except b/w then this might=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reasonable.&nbsp; The reason =
for=20
bidirectional LSP wasn't just =
driven<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by=20
technology but also by benefits in setup time and=20
recovery.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Much easier to handle =
one=20
bidirectional LSP than a combination =
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
two LSPs.<BR><BR>Attila - so summary is: do we have a strong use-case =
for=20
this?&nbsp; Need<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mailing=20
list discussion.<BR><BR>Lucy - need to think about P2MP as an=20
application.<BR><BR>Dimitri - What is P2MP asymetric bidirectional LSP=20
about?<BR><BR>Lucy - Discuss=20
offline.<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>5.=20
Data Channel Status using LMP (Dan) [10, =
75/120]<BR><BR>Slides<BR><BR>Background=20
reading<BR>&nbsp; -=20
draft-li-ccamp-confirm-data-channel-status-01.txt<BR>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>=
<BR>Dan=20
went over the slides, explaining changes and protocol =
extensions<BR><BR>Adrian -=20
We don't have many people doing LMP here, but two on=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft. Who in =
the room=20
read this? -&gt; 5<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Any=20
strong feeling against? None, but...<BR><BR>Zafar - Raised some=20
concern<BR><BR>Dan - Have you read this I-D?<BR><BR>Zafar - Some =
comments.=20
Personally not sure about requirements. Not=20
sure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if the group has =
enough=20
interest to solve this problem.<BR><BR>Adrian- we do have to be sure =
we're=20
solving a problem that =
needs<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
solving. Just because vendors are on the draft doesn't mean=20
they<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; intend to implement =
and=20
deploy.&nbsp; Would like feedback=20
from<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; carriers as to =
whether this=20
is a real problem and whether=20
they'd<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; look to LMP to =
solve=20
it.<BR><BR>Diego - We have implemented LMP. This draft solves a real=20
problem.<BR><BR>Julien - Feel that this is an interesting issue to =
solve. This=20
may be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specific to=20
transmission devices. Not really issue for=20
packet<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
networks.<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>6.=20
LSP Dynamical Provisioning Performance Metrics in GMPLS =
Networks<BR>(Guoying=20
Zhang) [10, 85/120]<BR><BR>Slides<BR><BR>Background reading<BR>&nbsp; -=20
draft-xie-ccamp-lsp-dppm-00.txt<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR>Guoying=20
went over the slides, explaining motivations and open =
issues.<BR><BR>Adrian - is=20
this project alive, or complete?&nbsp; Is the draft +=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; research&nbsp;=20
finished?<BR><BR>Guoying - project is still going.&nbsp; Want to do work =
on e.g.=20
multipoint<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LSPs and=20
rerouting.<BR><BR>Adrian - feedback you want from group is questions, =
also what=20
else the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; group would =
like=20
measured?<BR><BR>Guoying - also whether the group thinks this is=20
useful.<BR><BR>Adrian - please comment/discuss on mic or on =
list.<BR><BR>Zafar -=20
why is graceful release delay important?<BR><BR>Guoying - why graceful, =
or why=20
release?<BR><BR>Zafar - why is graceful release delay =
important?<BR><BR>Guoying=20
- release delay is important as both setup and release=20
impact<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
application=20
performance.&nbsp; if release is not good=20
then<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; won't =
meet=20
requirements.&nbsp; So need to define performance=20
for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
release.&nbsp;=20
Only looking at graceful release here as=20
forced<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; release =
will=20
cause problems anyway...<BR><BR>Lucy - when you talk about control plane =

management, is that just<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
signalling or=20
also data plane setup?<BR><BR>Guoying - only CP setup time today. Issues =
with=20
control/data =
sync.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
hard to measure the=20
sync.<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>7.=20
Transport Resource Management and Time-Based Bandwidth Services<BR>(Lucy =
Yong)=20
[10, 95/120]<BR><BR>Slides<BR><BR>Background reading<BR>&nbsp; -=20
draft-yong-ccamp-ason-gmpls-autobw-service-00<BR>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR=
>Lucy=20
went over the slides, explaining motivations and asking the =
group<BR>whether=20
this is interesting.<BR><BR>Dimitri - what shall we standardise=20
here?<BR><BR>Lucy - we need to have a CP that can handle=20
reservation.<BR><BR>Dimitri - is there something today that prevents you =
using=20
this model?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
What do we=20
need to standardise here (where we work=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
protocols)?<BR><BR>Adrian - yes, we do protocols.&nbsp; In order to =
decide if we=20
need a protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we =
need to=20
see what architecture we're trying to build.&nbsp; If=20
we<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can solve the=20
architecture with existing protocols then=20
we're<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; done.&nbsp; If =
we need=20
new protocol then we need to do it (either=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CCAMP or=20
elesewhere).&nbsp; But before we even define the arch=20
we<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; need to answer =
Lucy's Q=20
of whether this is something we need=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
solve.<BR><BR>Lucy - I=20
don't think the current protocol and architecture lets you=20
do<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this.<BR><BR>Dimitri - what =
prevents=20
us today from saying we'd establish a=20
connection<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at =
a given=20
point in time?<BR><BR>Lucy - all three options today don't =
work.<BR><BR>Zafar -=20
can't see what we need beyond what GMPLS provides.<BR><BR>Lucy - your =
connection=20
request doesn't have a future time in it.<BR><BR>Zafar - there are so =
many ways=20
you could do it.&nbsp; Nothing to do=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; protocol.<BR><BR>Lucy =
-=20
carriers currently rely on management plane to do it.&nbsp; If we=20
have<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CP then how do we combine =

them?<BR><BR>Zafar - local decision?<BR><BR>Lucy - A network resource =
you need=20
to reserve.&nbsp; Signalling doesn't =
let<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
you know time.<BR><BR>Zafar - can take offline...<BR><BR>Rowen - you do=20
signalling to future allocate resources? So do you=20
keep<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; full state of future=20
services?<BR><BR>Lucy - we can work that out in =
implementation.<BR><BR>Rowen -=20
do you keep states in network for services that aren't=20
running?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; That's a major =
scaling=20
issue.<BR><BR>Lucy - that's an implementation issue.<BR><BR>George - =
It's a=20
major scaling issue in building a switch.&nbsp; Also=20
issues<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in terms of=20
recovering stuff in event of failure.&nbsp; Better=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leave stuff in =
the mgmt=20
system and have CP as a slave.<BR><BR>Lucy - we already have PCE etc. so =
don't=20
need to embed this in the nodes<BR><BR>George - when pull out of =
network, it is=20
mgmt plane.<BR><BR>Lucy - PCE is out of network but is CP.<BR><BR>George =
- PCE=20
isn't part of GMPLS CP.&nbsp; Not suggesting we put this=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; routing and=20
signalling?&nbsp; E.g. signal with RSVP-TE ahead=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time?<BR><BR>Lucy =
- there=20
are different ways to implement this, not suggesting=20
one<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; here.<BR><BR>George - don't =
think is=20
good idea to put this in the switches.&nbsp;=20
Topology<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may change =
between=20
making request and reserving it.&nbsp; So=20
not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; very useful to =
embed the=20
info too close to where you're=20
going<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to deploy=20
it.<BR><BR>Lucy - I agree.<BR><BR>George - two things need to happen =
before we=20
consider this.&nbsp; (1) need=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hear from SPs =
that it's a=20
real need.&nbsp; Not many SPs want to=20
keep<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dark fibre =
around to=20
light up instantaneously.&nbsp; (2) need=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clarify the =
architecture=20
in terms of what is control and=20
what<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is=20
management...<BR><BR>Gert - we have application like this running for =
two=20
years.&nbsp; Never had<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; req. from =
service=20
provider to put anything in the control=20
plane.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So doubt if this is=20
useful...<BR><BR>Dimitri - I have one question.&nbsp; where shall I put =
the=20
resource<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
management=20
state.&nbsp; If I don't see a cost/benefit ratio=20
which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is =
better than=20
what we do today then won't do it.&nbsp; There is=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; temptation =
to make=20
the control plane have all the features=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
management=20
plane - really dangerous as end up with=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distributed=20
management plane...<BR><BR>Adrian - Keep hearing people say don't put =
mgmt plane=20
in CP.&nbsp; I think =
I<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; heard=20
Lucy say that too. So we all=20
agreed...<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>8.=20
CCAMP Liaison responses (chairs) [25, 120/120]<BR>&nbsp; - OIF Signaling =
for MEF=20
Requirements<BR>&nbsp; - OIF VLAN ID Requirements<BR>&nbsp; - OIF =
Interworking=20
Cookbook<BR>&nbsp; - SG15 Related<BR><BR>Slides<BR><BR>Background=20
reading<BR>&nbsp; - CCAMP incoming=20
correspondence<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR><BR>Dropped=20
from the agenda due to lack of time.<BR>Adrian - please look at slides =
on=20
liaison work.<BR><BR></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C77172.ACFFD779--

Delivery-date: Wed, 28 Mar 2007 19:27:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
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]>
Subject: Draft liaison to ITU-T SG 15 : VCAT
Date: Wed, 28 Mar 2007 20:26:49 +0100
Organization: Old Dog Consulting

Hi,

Thanks,
Adrian and Deborah

===

To: ITU-T SG15
From: IETF CCAMP

Best regards,

Delivery-date: Wed, 28 Mar 2007 19:26:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
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]>
Subject: Draft liaison to ITU-T SG15 : MLN work
Date: Wed, 28 Mar 2007 20:22:56 +0100
Organization: Old Dog Consulting

Hi,

Here is the first of a series of proposed liaisons to ITU-T Study Group 15.

Please comment by end of business 3rd April.

Thanks,
Adrian and Deborah
====
To: ITU-T SG15
Cc: Stephen Trowbridge; Kam Lam; Scott Bradner; Ross Callon; Dave Ward
Subject: Multi-Layer Networking (MLN) Work in CCAMP
For Action
Deadline: 18th May 2007

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.

Best regards,

Delivery-date: Wed, 28 Mar 2007 14:32:01 +0000
Content-class: urn:content-classes:message
Subject: Draft minutes
Date: Wed, 28 Mar 2007 09:26:24 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77145.11C00D09
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here's the minutes of the first session, much thanks to to the great
notes of David McWalter and Lyndon Ong. Please check them, comment on
missing items or corrections, and start to work on the items identified.
Thanks,
Deborah and Adrian
---------------------------------------------------------------
=20
Sixty-eighth IETF, Prague, March 2007

Monday, March 19, 2007
0900-1130 Morning Session I
RTG    ccamp    Common Control and Measurement Plane WG

CCAMP Working Group Minutes, Session 1 of 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CHAIRS: Adrian Farrel=20
        Deborah Brungard=20

Note takers: David McWalter, Lyndon Ong

Adrian opened, gave Note Well, noted that ccamp will meet *twice* in
Prague.
These minutes cover the Monday am meeting.
Second meeting tomorrow, Tuesday 1pm.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
0. Administrivia (chairs) [5 mins: 5/150]
Slides=20

Adrian asked for comments on agenda - none, for either session.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1. WG status, RFCs, drafts, milestones (chairs) [10, 15/150]
Slides=20

--0905 Adrian gave draft status.  Plenty of work, progressing well.
       6 new RFCs, 4 in editor queue, plus Crankback draft has just been
       sent to the RFC editor.
       Two drafts (rsvp-te-call and rsvp-restart-ext) are tied up in
       IESG review, both on security questions.
       3 drafts in WGLC.
       gmpls-addressing and te-node-cap are ready for last call (Adrian
       believes the latter is already implemented and deployed).
       ethernet-traffic-parameters seems to be stable
       10 more on today's agenda, 4 in pipeline.

Dimitri at mic: commented that some discussion was ongoing as a result
       of OIF liaison.  Adrian suggested closing with Lyndon offline,
       Deborah commented that we could close this in tomorrow's meeting.

--0911 Deborah presented an update on draft-andersson-rtg-gmpls-change,
       which has just been approved as a BCP.
       Adrian noted that this commits ccamp to do work sometimes.  The
       idea is that it encourages other SDOs to bring work to ccamp.

       Deborah went through charter milestones.  We're 'only just
       behind'.

--0913 Adrian recapped GELs progress.  This will make up the first 30
       minutes of tomorrow's agenda.  GMPLS enhancements are required,
       and will happen in ccamp.  Dataplane enhancements will not happen
       at the IETF.  Adrian will discuss possible charter changes with
       Ross and Dave (new AD). ccamp will only work on a control plane
       for a clearly specified dataplane.  IEEE is just starting work on
       this under the heading 802.1Qay, also known as PBBTE.  Adrian
       said that because a dataplane specification is *forthcoming*, it
       is okay to start control plane work now ('pipeline' it).
Dimitri at mic sought to clarify.  Adrian replied that there is work
       that can happen now in advance of definition of label format, for
       example the traffic parameters we have already started on.
Dimitri at mic also asked about scope of work.  Adrian replied that we
       should look at things that break 3945 on a case-by-case basis.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
2. ITU-T and OIF progress report (Lyndon) [10, 25/150]
Slides=20

Note: Discussion of responses to recent ITU-T and OIF liaisons
will fall in the second CCAMP meeting on Tuesday afternoon.

--0917 Lyndon presented ITU-T and OIF liaison.
       Lyndon was not at the ITU-T meeting a month ago, but has talked
       to the chair and quickly summarized the SG15 Q.14 work ongoing.
       Two liaisons:
       #1  Response to CCAMP reply on ASON, including requests for more
           information, some language concerns, and a clarifying point
           about call/connection separation.  There was also a concern
           about use of liaisons versus use of individual participation.
           ITU felt that liason communicated group concensus and was
           valuable.
Monique asked about about overlap SG13 Q5, which also deals with T-MPLS
           management.  Lyndon wasn't familiar with this, but took an
           action to look at this.
       #2  Requested to review the GMPLS call draft and VCAT/LCAS drafts
           before they get to RFC.

--0925 Lyndon summarized OIF status.  E-NNI routing IA and UNI2.0 and
       E-NNI 2.0 signaling in progress.  Again, two liaisons.
       #1  VLAN ID, where OIF wants to carry many VLAN ID 'labels' as
           part of an RSVP signaling message.  OIF members accept that
           possibly this information isn't really part of a label.  The
           EVC is the connection, and perhaps the VLAN ID list is just
           an attribute of that collection.  Lyndon said OIF was open to
           looking at what was the best solution from a protocol
           standpoint.
       #2  OIF documents liaising current state of UNI 2.0 and E-NNI 2.0
           documents.  OIF will send an update when these documents are
           approved and stable.

Adrian said that there is time at the end of tomorrow's meeting to draft
       a liaison back to OIF.
Lyndon said that the VLAN ID issue is perhaps the priority.
Deborah encouraged folks who could not make tomorrow's meeting to get in
       touch with Lyndon.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
3. ASON Routing solutions (Dimitri) [10 35/150]
Slides=20
Background reading
  - draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt

--0929 Dimitri recapped on progress since IETF-67.  Dimitri stressed
       that there is no implied relationship in these documents between
       MLN and multi-level routing.  This is a problem for
       implementations. There is also a question of technology-specific
       extensions; these will go in separate documents.  The main
       document will stay generic. For bandwidth accounting, a single
       generic mechanism will be defined that will cover packet, lambda,
       etc.  If any more specific information is defined, then an
       extension document can be written.
       Also discussed resiliency and policy.  Dimitri sought to exclude
       some of these points, on the basis that this document is 'a
       protocol spec', but which would support extensions for specific
       technologies or additional functions/management.
       Next steps: ready for last call? what review process?
Adrian noted that there are questions that are not yet resolved that may
       require changes.  Partly by keeping ITU in the loop, partly by
       closing technical discussions.
Igor Bryskin at mic: asked about TE node identification using TE router
       IDs or routable addresses.  Dimitri replied that this document
       wishes to be as simple as possible, and referred to RFC 3630, and
       asked about the rationale for TE router IDs today.  This has been
       discussed on the list, perhaps a couple of years ago.  Dimitri
       stressed that this has been discussed and agreed, and is not a
       new suggestion.
Adrian asked if node IDs were guaranteed routable in the signaling plane
       Dimitri answered noting that they were an identification.
Adrian said he wasn't asking whether it should or should not be routable
       he's just trying to understand.  Dmitri replied they could be.
Adrian asked if a summary would be that the node ID doesn't need to be
       routable, but a wise implementation would make it routable?
Dimitri discussed that it may or may not be by 3630.
Igor said he had expected a shorter answer from Dimitri, and raised an
       objection to the case where router IDs were not routable.
       Discussion between Igor and Dimitri continued.
       Summarizing: Igor asserts that the router ID should be a
       routable IP address.  Dimitri says this is just one
       interpretation of RFC 3630, and other interpretations are
       possible; this is nothing new and it's nothing new that this
       draft is introducing.
Igor asked 'how do you force it [TE node ID] to be routable?'
       Dimitri replied by again referring to RFC 3630.

--0948 Adrian closed by suggesting that a clarification section needs
       adding to the draft, to answer Igor's concern.  Dimitri took an
       action to do this and bounce it off Igor.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
4. VCAT/LCAS (Adrian) [15, 50/150]
  - Analysis of requirements
  - First proposal for solutions
Slides=20
Background reading
  - draft-ietf-ccamp-gmpls-vcat-lcas-01.txt

--0949 Adrian said that for some reason that is not entirely clear to
       him, he gets to present this draft.  This has been taken on as
       a working group draft.  Notes, there has been a long ad hoc
       mailing list discussion on-going. Greg Bernstein is the main
       editor, but he could not make it to this meeting.  Also there is
       a revision to the draft needed, but this didn't quite happen
       before this meeting.  (Adrian will hit people if there is not a
       new revision soon).
       Requirements are stable, and the people listed in the foils are
       in agreement on this, so should make progress.  CCAMP will need
       to liaise this work to ITU and OIF as it progresses.
       To summarize requirements; allow TDM LSPs to be signaled to
       support virual concatenation. RFC 4606 allows this, but then all
       members of VCG are co-routed.  Now hardware allows VCG components
       to follow different paths.  Need to associate LSPs to form a
       single group, with defined capabilities.  Need a pool of 'spare'
       LSPs that can be added to VCGs at short notice.  Determine ports/
       interfaces at egress that can support VCGs, which is dependent on
       hardware capabilities.
       There are two options for associating LSPs.  Can either use the
       association object (used for e2e), or using a GMPLS call.  The
       latter is favoured, because only the endpoints care about the
       association.  The VCG properties become call parameters, which
       works quite nicely.  The problem that arises is management of the
       spare pool.   It is suggested that this function requires LCAS in
       order to work.
       Determination of endpoint capabilities feels like a routing
       function, but doesn't scale well.  So perhaps only basic node and
       link properties should be advertised via routing, with other
       properties negotiated as part of call setup.
Lyndon at mic commented that the OIF has discussed this recently, and
       that there is a developing view in ITU that the dataplane looks
       like a layer built on SONET/SDH or STM.  Does this mean that a
       separate signaling or routing layer is needed?  This is confusing
       people a lot, because it adds flexibility but also overhead.
Deborah asked Lyndon if Q14 or Q11 was developing this view of layering.
       Lyndon replied that he knows about Q14 but is not sure about Q11.
       It's coming out of a G805 idea that VCAT is a layer on its own.
Adrian commented that LCAS is perhaps a separate layer, so VCG is really
       a client layer, which requests that LSPs are set up, co-ordinated
       and delivered to it as a service.  So all that we have talked
       about is within a layer, but with something above it that says
       'I want VCAT'.
Adrian asked whether we should liaise with Q11 as well as Q14.  Lyndon
       was unsure but agreed.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
5. Multi-Layer Networks (Kohei) [10, 60/150]
  - Strategy and plans to complete this work
Slides=20
Background reading
  - draft-ietf-ccamp-gmpls-mln-reqs-02.txt
  - draft-ietf-ccamp-gmpls-mln-eval-02.txt
  - draft-papadimitriou-ccamp-gmpls-mrn-extensions-03.txt

--1001 Kohei presented the MLN document set.
       Protocol extensions being defined; for example IACD (Internal
       Adaptation Capabilities Descriptor) TLV added to IGPs.
       There are two approaches to Virtual TE links at present.
       (i) Soft FA, which is a signaled LSP not established in the
           dataplane, and
       (ii) remote association, where LSPs are not signaled, but
            properties are exchanged between FA endpoint.
       These have different pros and cons. Comments have been received
       about Path diversity and SRLG inheritance. Kohei feels no
       protocol extensions are required, but that this is an issue for
       the management plane.  Comments have also been received about
       directionality-ambiguity in adaptation information, but Kohei
       felt there was no ambiguity.
       Next steps are that the -reqs and -eval documents are close to
       WGLC.
       The solution doc is proposed as a WG document.
Adrian is pleased to see this work proceeding again after a period of
       silence. Adrian said chairs should look at the documents to
       ensure they're ready for WGLC, and perhaps liaise them to ITU
       immediately (as they've expressed an interest), and this should
       allow them to respond in time for the end of last call.  The
       timescales for the requirements drafts look about right.  We'll
       poll the mailing list about adoption of the solutions draft after
       this meeting.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
6. MIB Module for GMPLS TE Database (Kenichi) [10, 70/150]
Slides=20
Background reading
  - draft-ietf-ccamp-gmpls-ted-mib-01.txt

--1009 Kenichi said that Tomohiro Otani could not attend.
       Originally this draft was created as an extension of OSPF MIBs
       for TE, but is being generalized to include both OSPF and IS-IS.
       Recent changes to this MIB module generalize OSPF-specific
       objects, and renames several objects.
Adrian encouraged input from people who are going to implement and use
       this.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
7. OAM Requirements for GMPLS Networks (Kenichi) [10, 80/150]
Slides=20
Background reading
  - draft-nadeau-ccamp-gmpls-oam-requirements-01.txt

--1014 Kenichi also presented this, as Tomohiro Otani is not here.  He
       explained how this responds to the WG charter item.  It is also
       an issue that there is no definition of GMPLS OAM requirements
       beyond the RFC4377 MPLS requirements.  Kenichi summarized a set
       of possible GMPLS OAM requirements (see slides).
Loa Andersson (MPLS chair) at mic asked about relationship to MPLS OAM
       requirements; is a revision of the MPLS requirements document
       proposed?
Adrian would not want to see anything that replaced or revised the MPLS
       work; would prefer a new document that pointed at the MPLS work
       and stated what was relevant and how they were extended.
Loa Andersson: okay
Dimitri asked a long question about control plane properties, and
       whether there was synchronous access to what it was transporting,
       and whether there were different requirements for circuit versus
       packet, and we should be clear about scope for the future.
Adrian: I don't know.  We should not be specifying Ethernet OAM; it is
       not our business.  But maybe there are questions of co-ordination
       of OAM (for example between different layers) that we could help
       with.  Control plane OAM is clearly ours.  Adrian is struggling
       with this work, and is not clear what there is that should be
       done; Adrian is hopeful that this document will cystalize issues,
       and discussion on the list should make it clear whether there is
       really some work here.
Dimitri worried that we shouldn't put too many purposes together into a
       single document.
Adrian: Good advice.
Don Fedyk agreed with Dimitri.  When it says 'requirements', you need to
       have a technology in mind.  It's good to have a list that says
       what OAM needs to do, but how this is satisfied depends on the
       technology.
Adrian agreed.
Dimitri doesn't want to see overloading of the GMPLS control plane.
Deborah: Suggests look at the document; question of whether GMPLS will
       provide OAM for the dataplane is reviewed by the document; take a
       look at it.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
8. Conversion between Permanent Connections and Switched Connections
(Diego) [10, 90/150]
Slides=20
Background reading
  - draft-ietf-ccamp-pc-and-sc-reqs-00.txt

--1024 Diego: No comments received on the requirements ID since made a
       WG item. For caviglia solution draft, have received some comments
       from Dimitri on the list.  Main problems are with failure
       scenarios during handover, to be solved in a draft update after
       this IETF.
Adrian: We want to see that update, and then decide whether this is the
       solution we want for this problem space.  Any questions? .
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
9. Multiple Nodes Graceful Restart (Dan) [10, 100/150]
Slides=20
Background reading
  - draft-li-ccamp-multinodes-gr-proc-01.txt

--1028 Dan: Summarized changes to draft since -00.  Note that this draft
       now targets Informational status.  Draft is stable, seeks WG
       acceptance.
Adrian: When we were discussing the previous version, there were
       questions of whether this was needed at all.  But there was a
       feeling that it would help people understand GR, and prevent
       needless development of protocol extensions already supported by
       GR.  Show of hands; who would find this helpful? (6 or 7).  Any
       objections (0).
Lou Berger (at back mic) said the document still implies it is more than
       just an informational clarification.  Document needs to be
       consistent with the proposal that no new procedures are defined.
       This is just an educational document, not a BCP.
Adrian: Understand.  We'll discuss on the list.
Ina at mic: I haven't heard any requirement for this work from
       providers.
Adrian: Agree, it would be good to have providers commenting.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
10. Graceful Shutdown (Zafar) [10, 110/150]
Slides=20
Background reading
  - draft-ietf-ccamp-mpls-graceful-shutdown-02.txt

--1035 Zafar Presented some protocol details that have been discussed:
       One comment on the list was with respect to how to get out of
       graceful shutdown state so traffic can be moved to alternate
       path.  Both MBB and FRR segment recovery have been suggested.
       This has been addressed by saying that PathError must be
       propagated to Ingress, but branch nodes can make local decisions
       about applying FRR.
       Another comment about shutdown of stitched LSPs, which are
       signaled as distinct LSPs in the control plane.  The document has
       been updated with a solution about these and for the case of
       bundled links.
       Finally, overloading error code from RFC 4736, which requires
       LSPs to do re-optimization on receipt of certain error codes.
       This draft relies on optimization at ingress, but extends this
       handling to other branch nodes on the path.  Wording is difficult
       here; anyone with objections should let authors know.
       Next steps, need to address a nit.
Adrian: What is this nit? Zafar: just need to clarify a sentence about
       how something or other applies to a link.
Adrian: Okay, just need to address this in next revision and then will
       be ready for last call.
Adrian: Do we know of any implementations?  Zaar: No.  Adrian: Okay,
       I'll ask on the list and people can reply in private if they need
       to.
Zafar: Thank-you.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
11. MPLS/GMPLS Security Discussions
11a. MPLS/GMPLS Security Framework (Luyuan) [15, 125/150]
     Slides=20
     Background reading
       - draft-fang-mpls-gmpls-security-framework-00.txt

--1042 Luyuan: There is a large design team for this work (see 1st
slide).
     We presented this in IETF-67, and called for interest.  The design
     team then formed.  -00 draft was issued before this meeting.  Will
     be presented at both MPLS and CCAMP.  Why did we start a security
     framework at this point, given what has been done in MPLS already?
     The trigger was that the security ADs and reviewers had questioned
     some GMPLS drafts, and wondered whether GMPLS security had been
     adequately addressed in the past.
     Questions started with p2mp, but then went back to TE and
     fundamental parts of GMPLS.  Ross and others asked for a single
     draft to discuss all MPLS/GMPLS security issues.  Any other drafts
     in MPLS/GMPLS should point to this draft as the general framework.
     Protocol extensions with their own security concerns must address
     them themselves.
     Objective is to make this an informational RFC as quickly as
     possible. Will address security implementation implications for
     several protocols, including LDP, RSVP-TE, PCE, P2MP/LDP, VPNs,
     PWs, inter-provider, etc. Scope is broader than core just GMPLS.
     However, general security concerns will not be addressed (will
     reference existing security drafts).
     Luyuan then outlined the content of the -00 draft.
Adrian: I'm really impressed with the quantity and quality of work that
     has gone into this draft in a short time.
Luyuan: Thanks, it was a team effort.
Dimitri: Wondered about duplication of work between this an rpsec/sidr.
Luyuan: Scope is a little bit fuzzy. Some content will touch on routing
     protocols but this is not the focus.
Dimitri: Further question about assuming modes of operation; should the
     draft state the modes of operation under which the network is
     assumed to run.
Luyuan: Again, scope is difficult. Document looks to demonstrate that
     with proper procedure adding MPLS/GMPLS to a network does not make
     it less secure.
Dimitri: Again sought to clarify which 'running mechanisms' were being
     employed in particular deployments being considered by this
     security draft.
Luyuan/Dimitri closed agreeably.

Adrian: Asked George if this work would be owned by the MPLS WG.
George Swallow: That's my understanding, but Ross can overrule me.
Adrian: He wouldn't dare.
Loa: Agree with George.
Ross: Has no opinion on whether this is MPLS/CCAMP.  Can last call it in
     both. No strong opinion, but tend to prefer MPLS unless others
     object.
Kireeti: Should be owned by MPLS, because some bits are MPLS-specific.
Adrian is happy that someone else is doing the work.
Adrian: Asked Monique about whether this overlaps with work done by
     IPSphere.
Monique (from floor): No.

11b. Security AD issues with TE Calls (Adrian) [10, 135/150]
     Slides=20
     Background reading
       - draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

11c. Security AD issues with Graceful Restart (Adrian) [10, 145/150]
     Slides=20
     Background reading
     - draft-ietf-ccamp-rsvp-restart-ext-08.txt

-1058 Adrian: To close, want to look at two drafts going through
     security AD review, related to what Luyuan has just presented.
     There are two major questions about the GR draft.
     #1  What would happen if a downstream neighbour of a restarting
         node sent a false RecoveryPath message, either accidentally or
         as a result of downstream node being subverted.
     #2  What damage could be done to the restarting node control/data
         plane as a result of such a bogus message?
     Adrian has pasted a long discussion thread on this to ccamp list.
     Trust model in ccamp is peer-to-peer; peers with whom messages are
     exchanged are authenticated.  This isn't about attacks from
     strangers; it is about subverted RSVP-TE nodes.  Adrian questions
     why this is of particular reference to GR?  Surely any subverted
     node could take a variety of actions at any time in the protocol
     (for example, corrupting routes in path messages).  Adrian also
     points out that RecoveryPath is verified against the dataplane on
     the restarting node.  There was also a discussion about falsified
     EROs, and what the consequences might be.

     On the TE-Call draft there were issues about Notify messages which
     are end-to-end communication; a new concept?  How are keys
     established with Notify recipients?  Is Notify processing a
     necessary part of call processing?  This leads to a question of
     whether an automated key distribution mechanism is required.
     Security of calls is definitely a concern, but again Notify
     processing is not specific to calls.  Either RSVP-TE security or
     IPeec (if tunneling) can be used to authenticate origin of Notify
     messages.  Can also use RSVP forwarding to propagate Notify
     messages hop-by-hop, which makes use of RSVP peer authentication as
     above.

     For the restart draft, the ADs are not really totally convinced,
     and would like ccamp to describe what could happen if each message
     was spoofed.  This strikes Adrian as being a lot of work.

     For the call draft, an RFC 4107 analysis is asked for.

     Next step will be to have face-to-face discussions with ADs at this
     IETF to try to get these drafts moved forward, and to clarify the
     security framework so this does not happen to other drafts in
     future.

Yakov Rechter at mic: Would it address GR concern if processing was
     restricted to a single service provider (implying same trust
     domain).  Adrian doesn't see that the Security AD would be happy
     with this because he is talking about node subversion which could
     be in a domain.
Yakov: Indeed, what would happen if all your routers were subverted?
Adrian: I don't know.

Lou: (commented about unreasonableness of feedback from ADs)
Adrian: Yes, perhaps ADs will say 'all of your work is broken, stop'.
Lou: Come on, there's history and deployed protocols here.  ADs are
     welcome to say it's all broken, and there is a new work item to
     make a working protocol to address all this.  We should push back
     very strongly, and not let this stop us from doing our work.
Adrian: Thanks.

Dimitri: Tried to clarify what the questions being answered were.

Ross: I'm trying to figure out what I should actually say.  I don't want
     to get shot.  I have mixed feelings.  When my laptop boots up, it
     says 'you might be infected'.  Actually I know my laptop is
     infected.  Routers might be too.  It's not hard to infect routers;
     administrators use stupid passwords, you can configure routers to
     bring down the network.  However, no vendor is going to implement
     the command 'please send wrong information on graceful restart'.
     The bottom line is that there's not a lot of reason for us to
     define something that no-one has any interest in buying.  That's
     one view.
     Another view is that the internet isn't as secure as it should be.
     But if no-one builds it, there's no point the spec saying it.  In
     the specific case of the restart work, Ross talked to a member of
     the security directorate.  Perhaps we don't need to do anything
     about it, but the directorate would like to know what a router
     would do if it was subverted. Would the conflicting information be
     detected?  We could try to figure out what an implementation would
     do if it got different information from downstream neighbours and
     put that in the draft.  That might be enough for this draft, I
     hope.

Zafar: I'm a little bit concerned about the notify message.  There's
     something you mentioned about making it hop-by-hop, but this would
     be more like a PathErr message.  Could you specify what you mean?
Adrian: On notify, RFC 3473 specifies these two methods, and points out
     a way to do security is hop-by-hop.
Zafar: Has concerns with this.
Adrian: Yes, but these are tradeoffs you may need to make to get e2e
     security.

Yakov Rechter: Wanted to respond to Ross's point about how things only
     get implemented if people are prepared to pay for it.  It's
     presumptious to say that 2 or 3 people in the IESG know what's good
     for everyone.  The IETF needs to address this problem.

Adrian: Watch this space.  Ross and I will report back to the mailing
     list after we've held our side-meetings.

Zafar: Every node does local checks it can do against the ERO.  If every
     node does that (I think implementations do), much of the
     information passed by the neighbor is checked.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

1121 Adrain: Okay, if we're done then perhaps this is a good time for
     folks interested in MEF to gather at the front and talk about it.

     We're done, see you tomorrow.

***********************************************************

------_=_NextPart_001_01C77145.11C00D09
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=3D694390714-28032007>Here's =
the minutes=20
of the first session, much thanks to to the great notes of David =
McWalter and=20
Lyndon Ong. Please check them, comment on missing items or corrections, =
and=20
start to work on the items identified.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D694390714-28032007>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D694390714-28032007>Deborah and=20
Adrian</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D694390714-28032007>----------------------------------------------=
-----------------</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D694390714-28032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D694390714-28032007><PRE><FONT =
size=3D2><FONT face=3DArial>Sixty-eighth IETF, Prague, March 2007

Monday, March 19, 2007
0900-1130 Morning Session I
RTG    ccamp    Common Control and Measurement Plane WG

CCAMP Working Group Minutes, Session 1 of 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CHAIRS: Adrian Farrel <[email-masked]>
        Deborah Brungard <[email-masked]>

Note takers: David McWalter, Lyndon Ong

Adrian opened, gave Note Well, noted that ccamp will meet *twice* in
Prague.
These minutes cover the Monday am meeting.
Second meeting tomorrow, Tuesday 1pm.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
0. Administrivia (chairs) [5 mins: 5/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-0.ppt>

Adrian asked for comments on agenda - none, for either session.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1. WG status, RFCs, drafts, milestones (chairs) [10, 15/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-0.ppt>

--0905 Adrian gave draft status.  Plenty of work, progressing well.
       6 new RFCs, 4 in editor queue, plus Crankback draft has just been
       sent to the RFC editor.
       Two drafts (rsvp-te-call and rsvp-restart-ext) are tied up in
       IESG review, both on security questions.
       3 drafts in WGLC.
       gmpls-addressing and te-node-cap are ready for last call (Adrian
       believes the latter is already implemented and deployed).
       ethernet-traffic-parameters seems to be stable
       10 more on today's agenda, 4 in pipeline.

Dimitri at mic: commented that some discussion was ongoing as a result
       of OIF liaison.  Adrian suggested closing with Lyndon offline,
       Deborah commented that we could close this in tomorrow's meeting.

--0911 Deborah presented an update on draft-andersson-rtg-gmpls-change,
       which has just been approved as a BCP.
       Adrian noted that this commits ccamp to do work sometimes.  The
       idea is that it encourages other SDOs to bring work to ccamp.

       Deborah went through charter milestones.  We're 'only just
       behind'.

--0913 Adrian recapped GELs progress.  This will make up the first 30
       minutes of tomorrow's agenda.  GMPLS enhancements are required,
       and will happen in ccamp.  Dataplane enhancements will not happen
       at the IETF.  Adrian will discuss possible charter changes with
       Ross and Dave (new AD). ccamp will only work on a control plane
       for a clearly specified dataplane.  IEEE is just starting work on
       this under the heading 802.1Qay, also known as PBBTE.  Adrian
       said that because a dataplane specification is *forthcoming*, it
       is okay to start control plane work now ('pipeline' it).
Dimitri at mic sought to clarify.  Adrian replied that there is work
       that can happen now in advance of definition of label format, for
       example the traffic parameters we have already started on.
Dimitri at mic also asked about scope of work.  Adrian replied that we
       should look at things that break 3945 on a case-by-case basis.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
2. ITU-T and OIF progress report (Lyndon) [10, 25/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-1.ppt>

Note: Discussion of responses to recent ITU-T and OIF liaisons
will fall in the second CCAMP meeting on Tuesday afternoon.

--0917 Lyndon presented ITU-T and OIF liaison.
       Lyndon was not at the ITU-T meeting a month ago, but has talked
       to the chair and quickly summarized the SG15 Q.14 work ongoing.
       Two liaisons:
       #1  Response to CCAMP reply on ASON, including requests for more
           information, some language concerns, and a clarifying point
           about call/connection separation.  There was also a concern
           about use of liaisons versus use of individual participation.
           ITU felt that liason communicated group concensus and was
           valuable.
Monique asked about about overlap SG13 Q5, which also deals with T-MPLS
           management.  Lyndon wasn't familiar with this, but took an
           action to look at this.
       #2  Requested to review the GMPLS call draft and VCAT/LCAS drafts
           before they get to RFC.

--0925 Lyndon summarized OIF status.  E-NNI routing IA and UNI2.0 and
       E-NNI 2.0 signaling in progress.  Again, two liaisons.
       #1  VLAN ID, where OIF wants to carry many VLAN ID 'labels' as
           part of an RSVP signaling message.  OIF members accept that
           possibly this information isn't really part of a label.  The
           EVC is the connection, and perhaps the VLAN ID list is just
           an attribute of that collection.  Lyndon said OIF was open to
           looking at what was the best solution from a protocol
           standpoint.
       #2  OIF documents liaising current state of UNI 2.0 and E-NNI 2.0
           documents.  OIF will send an update when these documents are
           approved and stable.

Adrian said that there is time at the end of tomorrow's meeting to draft
       a liaison back to OIF.
Lyndon said that the VLAN ID issue is perhaps the priority.
Deborah encouraged folks who could not make tomorrow's meeting to get in
       touch with Lyndon.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
3. ASON Routing solutions (Dimitri) [10 35/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-2.ppt>
Background reading
  - draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt

--0929 Dimitri recapped on progress since IETF-67.  Dimitri stressed
       that there is no implied relationship in these documents between
       MLN and multi-level routing.  This is a problem for
       implementations. There is also a question of technology-specific
       extensions; these will go in separate documents.  The main
       document will stay generic. For bandwidth accounting, a single
       generic mechanism will be defined that will cover packet, lambda,
       etc.  If any more specific information is defined, then an
       extension document can be written.
       Also discussed resiliency and policy.  Dimitri sought to exclude
       some of these points, on the basis that this document is 'a
       protocol spec', but which would support extensions for specific
       technologies or additional functions/management.
       Next steps: ready for last call? what review process?
Adrian noted that there are questions that are not yet resolved that may
       require changes.  Partly by keeping ITU in the loop, partly by
       closing technical discussions.
Igor Bryskin at mic: asked about TE node identification using TE router
       IDs or routable addresses.  Dimitri replied that this document
       wishes to be as simple as possible, and referred to RFC 3630, and
       asked about the rationale for TE router IDs today.  This has been
       discussed on the list, perhaps a couple of years ago.  Dimitri
       stressed that this has been discussed and agreed, and is not a
       new suggestion.
Adrian asked if node IDs were guaranteed routable in the signaling plane
       Dimitri answered noting that they were an identification.
Adrian said he wasn't asking whether it should or should not be routable
       he's just trying to understand.  Dmitri replied they could be.
Adrian asked if a summary would be that the node ID doesn't need to be
       routable, but a wise implementation would make it routable?
Dimitri discussed that it may or may not be by 3630.
Igor said he had expected a shorter answer from Dimitri, and raised an
       objection to the case where router IDs were not routable.
       Discussion between Igor and Dimitri continued.
       Summarizing: Igor asserts that the router ID should be a
       routable IP address.  Dimitri says this is just one
       interpretation of RFC 3630, and other interpretations are
       possible; this is nothing new and it's nothing new that this
       draft is introducing.
Igor asked 'how do you force it [TE node ID] to be routable?'
       Dimitri replied by again referring to RFC 3630.

--0948 Adrian closed by suggesting that a clarification section needs
       adding to the draft, to answer Igor's concern.  Dimitri took an
       action to do this and bounce it off Igor.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
4. VCAT/LCAS (Adrian) [15, 50/150]
  - Analysis of requirements
  - First proposal for solutions
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-3.ppt>
Background reading
  - draft-ietf-ccamp-gmpls-vcat-lcas-01.txt

--0949 Adrian said that for some reason that is not entirely clear to
       him, he gets to present this draft.  This has been taken on as
       a working group draft.  Notes, there has been a long ad hoc
       mailing list discussion on-going. Greg Bernstein is the main
       editor, but he could not make it to this meeting.  Also there is
       a revision to the draft needed, but this didn't quite happen
       before this meeting.  (Adrian will hit people if there is not a
       new revision soon).
       Requirements are stable, and the people listed in the foils are
       in agreement on this, so should make progress.  CCAMP will need
       to liaise this work to ITU and OIF as it progresses.
       To summarize requirements; allow TDM LSPs to be signaled to
       support virual concatenation. RFC 4606 allows this, but then all
       members of VCG are co-routed.  Now hardware allows VCG components
       to follow different paths.  Need to associate LSPs to form a
       single group, with defined capabilities.  Need a pool of 'spare'
       LSPs that can be added to VCGs at short notice.  Determine ports/
       interfaces at egress that can support VCGs, which is dependent on
       hardware capabilities.
       There are two options for associating LSPs.  Can either use the
       association object (used for e2e), or using a GMPLS call.  The
       latter is favoured, because only the endpoints care about the
       association.  The VCG properties become call parameters, which
       works quite nicely.  The problem that arises is management of the
       spare pool.   It is suggested that this function requires LCAS in
       order to work.
       Determination of endpoint capabilities feels like a routing
       function, but doesn't scale well.  So perhaps only basic node and
       link properties should be advertised via routing, with other
       properties negotiated as part of call setup.
Lyndon at mic commented that the OIF has discussed this recently, and
       that there is a developing view in ITU that the dataplane looks
       like a layer built on SONET/SDH or STM.  Does this mean that a
       separate signaling or routing layer is needed?  This is confusing
       people a lot, because it adds flexibility but also overhead.
Deborah asked Lyndon if Q14 or Q11 was developing this view of layering.
       Lyndon replied that he knows about Q14 but is not sure about Q11.
       It's coming out of a G805 idea that VCAT is a layer on its own.
Adrian commented that LCAS is perhaps a separate layer, so VCG is really
       a client layer, which requests that LSPs are set up, co-ordinated
       and delivered to it as a service.  So all that we have talked
       about is within a layer, but with something above it that says
       'I want VCAT'.
Adrian asked whether we should liaise with Q11 as well as Q14.  Lyndon
       was unsure but agreed.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
5. Multi-Layer Networks (Kohei) [10, 60/150]
  - Strategy and plans to complete this work
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-4.ppt>
Background reading
  - draft-ietf-ccamp-gmpls-mln-reqs-02.txt
  - draft-ietf-ccamp-gmpls-mln-eval-02.txt
  - draft-papadimitriou-ccamp-gmpls-mrn-extensions-03.txt

--1001 Kohei presented the MLN document set.
       Protocol extensions being defined; for example IACD (Internal
       Adaptation Capabilities Descriptor) TLV added to IGPs.
       There are two approaches to Virtual TE links at present.
       (i) Soft FA, which is a signaled LSP not established in the
           dataplane, and
       (ii) remote association, where LSPs are not signaled, but
            properties are exchanged between FA endpoint.
       These have different pros and cons. Comments have been received
       about Path diversity and SRLG inheritance. Kohei feels no
       protocol extensions are required, but that this is an issue for
       the management plane.  Comments have also been received about
       directionality-ambiguity in adaptation information, but Kohei
       felt there was no ambiguity.
       Next steps are that the -reqs and -eval documents are close to
       WGLC.
       The solution doc is proposed as a WG document.
Adrian is pleased to see this work proceeding again after a period of
       silence. Adrian said chairs should look at the documents to
       ensure they're ready for WGLC, and perhaps liaise them to ITU
       immediately (as they've expressed an interest), and this should
       allow them to respond in time for the end of last call.  The
       timescales for the requirements drafts look about right.  We'll
       poll the mailing list about adoption of the solutions draft after
       this meeting.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
6. MIB Module for GMPLS TE Database (Kenichi) [10, 70/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-5.ppt>
Background reading
  - draft-ietf-ccamp-gmpls-ted-mib-01.txt

--1009 Kenichi said that Tomohiro Otani could not attend.
       Originally this draft was created as an extension of OSPF MIBs
       for TE, but is being generalized to include both OSPF and IS-IS.
       Recent changes to this MIB module generalize OSPF-specific
       objects, and renames several objects.
Adrian encouraged input from people who are going to implement and use
       this.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
7. OAM Requirements for GMPLS Networks (Kenichi) [10, 80/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-6.ppt>
Background reading
  - draft-nadeau-ccamp-gmpls-oam-requirements-01.txt

--1014 Kenichi also presented this, as Tomohiro Otani is not here.  He
       explained how this responds to the WG charter item.  It is also
       an issue that there is no definition of GMPLS OAM requirements
       beyond the RFC4377 MPLS requirements.  Kenichi summarized a set
       of possible GMPLS OAM requirements (see slides).
Loa Andersson (MPLS chair) at mic asked about relationship to MPLS OAM
       requirements; is a revision of the MPLS requirements document
       proposed?
Adrian would not want to see anything that replaced or revised the MPLS
       work; would prefer a new document that pointed at the MPLS work
       and stated what was relevant and how they were extended.
Loa Andersson: okay
Dimitri asked a long question about control plane properties, and
       whether there was synchronous access to what it was transporting,
       and whether there were different requirements for circuit versus
       packet, and we should be clear about scope for the future.
Adrian: I don't know.  We should not be specifying Ethernet OAM; it is
       not our business.  But maybe there are questions of co-ordination
       of OAM (for example between different layers) that we could help
       with.  Control plane OAM is clearly ours.  Adrian is struggling
       with this work, and is not clear what there is that should be
       done; Adrian is hopeful that this document will cystalize issues,
       and discussion on the list should make it clear whether there is
       really some work here.
Dimitri worried that we shouldn't put too many purposes together into a
       single document.
Adrian: Good advice.
Don Fedyk agreed with Dimitri.  When it says 'requirements', you need to
       have a technology in mind.  It's good to have a list that says
       what OAM needs to do, but how this is satisfied depends on the
       technology.
Adrian agreed.
Dimitri doesn't want to see overloading of the GMPLS control plane.
Deborah: Suggests look at the document; question of whether GMPLS will
       provide OAM for the dataplane is reviewed by the document; take a
       look at it.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
8. Conversion between Permanent Connections and Switched Connections =
(Diego) [10, 90/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-7.ppt>
Background reading
  - draft-ietf-ccamp-pc-and-sc-reqs-00.txt

--1024 Diego: No comments received on the requirements ID since made a
       WG item. For caviglia solution draft, have received some comments
       from Dimitri on the list.  Main problems are with failure
       scenarios during handover, to be solved in a draft update after
       this IETF.
Adrian: We want to see that update, and then decide whether this is the
       solution we want for this problem space.  Any questions? <NONE>.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
9. Multiple Nodes Graceful Restart (Dan) [10, 100/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-8.ppt>
Background reading
  - draft-li-ccamp-multinodes-gr-proc-01.txt

--1028 Dan: Summarized changes to draft since -00.  Note that this draft
       now targets Informational status.  Draft is stable, seeks WG
       acceptance.
Adrian: When we were discussing the previous version, there were
       questions of whether this was needed at all.  But there was a
       feeling that it would help people understand GR, and prevent
       needless development of protocol extensions already supported by
       GR.  Show of hands; who would find this helpful? (6 or 7).  Any
       objections (0).
Lou Berger (at back mic) said the document still implies it is more than
       just an informational clarification.  Document needs to be
       consistent with the proposal that no new procedures are defined.
       This is just an educational document, not a BCP.
Adrian: Understand.  We'll discuss on the list.
Ina at mic: I haven't heard any requirement for this work from
       providers.
Adrian: Agree, it would be good to have providers commenting.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
10. Graceful Shutdown (Zafar) [10, 110/150]
Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-9.ppt>
Background reading
  - draft-ietf-ccamp-mpls-graceful-shutdown-02.txt

--1035 Zafar Presented some protocol details that have been discussed:
       One comment on the list was with respect to how to get out of
       graceful shutdown state so traffic can be moved to alternate
       path.  Both MBB and FRR segment recovery have been suggested.
       This has been addressed by saying that PathError must be
       propagated to Ingress, but branch nodes can make local decisions
       about applying FRR.
       Another comment about shutdown of stitched LSPs, which are
       signaled as distinct LSPs in the control plane.  The document has
       been updated with a solution about these and for the case of
       bundled links.
       Finally, overloading error code from RFC 4736, which requires
       LSPs to do re-optimization on receipt of certain error codes.
       This draft relies on optimization at ingress, but extends this
       handling to other branch nodes on the path.  Wording is difficult
       here; anyone with objections should let authors know.
       Next steps, need to address a nit.
Adrian: What is this nit? Zafar: just need to clarify a sentence about
       how something or other applies to a link.
Adrian: Okay, just need to address this in next revision and then will
       be ready for last call.
Adrian: Do we know of any implementations?  Zaar: No.  Adrian: Okay,
       I'll ask on the list and people can reply in private if they need
       to.
Zafar: Thank-you.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
11. MPLS/GMPLS Security Discussions
11a. MPLS/GMPLS Security Framework (Luyuan) [15, 125/150]
     Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-10.ppt>
     Background reading
       - draft-fang-mpls-gmpls-security-framework-00.txt

--1042 Luyuan: There is a large design team for this work (see 1st =
slide).
     We presented this in IETF-67, and called for interest.  The design
     team then formed.  -00 draft was issued before this meeting.  Will
     be presented at both MPLS and CCAMP.  Why did we start a security
     framework at this point, given what has been done in MPLS already?
     The trigger was that the security ADs and reviewers had questioned
     some GMPLS drafts, and wondered whether GMPLS security had been
     adequately addressed in the past.
     Questions started with p2mp, but then went back to TE and
     fundamental parts of GMPLS.  Ross and others asked for a single
     draft to discuss all MPLS/GMPLS security issues.  Any other drafts
     in MPLS/GMPLS should point to this draft as the general framework.
     Protocol extensions with their own security concerns must address
     them themselves.
     Objective is to make this an informational RFC as quickly as
     possible. Will address security implementation implications for
     several protocols, including LDP, RSVP-TE, PCE, P2MP/LDP, VPNs,
     PWs, inter-provider, etc. Scope is broader than core just GMPLS.
     However, general security concerns will not be addressed (will
     reference existing security drafts).
     Luyuan then outlined the content of the -00 draft.
Adrian: I'm really impressed with the quantity and quality of work that
     has gone into this draft in a short time.
Luyuan: Thanks, it was a team effort.
Dimitri: Wondered about duplication of work between this an rpsec/sidr.
Luyuan: Scope is a little bit fuzzy. Some content will touch on routing
     protocols but this is not the focus.
Dimitri: Further question about assuming modes of operation; should the
     draft state the modes of operation under which the network is
     assumed to run.
Luyuan: Again, scope is difficult. Document looks to demonstrate that
     with proper procedure adding MPLS/GMPLS to a network does not make
     it less secure.
Dimitri: Again sought to clarify which 'running mechanisms' were being
     employed in particular deployments being considered by this
     security draft.
Luyuan/Dimitri closed agreeably.

Adrian: Asked George if this work would be owned by the MPLS WG.
George Swallow: That's my understanding, but Ross can overrule me.
Adrian: He wouldn't dare.
Loa: Agree with George.
Ross: Has no opinion on whether this is MPLS/CCAMP.  Can last call it in
     both. No strong opinion, but tend to prefer MPLS unless others
     object.
Kireeti: Should be owned by MPLS, because some bits are MPLS-specific.
Adrian is happy that someone else is doing the work.
Adrian: Asked Monique about whether this overlaps with work done by
     IPSphere.
Monique (from floor): No.

11b. Security AD issues with TE Calls (Adrian) [10, 135/150]
     Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-11.ppt>
     Background reading
       - draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

11c. Security AD issues with Graceful Restart (Adrian) [10, 145/150]
     Slides <HTTP: www3.ietf.org proceedings 07mar slides ccamp-11.ppt>
     Background reading
     - draft-ietf-ccamp-rsvp-restart-ext-08.txt

-1058 Adrian: To close, want to look at two drafts going through
     security AD review, related to what Luyuan has just presented.
     There are two major questions about the GR draft.
     #1  What would happen if a downstream neighbour of a restarting
         node sent a false RecoveryPath message, either accidentally or
         as a result of downstream node being subverted.
     #2  What damage could be done to the restarting node control/data
         plane as a result of such a bogus message?
     Adrian has pasted a long discussion thread on this to ccamp list.
     Trust model in ccamp is peer-to-peer; peers with whom messages are
     exchanged are authenticated.  This isn't about attacks from
     strangers; it is about subverted RSVP-TE nodes.  Adrian questions
     why this is of particular reference to GR?  Surely any subverted
     node could take a variety of actions at any time in the protocol
     (for example, corrupting routes in path messages).  Adrian also
     points out that RecoveryPath is verified against the dataplane on
     the restarting node.  There was also a discussion about falsified
     EROs, and what the consequences might be.

     On the TE-Call draft there were issues about Notify messages which
     are end-to-end communication; a new concept?  How are keys
     established with Notify recipients?  Is Notify processing a
     necessary part of call processing?  This leads to a question of
     whether an automated key distribution mechanism is required.
     Security of calls is definitely a concern, but again Notify
     processing is not specific to calls.  Either RSVP-TE security or
     IPeec (if tunneling) can be used to authenticate origin of Notify
     messages.  Can also use RSVP forwarding to propagate Notify
     messages hop-by-hop, which makes use of RSVP peer authentication as
     above.

     For the restart draft, the ADs are not really totally convinced,
     and would like ccamp to describe what could happen if each message
     was spoofed.  This strikes Adrian as being a lot of work.

     For the call draft, an RFC 4107 analysis is asked for.

     Next step will be to have face-to-face discussions with ADs at this
     IETF to try to get these drafts moved forward, and to clarify the
     security framework so this does not happen to other drafts in
     future.

Yakov Rechter at mic: Would it address GR concern if processing was
     restricted to a single service provider (implying same trust
     domain).  Adrian doesn't see that the Security AD would be happy
     with this because he is talking about node subversion which could
     be in a domain.
Yakov: Indeed, what would happen if all your routers were subverted?
Adrian: I don't know.

Lou: (commented about unreasonableness of feedback from ADs)
Adrian: Yes, perhaps ADs will say 'all of your work is broken, stop'.
Lou: Come on, there's history and deployed protocols here.  ADs are
     welcome to say it's all broken, and there is a new work item to
     make a working protocol to address all this.  We should push back
     very strongly, and not let this stop us from doing our work.
Adrian: Thanks.

Dimitri: Tried to clarify what the questions being answered were.

Ross: I'm trying to figure out what I should actually say.  I don't want
     to get shot.  I have mixed feelings.  When my laptop boots up, it
     says 'you might be infected'.  Actually I know my laptop is
     infected.  Routers might be too.  It's not hard to infect routers;
     administrators use stupid passwords, you can configure routers to
     bring down the network.  However, no vendor is going to implement
     the command 'please send wrong information on graceful restart'.
     The bottom line is that there's not a lot of reason for us to
     define something that no-one has any interest in buying.  That's
     one view.
     Another view is that the internet isn't as secure as it should be.
     But if no-one builds it, there's no point the spec saying it.  In
     the specific case of the restart work, Ross talked to a member of
     the security directorate.  Perhaps we don't need to do anything
     about it, but the directorate would like to know what a router
     would do if it was subverted. Would the conflicting information be
     detected?  We could try to figure out what an implementation would
     do if it got different information from downstream neighbours and
     put that in the draft.  That might be enough for this draft, I
     hope.

Zafar: I'm a little bit concerned about the notify message.  There's
     something you mentioned about making it hop-by-hop, but this would
     be more like a PathErr message.  Could you specify what you mean?
Adrian: On notify, RFC 3473 specifies these two methods, and points out
     a way to do security is hop-by-hop.
Zafar: Has concerns with this.
Adrian: Yes, but these are tradeoffs you may need to make to get e2e
     security.

Yakov Rechter: Wanted to respond to Ross's point about how things only
     get implemented if people are prepared to pay for it.  It's
     presumptious to say that 2 or 3 people in the IESG know what's good
     for everyone.  The IETF needs to address this problem.

Adrian: Watch this space.  Ross and I will report back to the mailing
     list after we've held our side-meetings.

Zafar: Every node does local checks it can do against the ERO.  If every
     node does that (I think implementations do), much of the
     information passed by the neighbor is checked.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

1121 Adrain: Okay, if we're done then perhaps this is a good time for
     folks interested in MEF to gather at the front and talk about it.

     We're done, see you tomorrow.

***********************************************************</FONT>
</FONT></PRE></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C77145.11C00D09--

Delivery-date: Tue, 27 Mar 2007 13:57:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Progressing the discussion on liaison responses
Date: Tue, 27 Mar 2007 14:53:02 +0100
Organization: Old Dog Consulting

Hi,

The Rapporteur of Question 14 of Study Group 15 of the ITU-T  has indicated 
that we have a little more time to generate responses to their recent 
liaisons. Nevertheless, we will try to do what we can to get response out 
quickly where the actions are simple.

Cheers,
Adrian
----- Original Message ----- 
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "BRUNGARD, DEBORAH A, ATTLABS" 
<[email-masked]>
Cc: "Ong, Lyndon" <[email-masked]>
Sent: Tuesday, March 20, 2007 9:37 PM
Subject: RE: Progressing the discussion on liaison responses

Dear Adrian and Deborah,

Slides 9, 10, & 11 indicate that the Q14/15 liaisons are just in and
requesting response from ccamp by April 6th/2nd. Usually we set the
expected responding date so that Q14/15 can consider the reply at the
next meeting. This time, the Darmstadt meeting and the Chicago meeting
are so close. I agree the notice is too short. So for these two Q14/15
liaisons, please take your time to have sufficient discussion within
ccamp. If we can have the ccamp response by May 28 (Monday), we will be
able to address it at the next SG15 Geneva meeting, which is June 4 -
15.

Best Regards,
Kam

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, March 20, 2007 11:39 AM
> To: [email-masked]
> Subject: Progressing the discussion on liaison responses
>
> Hi,
>
> Would appreciate it if you looked at the various liaisons and
> correspondence at www.olddog.co.uk/ccamp.htm and the slides
> Deborah and I wrote at
> http://www3.ietf.org/proceedings/07mar/slides/ccamp-19.ppt
>
> Please comment on any aspect of any of the correspondence as
> Deborah and I try to put together responses. Would be nice if
> your comments were on the CCAMP list rather than in private.
>
> Thanks,
> Adrian

Delivery-date: Mon, 26 Mar 2007 20:54:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Planned liaison responses to ITU-T SG15
Date: Mon, 26 Mar 2007 21:51:24 +0100
Organization: Old Dog Consulting

Hi,

Thanks for the various conversations on and off list.

In order to separate out the issues and avoid future confusion I plan to 
spawn a bunch of liaison responses to SG15. So far I have identified the 
following...

1. Response to "SG15 OTNT Standardization Work Plan"
    For Action
    List of current RFCs for inclusion by reference in the work plan.

2. Response to "SG15 OTNT Standardization Work Plan"
    For Information
    Current plans and rules of engagement for GELS work.

3. Response to "Liaison statement to ccamp regarding work on calls
   and Vcat/LCAS"
    For Information
    Liaise current version of RSVP-TE Call I-D
    Explain current status
    Explain how I-D does not provide an ASON solution without
    additional work
    Give plans for additional work

4. Response to "Liaison statement to ccamp regarding work on calls
   and Vcat/LCAS"
    For Information
    Liaise current version of VCAT/LCAS I-D
    Explain that a new revision that firms up requirements and
    starts on solutions is likely soon
    Promise to liaise the new revision when available

5. Response to "Liaison Statement to CCAMP responding to ccamp
   liaison of 21 February 2007"
    For Action
    Response to the issues of process raised.

6. Response to "Liaison Statement to CCAMP responding to ccamp
   liaison of 21 February 2007"
    For Action
    Responses to questions about ASON routing solution
    Liaise the latest copy of the I-D
    This item may also generate multiple liaisons if we
    find that there are too many retailed issues to respond to

7. Response to "Liaison Statement to CCAMP responding to ccamp
   liaison of 21 February 2007"
    For Comment
    Close down the issue related to call/connection separation

8. Response to "Liaison Statement to CCAMP responding to ccamp
   liaison of 21 February 2007"
    For Comment
    Liaise the latest versions of the MLN I-Ds as requested

9. Unsolicited
    New RFCs
    For Information

I will start generating some draft text for these soon.

Regards,
Adrian 

Delivery-date: Mon, 26 Mar 2007 10:59:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Non-member submission from ["Italo Busi" <[email-masked]>]   
Date: Mon, 26 Mar 2007 11:58:57 +0100
Organization: Old Dog Consulting

> From [email-masked] Fri Mar 23 14:37:09 2007
> To: "Monique Morrow" <[email-masked]>,
>        "Huub van Helvoort" <[email-masked]>,
>        "Ong, Lyndon" <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: ITU-T Q.14/15 alignment with ITU-T SG13 work
>
> Monique,
>
> I apologize, but I cannot recall any OAM requirements for T-MPLS presented 
> by
> Lyndon in his liaison report.
>
> Could you please point me a reference?
>
> Thanks, Italo
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On
>> Behalf Of Monique Morrow
>> Sent: Thursday, March 22, 2007 11:01 AM
>> To: Huub van Helvoort; Ong, Lyndon
>> Cc: [email-masked]
>> Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
>>
>>
>> My question was more specific to the OAM requirements for T-MPLS as
>> presented by Lyndon in his liaison report
>>
>> Will these be different from those sourced in Q5/13?
>>
>> Monique
>>
>>
>> On 22/3/07 5:20 am, "Huub van Helvoort" <[email-masked]> wrote:
>>
>> > Hello Lyndon,
>> >
>> > You wrote:
>> >
>> >> Monique had asked if the equipment specifications work in Q.14/15 in
>> >> ITU-T on Ethernet-over-Transport and T-MPLS was in alignment with
>> >> the work in ITU-T SG13 on the same subjects.
>> >
>> > To avoid more confusion:
>> > The equipment specifications are G.8021 for Transport Ethernet
>> > and G.8121 for T-MPLS. Both are developed in Q9/15.
>> >
>> > Q14/15 is responsible for the management and control of that
>> > system/equipment, i.e. G.EOT_mgmt and G.tmpls_mgmt
>> >
>> >> I received the
>> >> following response from the Rapporteur for Q.14:
>> >>
>> >> The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in
>> >> particular, with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM
>> >> functions and mechanisms for Ethernet based networks).
>> >
>> > Cheers, Huub.

Delivery-date: Mon, 26 Mar 2007 10:49:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw:Non-member submission from ["Ken Young" <[email-masked]>]   
Date: Mon, 26 Mar 2007 11:25:53 +0100
Organization: Old Dog Consulting

> From [email-masked] Thu Mar 22 21:47:49 2007
> Subject: Re: Progressing the discussion on liaison responses
> To: "Adrian Farrel" <[email-masked]>,
> "Dimitri Papadimitriou" <[email-masked]>,
> "Lyndon Ong" <[email-masked]>
> Cc: <[email-masked]>,
> 
> Adrian / Dimitri,
>
> I would support progressing the VLAN ID topic to be inline with the MEF.
>
> Lyndon and I had a quick follow up on the VLAN ID discussion in the hall
> today.  We both had different pictures of how this would work and
> therefore we unsure what problem we were solving.  This really
> underline's Dimitri's point that we need to be sure "we have a correct
> understanding of the problem".
> 
> Lyndon suggested that he could provide a view of the MEF UNI parameters
> and a view on which paramters need to be signaled from some work in the
> OIF.  Let's review this and see if we are on track.
>
> Cheers,
> Ken

Delivery-date: Mon, 26 Mar 2007 10:49:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw:Non-member submission from ["Ken Young" <[email-masked]>]   
Date: Mon, 26 Mar 2007 11:27:29 +0100
Organization: Old Dog Consulting

> From [email-masked] Thu Mar 22 22:23:34 2007
> Subject: RE: Progressing the discussion on liaison responses
> To: "Ong, Lyndon" <[email-masked]>,
> "Adrian Farrel" <[email-masked]>,
> "Dimitri Papadimitriou" <[email-masked]>
> Cc: <[email-masked]>,
> 
> Lyndon,
>
> I believe your response was prompted by my first statement.  I placed
> that in the mail as a suggestion to Dimitri on how to progress the
> discussion.  He specifically stated: "do we want to progress on the
> topic inline with MEF expectations?".  I wanted to throw in my 2 cents
> that I thought this was not a bad way to proceed.
>
> Since we seem to be in agreement, no worries.  Sorry if I caused any
> confusion.
>
> On your second statement, I would like to see the liason exchange with
> the MEF.  A pointer would be awesome.
>
> Thanks!
> Ken
> 
> ________________________________
> 
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Thu 3/22/2007 18:12
> To: Ken Young; Adrian Farrel; Dimitri Papadimitriou
> Cc: [email-masked]; [email-masked]
> Subject: RE: Progressing the discussion on liaison responses
> 
> Hi Ken,
> 
> We may have had a miscommunication here.  I don't think there is any
> question regarding the problem being solved, for the most part, only
> how to solve it (for which OIF is asking IETF for help).
> 
> Liaisons have been exchanged with MEF over the course of the last year
> and MEF has responded encouraging the work to proceed.  If you 
> want I can point you to this exchange.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Ken Young [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 2:47 PM
> To: Adrian Farrel; Dimitri Papadimitriou; Ong, Lyndon
> Cc: [email-masked]; [email-masked]
> Subject: Re: Progressing the discussion on liaison responses
> 
> Adrian / Dimitri,
> 
> I would support progressing the VLAN ID topic to be inline with the MEF.
> 
> Lyndon and I had a quick follow up on the VLAN ID discussion in the hall
> today.  We both had different pictures of how this would work and
> therefore we unsure what problem we were solving.  This really
> underline's Dimitri's point that we need to be sure "we have a correct
> understanding of the problem".
> 
> Lyndon suggested that he could provide a view of the MEF UNI parameters
> and a view on which paramters need to be signaled from some work in the
> OIF.  Let's review this and see if we are on track.
> 
> Cheers,
> Ken

Delivery-date: Mon, 26 Mar 2007 08:35:07 +0000
Date: Mon, 26 Mar 2007 04:32:43 -0400
Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
From: Monique Morrow <[email-masked]>
To: Italo Busi <[email-masked]>, Huub van Helvoort <[email-masked]>, "Ong, Lyndon" <[email-masked]>
CC: <[email-masked]>

Italo,

Was precisely my question in the context of network management as per his
report.

Lyndon has since cross checked with the rapporteur of Q.14.

/m

On 23/3/07 10:37 am, "Italo Busi" <[email-masked]> wrote:

> Monique,
> 
> I apologize, but I cannot recall any OAM requirements for T-MPLS presented by
> Lyndon in his liaison report.
> 
> Could you please point me a reference?
> 
> Thanks, Italo
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On
>> Behalf Of Monique Morrow
>> Sent: Thursday, March 22, 2007 11:01 AM
>> To: Huub van Helvoort; Ong, Lyndon
>> Cc: [email-masked]
>> Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
>> 
>> 
>> My question was more specific to the OAM requirements for T-MPLS as
>> presented by Lyndon in his liaison report
>> 
>> Will these be different from those sourced in Q5/13?
>> 
>> Monique
>> 
>> 
>> 
>> 
>> On 22/3/07 5:20 am, "Huub van Helvoort" <[email-masked]> wrote:
>> 
>>> Hello Lyndon,
>>> 
>>> You wrote:
>>> 
>>>> Monique had asked if the equipment specifications work in Q.14/15 in
>>>> ITU-T on Ethernet-over-Transport and T-MPLS was in alignment with
>>>> the work in ITU-T SG13 on the same subjects.
>>> 
>>> To avoid more confusion:
>>> The equipment specifications are G.8021 for Transport Ethernet
>>> and G.8121 for T-MPLS. Both are developed in Q9/15.
>>> 
>>> Q14/15 is responsible for the management and control of that
>>> system/equipment, i.e. G.EOT_mgmt and G.tmpls_mgmt
>>> 
>>>> I received the
>>>> following response from the Rapporteur for Q.14:
>>>> 
>>>> The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in
>>>> particular, with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM
>>>> functions and mechanisms for Ethernet based networks).
>>> 
>>> Cheers, Huub.
>> 
>> 

Delivery-date: Sat, 24 Mar 2007 10:17:54 +0000
To: [email-masked]
Subject: GELS slides - comments
From: [email-masked]
Date: Sat, 24 Mar 2007 11:14:43 +0100

o) slide 2 - draft-andersson (rev.01)

"   o  Routing Protocol - OSPF-TE, we are running the OSPF-TE exactly as
      implemented by the Dragon project."

-> are there more details available ? more importantly which TE 
information are carried that are of use for explicit route (computation, 
selection, etc.)

section 3.3 suggest to make use of the LSP ATTRIBUTE object (that provides 
the flexibility of adding vectors of flags) - resource affinity can be 
still used per 3209

section 3.4 not sure to understand the purpose of using the suggested 
label as described

o) slide 9 - bw reservation i would suggest parking this item in the more 
general context (to prevent specialization)

o) slide 13 and slide 14 - clearly indicate the need supporting edge to 
edge ethernet LSP provisioning (explicit label control on the egress LSR)

o) more generically for all mechanisms put in place for 802.1q and related 
(B, PB, and PBB) there is a wider question is GMPLS appropriate for the 
support of "domain wide" labels - i am not arguing in favor or against - i 
am just trying to solicit discussion on implications

thanks,
-d.

Delivery-date: Thu, 22 Mar 2007 22:16:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Progressing the discussion on liaison responses
Date: Thu, 22 Mar 2007 18:12:10 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Ken Young" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Ken,

We may have had a miscommunication here.  I don't think there is any
question
regarding the problem being solved, for the most part, only how to solve
it
(for which OIF is asking IETF for help).

Liaisons have been exchanged with MEF over the course of the last year
and
MEF has responded encouraging the work to proceed.  If you want I can
point
you to this exchange.

Cheers,

Lyndon

-----Original Message-----
From: Ken Young [mailto:[email-masked]]=20
Sent: Thursday, March 22, 2007 2:47 PM
To: Adrian Farrel; Dimitri Papadimitriou; Ong, Lyndon
Cc: [email-masked]; [email-masked]
Subject: Re: Progressing the discussion on liaison responses

Adrian / Dimitri,
=20
I would support progressing the VLAN ID topic to be inline with the MEF.
=20
Lyndon and I had a quick follow up on the VLAN ID discussion in the hall
today.  We both had different pictures of how this would work and
therefore we unsure what problem we were solving.  This really
underline's Dimitri's point that we need to be sure "we have a correct
understanding of the problem".
=20
Lyndon suggested that he could provide a view of the MEF UNI parameters
and a view on which paramters need to be signaled from some work in the
OIF.  Let's review this and see if we are on track.
=20
Cheers,
Ken

Delivery-date: Thu, 22 Mar 2007 18:18:37 +0000
Date: Thu, 22 Mar 2007 19:16:20 +0100
To: "Ong, Lyndon" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Progressing the discussion on liaison responses
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>,<[email-masked]>, <[email-masked]>, "JONES Jim D" <[email-masked]>

A way to handle the MTU issue is to signal multiple independent 
LSPs.  The LSPs could be bound together into a single logical 
connection (EVC) using the association object.  This approach could 
be used with either the VID per LSP or the multi-VID per LSP 
approach.  The difference is one of scaling and optimization; i.e., 
(a) the first has lots of LSPs, but has simple/standard VID 
change/add/drop procedures while (b) the second has few LSPs but will 
require specific procedures to handle VID changes/adds/drops.

While intuition leads me to believe that (b) is the better way to go, 
we may want to get the feedback of those presenting the requirements.

Lou
At 08:49 AM 3/21/2007, Ong, Lyndon wrote:

>Hi Folks,
>
>I agree with Dimitri regarding the ad hoc discussions on the VLAN ID, I
>think
>we are close to a working solution (albeit it does not handle the case
>of
>very large numbers of VLAN IDs due to the message size problem Dimitri
>mentions).
>
>Regarding the interworking "cookbook", it may help for people to know
>that this
>was specifically scoped to the G.7713.2 and RFC 3473 specifications and
>not
>beyond this.
>
>Cheers,
>
>Lyndon
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of [email-masked]
>Sent: Tuesday, March 20, 2007 7:06 PM
>To: Adrian Farrel
>Cc: [email-masked]; [email-masked]
>Subject: Re: Progressing the discussion on liaison responses
>
>adrian
>
>o) VLAN I-D
>
>i don't think this is a Call functionality
>
>"No information provided on UNI TSPEC expectations (e.g. granularity of
>C-VLAN within EVC) in Liaison"
>
>i think this has been clarified on this list if my record is correct
>
>"Any outcome of ad hoc discussions yesterday?"
>
>rsv is associated to the vc and there are two modes 1:1
><vc/session,label/session attr.> and 1:N <vc/session,set of
>labels/session attr.> we can cover base cases as long as msg size
>doesn't exceed MTU size
>- the question wrt progress are 1) do we have a correct understanding of
>the problem 2) do we want to progress on the topic inline with MEF
>expectations 3) is the base mode acceptable until a more generic is
>proposed (or shall we propose a single solution covering all cases)
>
>o) the following is odd, in a sense OIF asks to comment but is ignoring
>what we have been developing since those where provided to eliminate
>interworking with ASON (shouldn't that be our first comment ?)
>
>"Our comments are solicited
>Cookbook objectives seem unclear (ignores GMPLS work on UNI, ENNI,
>ASON)"
>
>o) you wrote "Can we help by describing how to map OIF UNI parameters to
>GMPLS signalling?" i don't understand the question, the former is a
>"profile" the latter a protocol - shouldn't be the other way around
>
>o) optical transport plane work - i don't clearly understand what's all
>about but to the question
>
>"-      No mention of GELS. Time to let them know?" answer is yes. the
>point is that such exchange informative ?
>
>o) Send a complete list and ask for it to be included?
>
>yes
>
>o) *    Recent liaison (just in) requests us to liaise
>draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt "before it is published as an
>RFC" and by April 2nd
>-       I-D is past IETF last call. Is it too late?
>
>that's not the question, the point is WHY ? because the applicability
>I-D is not yet respined ? we should address this point by committing
>charter milestones here
>
>o) routing
>
>"Asks us to supply details of our reasoning in selecting OSPF loop
>prevention mechanisms rather than applying ISIS mechanisms to OSPF We
>could supply this reasoning, but to what purpose?
>We note that we previously asked if the ITU-T had any technical issues
>with our choice and received no answer."
>
>isn't the answer obvious ?
>
>"Asks for further explanation of why we declined to change "an Li may be
>advertised by only one Ri at any time" to "a TE link is only advertised
>by one Ri at a time.""
>
>i'd like to re-state that the RFC 4652 (in its draft version) maintained
>an open item on multiple Ri per Li - no answer, hence closed to re-open
>pls provide reasoning (interest argument is a consequence not a cause)
>
>"Restates that we should use "MUST" not "optional" in describing the
>inclusion of timeslot accounting information (section 4.2) This seems to
>be a misunderstanding of context New revision of I-D clarifies the text
>We can liaise back to thank them for prompting us to clarify"
>
>ok
>
>"Request liaison of any work on multi-layer networks We should do this
>especially for the MLN requirements and evaluation that are soon to have
>last call Very many of our I-Ds and some in PCE are applicable to
>multi-layer networks. Liaise them all?"
>
>at least those on control plane at for the layers that concern ITU
>meaning SDH & OTH, for the PCE ask to PCE, but what is their real
>concern ?
>
>"Set respond-by date to coincide with end of WG last call?
>Request explanation of how redistribution of information continues when
>a redistribution point fails Simply send an explanation?"
>
>done
>
>o) call i-d
>
>no, i think we're done
>
>note i observe that the list of discussion points is quite large most of
>those are non-issues we should ask for splitting real concerns from
>informational aspects
>
>thanks,
>-d.
>
>
>
>
>
>"Adrian Farrel" <[email-masked]>
>Sent by: [email-masked]
>20/03/2007 16:39
>Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the discussion on liaison responses
>
>
>Hi,
>
>Would appreciate it if you looked at the various liaisons and
>correspondence at www.olddog.co.uk/ccamp.htm and the slides Deborah and
>I wrote at http://www3.ietf.org/proceedings/07mar/slides/ccamp-19.ppt
>
>Please comment on any aspect of any of the correspondence as Deborah and
>I
>
>try to put together responses. Would be nice if your comments were on
>the CCAMP list rather than in private.
>
>Thanks,
>Adrian

Delivery-date: Thu, 22 Mar 2007 10:02:56 +0000
Date: Thu, 22 Mar 2007 06:01:28 -0400
Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
From: Monique Morrow <[email-masked]>
To: Huub van Helvoort <[email-masked]>, "Ong, Lyndon" <[email-masked]>
CC: <[email-masked]>

My question was more specific to the OAM requirements for T-MPLS as
presented by Lyndon in his liaison report

Will these be different from those sourced in Q5/13?

Monique

On 22/3/07 5:20 am, "Huub van Helvoort" <[email-masked]> wrote:

> Hello Lyndon,
> 
> You wrote:
> 
>> Monique had asked if the equipment specifications work in Q.14/15 in
>> ITU-T on Ethernet-over-Transport and T-MPLS was in alignment with
>> the work in ITU-T SG13 on the same subjects.
> 
> To avoid more confusion:
> The equipment specifications are G.8021 for Transport Ethernet
> and G.8121 for T-MPLS. Both are developed in Q9/15.
> 
> Q14/15 is responsible for the management and control of that
> system/equipment, i.e. G.EOT_mgmt and G.tmpls_mgmt
> 
>> I received the
>> following response from the Rapporteur for Q.14:
>> 
>> The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in
>> particular, with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM
>> functions and mechanisms for Ethernet based networks).
> 
> Cheers, Huub.

Delivery-date: Thu, 22 Mar 2007 09:21:30 +0000
Date: Thu, 22 Mar 2007 10:20:21 +0100
From: Huub van Helvoort <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
CC:  [email-masked]
Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work

Hello Lyndon,

You wrote:

> Monique had asked if the equipment specifications work in Q.14/15 in
> ITU-T on Ethernet-over-Transport and T-MPLS was in alignment with
> the work in ITU-T SG13 on the same subjects. 

To avoid more confusion:
The equipment specifications are G.8021 for Transport Ethernet
and G.8121 for T-MPLS. Both are developed in Q9/15.

Q14/15 is responsible for the management and control of that
system/equipment, i.e. G.EOT_mgmt and G.tmpls_mgmt

> I received the
> following response from the Rapporteur for Q.14:
> 
> The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in 
> particular, with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM 
> functions and mechanisms for Ethernet based networks).

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Thu, 22 Mar 2007 08:53:58 +0000
Date: Thu, 22 Mar 2007 04:53:08 -0400
Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
From: Monique Morrow <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3257383988_178552
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Thanks Lyndon!

/m

On 22/3/07 4:19 am, "Ong, Lyndon" <[email-masked]> wrote:

> Hi Folks,
>  
> Monique had asked if the equipment specifications work in Q.14/15 in ITU-T on
> Ethernet-over-Transport
> and T-MPLS was in alignment with the work in ITU-T SG13 on the same subjects.
> I received the following
> response from the Rapporteur for Q.14:
>  
> The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in particular,
> with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM functions and mechanisms
> for Ethernet based networks).
>  
> Cheers,
>  
> L. Ong
> 

--B_3257383988_178552
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: ITU-T Q.14/15 alignment with ITU-T SG13 work</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Thank=
s Lyndon!<BR>
<BR>
/m<BR>
<BR>
<BR>
On 22/3/07 4:19 am, &quot;Ong, Lyndon&quot; &lt;[email-masked]&gt; wrote:<=
BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Arial"=
>Hi Folks,<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE=3D"Arial">Monique had asked if the equipment specifications=
 work in Q.14/15 in ITU-T on Ethernet-over-Transport<BR>
and T-MPLS was in alignment with the work in ITU-T SG13 on the same subject=
s. &nbsp;I received the following<BR>
response from the Rapporteur for Q.14:<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">The EoT and T-MPLS works in=
 SG15 are in alignment with Q5/13, in particular, with Y.17TOM (T-MPLS OAS M=
echanism) and Y.1731 (OAM functions and mechanisms for Ethernet based networ=
ks).<BR>
</FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Cheers,<BR>
</FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">L. Ong<BR>
</FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Verda=
na, Helvetica, Arial"><BR>
</FONT></SPAN>
</BODY>
</HTML>

--B_3257383988_178552--

Delivery-date: Thu, 22 Mar 2007 08:23:06 +0000
Content-class: urn:content-classes:message
Subject: ITU-T Q.14/15 alignment with ITU-T SG13 work
Date: Thu, 22 Mar 2007 04:19:23 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Folks,
=20
Monique had asked if the equipment specifications work in Q.14/15 in
ITU-T on Ethernet-over-Transport
and T-MPLS was in alignment with the work in ITU-T SG13 on the same
subjects.  I received the following
response from the Rapporteur for Q.14:
=20
The EoT and T-MPLS works in SG15 are in alignment with Q5/13, in
particular, with Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM
functions and mechanisms for Ethernet based networks).
=20
Cheers,
=20
L. Ong

------_=_NextPart_001_01C76C5A.CD544131
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.6000.16414" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007>Hi=20
Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D557501508-22032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D557501508-22032007>Monique had asked if=20
the equipment specifications work in Q.14/15 in ITU-T on=20
Ethernet-over-Transport</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007>and =
T-MPLS was in=20
alignment with the work in ITU-T SG13 on the same subjects.&nbsp; I =
received the=20
following</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D557501508-22032007>response from the=20
Rapporteur for Q.14:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D557501508-22032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007><FONT=20
color=3D#0000ff>The EoT and T-MPLS works in SG15 are in alignment with =
Q5/13,=20
<FONT face=3DArial size=3D2><SPAN class=3D773024415-20032007>in =
particular, with=20
Y.17TOM (T-MPLS OAS Mechanism) and Y.1731 (OAM functions and mechanisms =
for=20
Ethernet based networks).</SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007><FONT=20
color=3D#0000ff><FONT face=3DArial size=3D2><SPAN=20
class=3D773024415-20032007></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV=
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007><FONT=20
color=3D#0000ff><FONT face=3DArial size=3D2><SPAN=20
class=3D773024415-20032007>Cheers,</SPAN></FONT></FONT></SPAN></FONT></DI=
V>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007><FONT=20
color=3D#0000ff><FONT face=3DArial size=3D2><SPAN=20
class=3D773024415-20032007></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV=
<DIV><FONT face=3DArial size=3D2><SPAN class=3D557501508-22032007><FONT=20
color=3D#0000ff><FONT face=3DArial size=3D2><SPAN =
class=3D773024415-20032007>L.=20
Ong</SPAN></FONT></FONT></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C76C5A.CD544131--

Delivery-date: Wed, 21 Mar 2007 07:54:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Progressing the discussion on liaison responses
Date: Wed, 21 Mar 2007 03:49:25 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "JONES Jim D" <[email-masked]>

Hi Folks,

I agree with Dimitri regarding the ad hoc discussions on the VLAN ID, I
think
we are close to a working solution (albeit it does not handle the case
of
very large numbers of VLAN IDs due to the message size problem Dimitri
mentions).

Regarding the interworking "cookbook", it may help for people to know
that this
was specifically scoped to the G.7713.2 and RFC 3473 specifications and
not
beyond this. =20

Cheers,

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, March 20, 2007 7:06 PM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: Progressing the discussion on liaison responses

adrian

o) VLAN I-D

i don't think this is a Call functionality=20

"No information provided on UNI TSPEC expectations (e.g. granularity of
C-VLAN within EVC) in Liaison"

i think this has been clarified on this list if my record is correct

"Any outcome of ad hoc discussions yesterday?"

rsv is associated to the vc and there are two modes 1:1
<vc/session,label/session attr.> and 1:N <vc/session,set of
labels/session attr.> we can cover base cases as long as msg size
doesn't exceed MTU size
- the question wrt progress are 1) do we have a correct understanding of
the problem 2) do we want to progress on the topic inline with MEF
expectations 3) is the base mode acceptable until a more generic is
proposed (or shall we propose a single solution covering all cases)

o) the following is odd, in a sense OIF asks to comment but is ignoring
what we have been developing since those where provided to eliminate
interworking with ASON (shouldn't that be our first comment ?)=20

"Our comments are solicited
Cookbook objectives seem unclear (ignores GMPLS work on UNI, ENNI,
ASON)"

o) you wrote "Can we help by describing how to map OIF UNI parameters to
GMPLS signalling?" i don't understand the question, the former is a
"profile" the latter a protocol - shouldn't be the other way around

o) optical transport plane work - i don't clearly understand what's all
about but to the question=20

"-      No mention of GELS. Time to let them know?" answer is yes. the=20
point is that such exchange informative ?

o) Send a complete list and ask for it to be included?

yes

o) *    Recent liaison (just in) requests us to liaise=20
draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt "before it is published as an
RFC" and by April 2nd=20
-       I-D is past IETF last call. Is it too late?

that's not the question, the point is WHY ? because the applicability
I-D is not yet respined ? we should address this point by committing
charter milestones here

o) routing

"Asks us to supply details of our reasoning in selecting OSPF loop
prevention mechanisms rather than applying ISIS mechanisms to OSPF We
could supply this reasoning, but to what purpose?
We note that we previously asked if the ITU-T had any technical issues
with our choice and received no answer."

isn't the answer obvious ?

"Asks for further explanation of why we declined to change "an Li may be
advertised by only one Ri at any time" to "a TE link is only advertised
by one Ri at a time.""

i'd like to re-state that the RFC 4652 (in its draft version) maintained
an open item on multiple Ri per Li - no answer, hence closed to re-open
pls provide reasoning (interest argument is a consequence not a cause)

"Restates that we should use "MUST" not "optional" in describing the
inclusion of timeslot accounting information (section 4.2) This seems to
be a misunderstanding of context New revision of I-D clarifies the text
We can liaise back to thank them for prompting us to clarify"

ok

"Request liaison of any work on multi-layer networks We should do this
especially for the MLN requirements and evaluation that are soon to have
last call Very many of our I-Ds and some in PCE are applicable to
multi-layer networks. Liaise them all?"

at least those on control plane at for the layers that concern ITU
meaning SDH & OTH, for the PCE ask to PCE, but what is their real
concern ?

"Set respond-by date to coincide with end of WG last call?
Request explanation of how redistribution of information continues when
a redistribution point fails Simply send an explanation?"

done

o) call i-d

no, i think we're done

note i observe that the list of discussion points is quite large most of
those are non-issues we should ask for splitting real concerns from
informational aspects

thanks,
-d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
20/03/2007 16:39
Please respond to "Adrian Farrel"
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Progressing the discussion on liaison responses

Hi,

Would appreciate it if you looked at the various liaisons and
correspondence at www.olddog.co.uk/ccamp.htm and the slides Deborah and
I wrote at http://www3.ietf.org/proceedings/07mar/slides/ccamp-19.ppt

Please comment on any aspect of any of the correspondence as Deborah and
I=20

try to put together responses. Would be nice if your comments were on
the CCAMP list rather than in private.

Thanks,
Adrian=20

Delivery-date: Wed, 21 Mar 2007 02:08:50 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Progressing the discussion on liaison responses
From: [email-masked]
Date: Wed, 21 Mar 2007 03:05:43 +0100

Delivery-date: Tue, 20 Mar 2007 17:33:29 +0000
Cc: Mach Chen <[email-masked]>, [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: My comments about draft-chen-ccamp-ospf-interas-te-extension-01.txt
Date: Tue, 20 Mar 2007 18:30:44 +0100
To: zhangrenhai 18605 <[email-masked]>

Thanks.

JP.

On Mar 20, 2007, at 5:25 PM, zhangrenhai 18605 wrote:

>
> Hi, JP
>
> Thanks a lot for your comments, we will fold this into the next  
> version of the draft.
>
> Best regards,
> Zhang Renhai
>
>> Hi,
>>
>> Just to reiterate my comment, could you please clearly spell out
>> in
>> the document that the intention is *not* to flood any TE related
>> information of any kind across domains but only the remote AS
>> number
>> and link type ?
>>
>> Thanks.
>>
>> JP.
>>

Delivery-date: Tue, 20 Mar 2007 16:33:46 +0000
Date: Wed, 21 Mar 2007 00:25:31 +0800
From: zhangrenhai 18605 <[email-masked]>
Subject: Re:My comments about draft-chen-ccamp-ospf-interas-te-extension-01.txt
To: JP Vasseur <[email-masked]>
Cc: Mach Chen <[email-masked]>, [email-masked]

Hi, JP

Thanks a lot for your comments, we will fold this into the next version of the draft.

Best regards,
Zhang Renhai

> Hi,
> 
> Just to reiterate my comment, could you please clearly spell out 
> in  
> the document that the intention is *not* to flood any TE related  
> information of any kind across domains but only the remote AS 
> number  
> and link type ?
> 
> Thanks.
> 
> JP.
> 

Delivery-date: Tue, 20 Mar 2007 15:39:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Progressing the discussion on liaison responses
Date: Tue, 20 Mar 2007 15:39:11 -0000
Organization: Old Dog Consulting

Hi,

Would appreciate it if you looked at the various liaisons and correspondence 
at www.olddog.co.uk/ccamp.htm and the slides Deborah and I wrote at 
http://www3.ietf.org/proceedings/07mar/slides/ccamp-19.ppt

Please comment on any aspect of any of the correspondence as Deborah and I 
try to put together responses. Would be nice if your comments were on the 
CCAMP list rather than in private.

Thanks,
Adrian 

Delivery-date: Tue, 20 Mar 2007 15:37:31 +0000
Cc: [email-masked]
From: JP Vasseur <[email-masked]>
Subject: My comments about draft-chen-ccamp-ospf-interas-te-extension-01.txt
Date: Tue, 20 Mar 2007 16:34:21 +0100
To: Mach Chen <[email-masked]>, Zhang Renhai <[email-masked]>

Hi,

Just to reiterate my comment, could you please clearly spell out in  
the document that the intention is *not* to flood any TE related  
information of any kind across domains but only the remote AS number  
and link type ?

Thanks.

JP.

Delivery-date: Mon, 19 Mar 2007 14:11:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: New Liaison Statement, "Liaison statement to ccamp regarding work on calls and Vcat/LCAS" 
Date: Mon, 19 Mar 2007 14:08:11 -0000
Organization: Old Dog Consulting

Hi,

We have received a second liaison statement from Question 14 of Study Group 
15 of the IETF.

This can be seen at www.olddog.co.uk/ccamp.htm

We are asked to respond by 2nd April 2007

> Title: Liaison statement to ccamp regarding work on calls and Vcat/LCAS
> Submission Date: 2007-03-14
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=306
> Attachment(s):
>     text of liaison 
> (https://datatracker.ietf.org/documents/LIAISON/file407.doc)

We understand that IETF ccamp is currently progressing towards RFC status:
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls
 - draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

Section 2.1 of this draft states:
“2.1 Applicability to ASON

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

Since ITU-T SG 15 has responsibility for the ASON architecture, we would 
appreciate the opportunity to review this draft and provide our comments 
before it is published as an RFC.  We would also appreciate a view from IETF 
ccamp on how this draft would be applied in the context of an ASON network, 
in particular how the ASON requirements are supported.

Additionally, we observe with interest the progress on the draft:
Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment 
Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
 - draft-ietf-ccamp-gmpls-vcat-lcas-01.txt

This draft uses mechanisms defined by ITU-T SG 15 in Recommendations G.7041 
and G.7042 and is also applicable to an ASON network.  Therefore, we would 
appreciate having an opportunity to review and provide input on this draft 
from an architectural perspective before it is published as an RFC.

An electronic copy of this liaison statement is available at:
http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0702/wd/wd38r4_ls_ccamp.doc 

Delivery-date: Mon, 19 Mar 2007 14:11:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: New Liaison Statement, "Liaison statement to ccamp responding to ccamp liaison of 21 February 2007" 
Date: Mon, 19 Mar 2007 14:04:46 -0000
Organization: Old Dog Consulting

Hi,

We have received the following liaison from Question 14 of Study Group 15 of 
the ITU-T. A response is requested by 6th April 2007.

As usual, you can find the details at www.olddog.co.uk/ccamp.htm

Thanks,
Adrian

> Title: Liaison statement to ccamp responding to ccamp liaison of 21 
> February 2007
> Submission Date: 2007-03-14
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=305
> Attachment(s):
>     text of liaison 
> (https://datatracker.ietf.org/documents/LIAISON/file406.doc)

Thank you for your response to our previous liaison statement on the current 
ASON work in ccamp.  With respect to the current liaison statement we have 
the following comments:

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.

In the context of an n:1or m:n relationship between Routing Controllers 
(RCs) and Transport Nodes the liaison states “we have yet to hear from 
anyone who wishes to implement or deploy in this ratio”.  While there may 
have not been direct input from CCAMP participants on this, the ITU-T 
liaison clearly expressed interest in these scenarios on the part of ITU-T 
participants.  We would appreciate understanding further the concerns in 
IETF ccamp with the wording change that was proposed in our last liaison to 
replace “Li” with “TE Link” in section 5.1.  Please note that in our 
previous liaison that the abbreviation SC refers to Signalling Controller 
(e.g. a RSVP instance).  Please note that the ASON terms and abbreviations 
are defined in ITU-T Recommendation G.8081 (available for free download from 
the ITU-T web site).

Regarding the use of “optional” in the draft for timeslot accounting, we 
believe “MUST” to be more appropriate to meet the requirements defined in 
G.7715.1, whereas “optional” implies that ASON requirements can be met 
without providing this level of accounting detail.  We agree that WDM 
systems do not have timeslots.  ASON is not specific to TDM networks, it may 
be applied to any network technology that can be modelled using G.805.  To 
achieve this ASON manages link connections.  Time slots and wavelengths are 
examples of link connections.  Therefore, routing announcements for ASON 
must contain link connection accounting information.

For the Local TE Router ID, we believe that “SHOULD only be included…if the 
Router_ID is advertising on behalf of more than one TE_Router_ID ” is overly 
constrained, and “MUST be included” is necessary since identifier separation 
is an ASON requirement.  This allows for the case of multiple Li per Ri (a 
common case for ASON).  This also allows separation of the identifiers used 
in the information being distributed from the identifiers used by the 
protocol supporting the distribution.  We do not require inter-operability 
with legacy OSPF routers in an ASON context.

The liaison states  “Please keep us informed as you evolve ASON to include 
multi-layer networks and any related GMPLS protocol requirements.”  It 
should be noted that ITU-T work has been addressing multi-layer networks for 
ASON for some time.  The results of this multi-layer work are reflected in 
G.7715.1 (2004) section 9.5, G.8080 amendment 2 (2005) sections 6.5 and 6.6, 
with further detail in G.8080 version 2 (2006) sections 6.5, 6.6 and 8.5 
(Available for free download from the ITU-T web site).  Previous ITU-T 
liaison statements have shared the drafts in progress and the final results. 
We request that you liaise any work that you have under way on multi-layer 
networks.

The liaison states: “With regard to "speedy recovery", can you clarify your 
concern on LS MAX Age and the implications for recovery? Are you saying that 
your concern is the continued behavior of upward dissemination of routing 
information in the event that the selected RC performing the dissemination 
fails?”.  Our expectation is that the parent/child redistribution of 
information will be continuous even when a redistribution point has failed. 
Could you explain how the mechanism that has been proposed behaves under 
this condition.
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.

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.  However, 
the effectiveness of this SDO liaison relationship could be improved.

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.

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.  ITU-T SG15 continues to be interested in providing 
clarification or validation of IETF ccamp interpretation of the ASON 
requirements and therefore continues to 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.

An electronic copy of this liaison statement is available at:

http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0702/wd/rd29r6_ls_ccamp.doc 

Delivery-date: Mon, 19 Mar 2007 01:31:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
Date: Sun, 18 Mar 2007 21:28:42 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jean Philippe Vasseur \(jvasseur\)" <[email-masked]>, <[email-masked]>

Dear Dimitri-=20

Thanks for your comments and sorry for the delay in replying. Please see
in-line.=20

Thanks

Regards... Zafar =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]=20
> Sent: Wednesday, March 07, 2007 7:28 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); [email-masked];=20
> Brungard, Deborah A, ALABS; Jean Philippe Vasseur (jvasseur);=20
> [email-masked]
> Subject: Re: Next steps for=20
> draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
>=20
> zafar -
>=20
> o) would it be possible to sum'up changes you have been=20
> provided since so far ?
>=20

Dimitri-=20

The delta was to mainly addresses comments received. The major comments
were (quoting from respective email):=20

"- not sure to understand why the PathErr/Notify can be processed by the

head-end only (what about segment recovery and stitching case) - why
only=20
MBB is possible upon reception (pls use E2E recovery/Segment recovery=20
capabilities as you address GMPLS networks)".

How this comment is addressed:

Re: segment recovery and stitching case, definition of the node that can
perform GS procedure has been extended to include Ingress LSR of an
S-LSP. See enclosed slides for details.

Re: why only MBB is possible upon reception.=20

Text in the new version is modified such that it allows the following-=20

- Graceful shutdown may be exercised using make-before-break or FRR/
segment recovery procedure.=20
- When PLR/ branch node receive a Path Error with Graceful Shutdown
indication,=20
  	o It MUST forward the Path Error to the Ingress node.
  	O Based on a local decision, PLR/ branch node MAY trigger FRR/
segment recovery.

"- in case shutdown of a protected component link (of a bundle) is=20
initiated why can't link protection be used ?"

How this comment is addressed:

Based on a local decision, PLR/ branch node MAY trigger FRR/ segment
recovery to recover from failure of a component link.=20

"- compared to path-reopt, error description is identical for the TE
link=20
case which leads to the following point - if errors code/value are the=20
same how to distinguish them"

This ID inherits the Ingress behavior from RFC 4736, which says, "Upon
receiving an RSVP PERR message with Error code 25 and Error sub- code 7
(Local link maintenance required) or 8 (Local node maintenance
required), the Head-end LSR SHOULD perform a TE LSP reoptimization".=20
This drafts extends the handling of this error code/ sub-code at PLR/
branch node (which includes the case where  ingress node is PLR/ branch
node). IMO no need for adding a new perr subcode. =20

> o) would it be possible to clarify the following statement
>=20
> "- Graceful shutdown mechanisms are required to address TE LSPs=20
>    spanning multiple domains, as well as intra domain TE LSPs. "
>=20
> afaik you don't shutdown LSPs but Links - right ?

This is correct. We will change the wording to make it clear.=20

>=20
> thanks,
> -d.
>=20
>=20
>=20
>=20
>=20
> "Zafar Ali \(zali\)" <[email-masked]>
> Sent by: [email-masked]
> 02/03/2007 00:41
> =20
>         To:     "Adrian Farrel" <[email-masked]>,=20
> "Brungard, Deborah=20
> A, ALABS" <[email-masked]>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[email-masked]>, "Jean Philippe Vasseur=20
> \(jvasseur\)"=20
> <[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>
>         Subject:        Next steps for=20
> draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
>=20
>=20
> Hi Adrian, Deborah, Dimitri, and campers-=20
> =20
> As we mentioned at the last IETF meeting,=20
> http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.ht
> m, we have addressed all outstanding comments, except the=20
> following comment from Dimitri, related to this ID. Should=20
> you have any further comment, please share.=20
> =20
> The only remaining comment that is not closed is "should this=20
> ID be informational or standard track". IMO the ID defines a=20
> new error-subcode and some specific behavior, and should be=20
> standard track. Can you please comment on this.=20
> =20
> The ID has been stable for quite some time and following the=20
> closure of the above, we would like to request last call.=20
> =20
> Thanks
> =20
> Regards... Zafar =20
>=20

Envelope-to: [email-masked]
Delivery-date: Sun, 18 Mar 2007 09:19:19 +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: 'Crankback Signaling Extensions for  MPLS and GMPLS RSVP-TE' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Sun, 18 Mar 2007 05:16:23 -0400

The IESG has approved the following document:

- 'Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE '
   <draft-ietf-ccamp-crankback-06.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 Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-06.txt

Technical Summary
 
   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP recovery to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC3473. These extensions mean that the LSP
   setup request can be retried on an alternate path that detours around
   blocked links or nodes.
 
Working Group Summary
 
   No dissent. There was some comment that the document contains too
   many sub-TLVs for conveying crankback information , but for each
   individual TLV the consensus was to retain it (see PROTO writeup
   in comments in ID tracker). 
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG.
   The spec has been updated in response to comments from the AD (Ross)
   as well as Security Directorate comments. The document was also 
   liaisoned and reviewed by ITU-T's SG15.

Note to RFC Editor
 
   There are a few typos, particularly in documents referenced,
   that need to be corrected. The set of corrections (provided by
   Adrian Farrel):

   ====
   Section 2.1
   s/[RC3473]/[RFC3473]/
   ===
   Section 4.5, point 4)
   s/[RFC4373]/[RFC3473]/
   ===
   Section 13
   DELETE
     [G8080]   ITU-T Recommendation G.808/Y.1304, Architecture for the
               Automatically Switched Optical Network (ASON), November
               2001. For information on the availability of this
               document, please see http://www.itu.int.
   ===
   Section 13
   ADD
     [RFC4201] Kompella, K., Rekhter, Y., and Berger, L. "Link Bundling
               in MPLS Traffic Engineering (TE)", RFC 4201, October
               2005.
   ===

Delivery-date: Fri, 16 Mar 2007 16:27:18 +0000
To: [email-masked]
From: OGAKI Kenichi <[email-masked]>
Subject: I-D ACTION:draft-otani-ccamp-gmpls-cspf-constraints-05.txt 
Date: Sat, 17 Mar 2007 01:24:28 +0900

Hello All,

Please find the new revision (05) of "Considering Generalized  
Multiprotocol Label Switching Traffic Engineering Attributes During  
Path Computation".

http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf- 
constraints-05.txt

The document provides guidelines for the consideration of Generalized  
Multiprotocol Label Switching (GMPLS) Traffic-Engineering (TE)  
attributes for computation of routes for Label Switched Paths (LSPs) in  
a GMPLS network.

We have made a number of changes to make the document clearer and added  
some new sections including security.

We would welcome your feedback and thoughts.

Regards,
Tomo, Kenichi, & Dan

Delivery-date: Thu, 15 Mar 2007 23:19:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Don't forget to send me your slides!
Date: Thu, 15 Mar 2007 23:12:48 -0000
Organization: Old Dog Consulting

Hi,

It is really helpful to everyone and especially the non-native English 
speakers if we can get the slides posted before the meeting, so don't forget 
to send them to us.

Thanks,
Adrian and Deborah 

Envelope-to: [email-masked]
Delivery-date: Mon, 12 Mar 2007 21:24:08 +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: 'Routing extensions for discovery of  Multiprotocol (MPLS) Label Switch Router (LSR) Traffic  Engineering (TE) mesh membership' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 12 Mar 2007 17:23:10 -0400

The IESG has approved the following document:

- 'Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 
   Router (LSR) Traffic Engineering (TE) mesh membership '
   <draft-ietf-ccamp-automesh-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 Bill Fenner.

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

Technical Summary
 
  The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
  Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
  Label Switch Routers (LSR) is a common deployment scenario of MPLS
  Traffic Engineering either for bandwidth optimization, bandwidth
  guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
  may require the configuration of potentially a large number of TE
  LSPs (on the order of the square of the number LSRs).  This document
  specifies Interior Gateway Protocol (IGP) routing extensions for
  Intermediate System-to-Intermediate System (IS-IS) and Open Shortest
  Path First (OSPF) so as to provide an automatic discovery of the set
  of LSRs members of a mesh in order to automate the creation of such
  mesh of TE LSPs.

Working Group Summary
 
  No dissent reported. There has been some discussion of the wisdom 
  of putting this information in an IGP (rather than BGP or somewhere
  else) within the routing directorate and a few other relevant folks
  (eg, chairs of IS-IS and/or OSPF WGs). The consensus is clearly to 
  go ahead with this draft as specified. Based on this discussion,  
  appropriate text was added to the document that discusses this 
  issue briefly. The document was last called in the IS-IS and OSPF
  working groups in addition to the CCAMP WG. 

Protocol Quality
 
  Ross Callon has reviewed this for the IESG. According to the PROTO
  writeup there are implementations and at least some deployment. 

IANA Note

  The -03 and -04 versions of the draft contains an updated IANA 
  considerations section which is intended to respond to the IANA   
  questions entered into the tracker on Sept 27, 2006.

Delivery-date: Mon, 12 Mar 2007 19:52:14 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt 
Date: Mon, 12 Mar 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		: OSPFv2 Routing Protocols Extensions for ASON Routing
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt
	Pages		: 0
	Date		: 2007-3-12
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 
    
   This document provides the extensions of the OSPFv2 Link State 
   Routing Protocol to meet the routing requirements for an 
   Automatically Switched Optical Network (ASON) as defined by ITU-T.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-ospf-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: Mon, 12 Mar 2007 10:05:44 +0000
Date: Mon, 12 Mar 2007 18:03:12 +0800
From: "gyzhang" <[email-masked]>
To: "ccamp" <[email-masked]>
Subject: A new draft draft-xie-ccamp-lsp-dppm-00.txt -- brif background

Delivery-date: Sat, 10 Mar 2007 21:29:04 +0000
Date: Sat, 10 Mar 2007 13:26:23 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]

--0-611198405-1173561983=:91906
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,

I probably do not make myself clear, but you don't seem to see what I am saying. Let's continue the discussion in Prague. Hoefully, we will also hear what the authors of RFC3630 have to say.

See you soon,
Igor

[email-masked] wrote: igor 

the first sentence is the disconnect, per 3630 

"The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear 
exactly once."

" The Link ID sub-TLV identifies the other end of the link.  For
  point-to-point links, this is the Router ID of the neighbor."

you wrote

"TE links must be uniqely identifed either as numbered or unnumbered 
(combination of TERtrID and LinkID)."

this is totally incorrect, there is a local/remote sub-TLV defined for 
numbered TE links

in fact what the present document does is to define a sub-TLV to allow 
identification of unnumbered TE links (associated to the TE router ID 
rather than the Router ID)

thanks,
-d.

Igor Bryskin 
10/03/2007 14:10
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[email-masked]
        Subject:        RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Dimitri,

But who said that linkID must be unique per routerID? Of course, not. It 
must be unique per TE Router ID. The fact that the same RC manages several 
TE RTRs does not change a thing. The paths are computed on the network TE 
graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE 
links must be uniqely identifed either as numbered or unnumbered 
(combination of TERtrID and LinkID). How the links are advertised - by 
separate RCs, the same RC or via no RC (statically configured) - is of no 
importance.

Igor

[email-masked] wrote:
igor

not an issue of TE router ID uniqueness, without this additional sub-TLV, 
an unnumbered local id may not be unique per router_id, hence the addition 

of this sub-TLV (TE Router ID being unique per router_id) 

-d

Igor Bryskin 
09/03/2007 22:36

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[email-masked]
Subject: RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Dimitri,

I don't see how we can manage the situation where TENodeIds are not 
unique. At the end of the day we must process EROs/RROs that are build
of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not 

unique, how then we can identify the specified link? So what do you 
suggest we put in each of these two fields?

[email-masked] wrote:
igor 

but it doesn't solve the issue (and introduces different setting and 
processing of the link id value from rfc 3630) indeed, in ASON RC can be 
associated to multiple "nodes", each of these nodes can have overlapping 
id spaces (to identify the "links") 

for that reason the solution is that each TE link (top level) TLV has a 
new sub-TLV that associates the local and remote "node id" (the former and 

latter takes the TE Router ID as value)

it is the substance of what i have been pointing to you in my initial 
e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing 
protocol MUST be able to disambiguate the advertised TE links so that they 

can be associated with the correct TE Router ID.")

-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 20:29

To: "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 
, [email-masked]
Subject: RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Lyndon,

Let me try to explain my point. 

Basically, we have two solutions to address the situation when the 
relationship between a router controller and data plane switches (TE nodes 

or TE routers) are 1:N, that is, when a single controller manages multiple 

TE routers.

Solution 1 (suggested in the draft):

Each TE Link advertising is extended with Local/Remote TE Router IDs pair. 

In this case, what is in the LinkID sub-TLV is not important really.

Solution 2 (mine)

The Router Address TLV is extended to advertise all TE Router IDs 
controlled by the advertising controller as routable addresses. The TE 
Link TLV is extended to advertise the local TE Router ID. However, there 
is no need to advertise the remote TE Router ID, because this is the 
function of the existing LinkID sub-TLV, which is to identify the remote 
end of the advertised TE link Ã¢â‚¬â€œ remote TE Router ID.

Both these approaches solve the problem; however, an important question to 

answer is:

Do we need the TE Router IDs to be routable addresses?

The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. 
For example, if the network
is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will 
contain
path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable 
solves the problem how to signal the Path message along the provisioned 
path..
If you agree with this, than you will also agree that all TE Router IDs 
should be advertised within Router Address TLV
Hope that this helps.

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

That was my understanding also, I don't see any issue with this.

Cheers,

Lyndon 

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

Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; 
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 

Router ID of the neighbor for point-to-point links) MUST appear exactly 
once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 

" 

which is exactly what you are saying - when i say "it identifies the 
remote RC not the remote data plane "node" in case the remote RC is 
associate to n nodes" read "it is set to the router_id that identifies the 

remote RC..."
in brief, we keep the semantic and add a discriminator (that does not 
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple 

associations in different LSAs i don't where the problem is ?

thanks,
-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID? 

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case 
the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2. Link ID

The Link ID sub-TLV identifies the other end of the link. For

point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the
neighbor TE node). However, it does say that it "identifies the other end 
of the link". Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.

Furthermore, earlier in RFC 3630 we read:
"
2.4.1. Router Address TLV

The Router Address TLV specifies a stable IP address of the
advertising router that is always reachable if there is any
connectivity to it; this is typically implemented as a "loopback
address". The key attribute is that the address does not become
unusable if an
interface is down. In other protocols, this is known
as the "router ID"

I interpret that this is the same router ID as in the upper quote. It is 
advertised in the Router Address TLV, which is the only way today to 
advertise TE Router ID. Hence the router ID in the context of this RFC is 
the TE Router ID.

The conclusion #1: the TE Link TLV, as it is today, always contains the ID 

of the remote TE node. 

The conclusion #2: there is a need to advertise several TE Router IDs 
supported by the same RC (advertising router), which, I think, should be 
proposed in your draft

ps: second question is trivial, mathematical vs networking formulation (no 

real difference)

IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080 

Igor

pps: if you want to put guidelines on e-mail responses probably directing 
your e-mail to the GEN AREA would be more suitable 

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the 
difference? If yes, why do you need the latter? Both your pointers explain 

why do you need advertising of the local TE Router ID (advertising router 
may cover multiple data plane nodes), However, LinkID unambiguosly 
identifies remote data plane node, and the need for the advertising of 
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding 
to the comments/questions by just pointing to RFCs or drafts. In my view 
it is quite unfriendly. It is always possible to cut and paste a piece 
from the relevant RFC or draft confirming the points the writer is trying 
to make.

[email-masked] wrote:
igor

pls use version (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
(i.e. Router ID of the neighbor for point-to-point links) MUST 
appear exactly once per Link TLV. This sub-TLV MUST be processed as 
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 17 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Local TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Remote TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬ÃƒÂ¢"Ã‚Â¢t understand why the Remote Te 
Router ID? 
IsnÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬ÃƒÂ¢"Ã‚Â¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€¦"A RA may contain smaller RAs inter-connected by 
links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€šÃ‚Â

In G.8080 I read:
ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€¦".... A routing area is defined by a set of 
subnetworks, the 
SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one 
subnetwork.ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€šÃ‚Â

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Get your own web address.
Have a HUGE year through Yahoo! Small Business.

8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.

 Don't get soaked. Take a quick peek at the forecast 
with theYahoo! Search weather shortcut.

---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
--0-611198405-1173561983=:91906
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,<br><br>I probably do not make myself clear, but you don't seem to see what I am saying. Let's continue the discussion in Prague. Hoefully, we will also hear what the authors of RFC3630 have to say.<br><br>See you soon,<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;"> igor <br><br>the first sentence is the disconnect, per 3630 <br><br>"The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear <br>exactly once."<br><br>" The Link ID sub-TLV identifies the other end of the link.  For<br>  point-to-point links, this is the Router ID of the neighbor."<br><br><br>you wrote<br><br>"TE links must be uniqely identifed either as numbered or unnumbered <br>(combination of TERtrID and LinkID)."<br><br>this is totally incorrect, there is a local/remote sub-TLV defined for <br>numbered TE links<br><br>in fact what the present
 document does is to define a sub-TLV to allow <br>identification of unnumbered TE links (associated to the TE router ID <br>rather than the Router ID)<br><br><br>thanks,<br>-d.<br><br><br> <br><br><br><br><br>Igor Bryskin <[email-masked]><br>10/03/2007 14:10<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked], "Brungard, Deborah A, ALABS" <br><[email-masked]>, "Ong, Lyndon" <[email-masked]>, <br>[email-masked]<br>        Subject:        RE: Two questions on <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Dimitri,<br><br>But who said that linkID must be unique per routerID? Of course, not. It <br>must be unique per TE Router ID. The fact that the same RC manages several <br>TE RTRs does not change a thing. The paths are computed on the network TE <br>graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE <br>links must be uniqely identifed either as numbered or unnumbered
 <br>(combination of TERtrID and LinkID). How the links are advertised - by <br>separate RCs, the same RC or via no RC (statically configured) - is of no <br>importance.<br><br>Igor<br><br>[email-masked] wrote:<br>igor<br><br>not an issue of TE router ID uniqueness, without this additional sub-TLV, <br>an unnumbered local id may not be unique per router_id, hence the addition <br><br>of this sub-TLV (TE Router ID being unique per router_id) <br><br>-d<br><br><br><br><br><br>Igor Bryskin <br>09/03/2007 22:36<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br>, "Ong, Lyndon" , <br>[email-masked]<br>Subject: RE: Two questions on <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Dimitri,<br><br>I don't see how we can manage the situation where TENodeIds are not <br>unique. At the end of the day we must process EROs/RROs that are build<br>of TENodeID/TELinkID pairs. If TELinkID
 has node-scope and TENodeID is not <br><br>unique, how then we can identify the specified link? So what do you <br>suggest we put in each of these two fields?<br><br>[email-masked] wrote:<br>igor <br><br>but it doesn't solve the issue (and introduces different setting and <br>processing of the link id value from rfc 3630) indeed, in ASON RC can be <br>associated to multiple "nodes", each of these nodes can have overlapping <br>id spaces (to identify the "links") <br><br>for that reason the solution is that each TE link (top level) TLV has a <br>new sub-TLV that associates the local and remote "node id" (the former and <br><br><br>latter takes the TE Router ID as value)<br><br>it is the substance of what i have been pointing to you in my initial <br>e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing <br>protocol MUST be able to disambiguate the advertised TE links so that they <br><br><br>can be associated with the correct TE
 Router ID.")<br><br>-d.<br><br><br><br><br><br><br><br>Igor Bryskin <br>Sent by: [email-masked]<br>09/03/2007 20:29<br><br>To: "Ong, Lyndon" , Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br>, [email-masked]<br>Subject: RE: Two questions on <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Lyndon,<br><br>Let me try to explain my point. <br><br>Basically, we have two solutions to address the situation when the <br>relationship between a router controller and data plane switches (TE nodes <br><br><br>or TE routers) are 1:N, that is, when a single controller manages multiple <br><br><br>TE routers.<br><br>Solution 1 (suggested in the draft):<br><br>Each TE Link advertising is extended with Local/Remote TE Router IDs pair. <br><br><br>In this case, what is in the LinkID sub-TLV is not important really.<br><br>Solution 2 (mine)<br><br>The Router Address TLV is extended to advertise all TE Router
 IDs <br>controlled by the advertising controller as routable addresses. The TE <br>Link TLV is extended to advertise the local TE Router ID. However, there <br>is no need to advertise the remote TE Router ID, because this is the <br>function of the existing LinkID sub-TLV, which is to identify the remote <br>end of the advertised TE link Ã¢â‚¬â€œ remote TE Router ID.<br><br>Both these approaches solve the problem; however, an important question to <br><br><br>answer is:<br><br>Do we need the TE Router IDs to be routable addresses?<br><br>The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. <br>For example, if the network<br>is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will <br>contain<br>path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable <br>solves the problem how to signal the Path message along the provisioned <br>path..<br>If you agree with this, than you will also agree that all TE Router IDs
 <br>should be advertised within Router Address TLV<br>Hope that this helps.<br><br>Igor<br><br><br><br><br>"Ong, Lyndon" wrote:<br>Hi Dimitri,<br><br>That was my understanding also, I don't see any issue with this.<br><br>Cheers,<br><br>Lyndon <br><br>-----Original Message-----<br>From: [email-masked] [mailto:[email-masked]] On Behalf <br><br><br>Of [email-masked]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [email-masked]; Brungard, Deborah A, ALABS; <br>[email-masked]<br>Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf <br><br>igor<br><br>the drafts says<br><br>"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. <br><br><br><br>Router ID of the neighbor for point-to-point links) MUST appear exactly <br>once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. <br><br><br><br>" <br><br>which is exactly what you are saying - when i say
 "it identifies the <br>remote RC not the remote data plane "node" in case the remote RC is <br>associate to n nodes" read "it is set to the router_id that identifies the <br><br><br>remote RC..."<br>in brief, we keep the semantic and add a discriminator (that does not <br>apply in case of colocated 1:1 LSR) - this closes the first point -<br><br>concerning the second point, since there is a possibility to have multiple <br><br><br>associations in different LSAs i don't where the problem is ?<br><br>thanks,<br>-d.<br><br><br><br><br><br>Igor Bryskin <br>Sent by: [email-masked]<br>09/03/2007 16:05<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br><br>&gt; Is the LinkID is the same as Remote TE Router ID? <br><br>no<br><br>&gt; LinkID unambiguosly identifies remote data plane node,<br><br>no, it
 identifies the remote RC not the remote data plane "node" in case <br>the remote RC is associate to n "nodes"<br><br>IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the<br>RFCs/drafts, because people often interpret them differently.<br><br>In RFC 3630 we read:<br>"<br>2.5.2. Link ID<br><br><br><br>The Link ID sub-TLV identifies the other end of the link. For<br><br>point-to-point links, this is the Router ID of the neighbor.<br><br>"<br><br>Note that it does not say whether this is the advertising Router ID <br><br>(identifying neighbor RC) or TE Router ID (identifying the<br>neighbor TE node). However, it does say that it "identifies the other end <br>of the link". Because a link is terminated by TE nodes (and not <br>advertising routers) I conclude that LinkID identifies the remote TE node.<br><br>Furthermore, earlier in RFC 3630 we read:<br>"<br>2.4.1. Router Address TLV<br><br>The Router Address TLV specifies a stable IP address of
 the<br>advertising router that is always reachable if there is any<br>connectivity to it; this is typically implemented as a "loopback<br>address". The key attribute is that the address does not become<br>unusable if an<br>interface is down. In other protocols, this is known<br>as the "router ID"<br><br>I interpret that this is the same router ID as in the upper quote. It is <br>advertised in the Router Address TLV, which is the only way today to <br>advertise TE Router ID. Hence the router ID in the context of this RFC is <br>the TE Router ID.<br><br>The conclusion #1: the TE Link TLV, as it is today, always contains the ID <br><br><br><br>of the remote TE node. <br><br>The conclusion #2: there is a need to advertise several TE Router IDs <br>supported by the same RC (advertising router), which, I think, should be <br>proposed in your draft<br><br>ps: second question is trivial, mathematical vs networking formulation (no <br><br><br><br><br>real
 difference)<br><br>IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br>am asking why is that in the draft which is supposed to define ways to <br>support G.8080 <br><br>Igor<br><br>pps: if you want to put guidelines on e-mail responses probably directing <br>your e-mail to the GEN AREA would be more suitable <br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>09/03/2007 00:03<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri, no, it does not help.<br><br>You didn't answer the first question, which is:<br><br>Is the LinkID is the same as Remote TE Router ID? If no, what is the <br>difference? If yes, why do you need the latter? Both your pointers explain <br><br><br><br><br>why do you need advertising of the local TE Router ID (advertising router <br>may cover
 multiple data plane nodes), However, LinkID unambiguosly <br>identifies remote data plane node, and the need for the advertising of <br>Remote TE Router ID is not obvious<br><br>BTW, You didn't answer the second question either.<br><br>Igor<br><br>PS, I have a suggestion for the working group: Let us disallow responding <br>to the comments/questions by just pointing to RFCs or drafts. In my view <br>it is quite unfriendly. It is always possible to cut and paste a piece <br>from the relevant RFC or draft confirming the points the writer is trying <br>to make.<br><br>[email-masked] wrote:<br>igor<br><br><br>pls use version (or 03 <br>when available to make comments)<br><br>in that version you will see in Section 5.2<br><br>" Note: The Link ID sub-TLV that identifies the other end of the link <br>(i.e. Router ID of the neighbor for point-to-point links) MUST <br>appear exactly once per Link TLV. This sub-TLV MUST be processed as <br>defined in
 [RFC3630]. "<br><br>now why this sub-TLV 17, well for the reason explained at the beginning of <br><br><br><br><br><br>par.5.2<br>but also in RFC 4652 Section 5.7<br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>08/03/2007 22:11<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br>I have a couple questions wrt the <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br>local and remote TE Router ID:<br><br>0 1 2 3 <br>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| 17 | Length | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Local TE Router Identifier |
 <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Remote TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br><br>Although I do understand why there is a need for advertising the Local TE <br>Router ID, I donÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬ÃƒÂ¢"Ã‚Â¢t understand why the Remote Te <br>Router ID? <br>IsnÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬ÃƒÂ¢"Ã‚Â¢t <br>this is <br>the same<br>information <br>that is carried in the Link ID sub-TLV?<br>In 6. you write:<br><br>ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€¦"A RA may contain smaller RAs inter-connected by <br>links. <br>The limit of the subdivision results in<br>a RA that contains two sub-networks interconnected by a single <br>link.ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€šÃ‚Â<br><br>In G.8080 I read:<br>ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€¦".... A routing area is defined by a set of <br>subnetworks, the <br>SNPP
 <br>links <br><br>that interconnect them, and the SNPPs representing the ends of the SNPP <br>links exiting that routing area. A routing area may contain smaller <br>routing areas interconnected by SNPP links. The limit of subdivision <br>results in a routing area that contains ]one <br>subnetwork.ÃƒÆ’Ã‚Â¢ÃƒÂ¢'Ã‚Â¬Ãƒâ€šÃ‚Â<br><br>Why is the discrepancy?<br><br>Thanks,<br>Igor<br><br><br>[<br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br>Now that's room service! Choose from over 150,000 hotels <br>in 45,000 destinations on Yahoo! Travel to find your fit.<br><br><br><br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br><br>Get your own web address.<br>Have a HUGE year through Yahoo! Small Business.<br><br><br>8:00? 8:25? 8:40? Find a flick in no time<br>with theYahoo! Search movie showtime shortcut.<br><br><br> Don't get soaked. Take a quick peek at the
 forecast <br>with theYahoo! Search weather shortcut.<br><br></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>TV dinner still cooling?<br><a href="http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/">Check out "Tonight's Picks"</a> on Yahoo! TV.
--0-611198405-1173561983=:91906--

Delivery-date: Sat, 10 Mar 2007 13:44:44 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
From: [email-masked]
Date: Sat, 10 Mar 2007 14:44:01 +0100

Delivery-date: Sat, 10 Mar 2007 13:13:09 +0000
Date: Sat, 10 Mar 2007 05:10:45 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]

--0-914139335-1173532245=:30300
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,

But who said that linkID must be unique per routerID? Of course, not. It must be unique per TE Router ID. The fact that the same RC manages several TE RTRs does not change a thing. The paths are computed on the network TE graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE links must be uniqely identifed either as numbered or unnumbered (combination of TERtrID and LinkID). How the links are advertised - by separate RCs, the same RC or via no RC (statically configured) - is of no importance.

Igor

[email-masked] wrote: igor

not an issue of TE router ID uniqueness, without this additional sub-TLV, 
an unnumbered local id may not be unique per router_id, hence the addition 
of this sub-TLV (TE Router ID being unique per router_id) 

-d

Igor Bryskin 
09/03/2007 22:36
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[email-masked]
        Subject:        RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Dimitri,

I don't see how we can manage the situation where TENodeIds are not 
unique. At the end of the day we must process EROs/RROs that are build
of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not 
unique, how then we can identify the specified link? So what do you 
suggest we put in each of these two fields?

[email-masked] wrote:
igor 

but it doesn't solve the issue (and introduces different setting and 
processing of the link id value from rfc 3630) indeed, in ASON RC can be 
associated to multiple "nodes", each of these nodes can have overlapping 
id spaces (to identify the "links") 

for that reason the solution is that each TE link (top level) TLV has a 
new sub-TLV that associates the local and remote "node id" (the former and 

latter takes the TE Router ID as value)

it is the substance of what i have been pointing to you in my initial 
e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing 
protocol MUST be able to disambiguate the advertised TE links so that they 

can be associated with the correct TE Router ID.")

-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 20:29

To: "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 
, [email-masked]
Subject: RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Lyndon,

Let me try to explain my point. 

Basically, we have two solutions to address the situation when the 
relationship between a router controller and data plane switches (TE nodes 

or TE routers) are 1:N, that is, when a single controller manages multiple 

TE routers.

Solution 1 (suggested in the draft):

Each TE Link advertising is extended with Local/Remote TE Router IDs pair. 

In this case, what is in the LinkID sub-TLV is not important really.

Solution 2 (mine)

The Router Address TLV is extended to advertise all TE Router IDs 
controlled by the advertising controller as routable addresses. The TE 
Link TLV is extended to advertise the local TE Router ID. However, there 
is no need to advertise the remote TE Router ID, because this is the 
function of the existing LinkID sub-TLV, which is to identify the remote 
end of the advertised TE link â€“ remote TE Router ID.

Both these approaches solve the problem; however, an important question to 

answer is:

Do we need the TE Router IDs to be routable addresses?

The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. 
For example, if the network
is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will 
contain
path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable 
solves the problem how to signal the Path message along the provisioned 
path..
If you agree with this, than you will also agree that all TE Router IDs 
should be advertised within Router Address TLV
Hope that this helps.

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

That was my understanding also, I don't see any issue with this.

Cheers,

Lyndon 

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

Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; 
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 

Router ID of the neighbor for point-to-point links) MUST appear exactly 
once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 

" 

which is exactly what you are saying - when i say "it identifies the 
remote RC not the remote data plane "node" in case the remote RC is 
associate to n nodes" read "it is set to the router_id that identifies the 

remote RC..."
in brief, we keep the semantic and add a discriminator (that does not 
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple 

associations in different LSAs i don't where the problem is ?

thanks,
-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID? 

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case 
the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2. Link ID

The Link ID sub-TLV identifies the other end of the link. For

point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the
neighbor TE node). However, it does say that it "identifies the other end 
of the link". Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.

Furthermore, earlier in RFC 3630 we read:
"
2.4.1. Router Address TLV

The Router Address TLV specifies a stable IP address of the
advertising router that is always reachable if there is any
connectivity to it; this is typically implemented as a "loopback
address". The key attribute is that the address does not become
unusable if an
interface is down. In other protocols, this is known
as the "router ID"

I interpret that this is the same router ID as in the upper quote. It is 
advertised in the Router Address TLV, which is the only way today to 
advertise TE Router ID. Hence the router ID in the context of this RFC is 
the TE Router ID.

The conclusion #1: the TE Link TLV, as it is today, always contains the ID 

of the remote TE node. 

The conclusion #2: there is a need to advertise several TE Router IDs 
supported by the same RC (advertising router), which, I think, should be 
proposed in your draft

ps: second question is trivial, mathematical vs networking formulation (no 

real difference)

IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080 

Igor

pps: if you want to put guidelines on e-mail responses probably directing 
your e-mail to the GEN AREA would be more suitable 

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the 
difference? If yes, why do you need the latter? Both your pointers explain 

why do you need advertising of the local TE Router ID (advertising router 
may cover multiple data plane nodes), However, LinkID unambiguosly 
identifies remote data plane node, and the need for the advertising of 
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding 
to the comments/questions by just pointing to RFCs or drafts. In my view 
it is quite unfriendly. It is always possible to cut and paste a piece 
from the relevant RFC or draft confirming the points the writer is trying 
to make.

[email-masked] wrote:
igor

pls use version (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
(i.e. Router ID of the neighbor for point-to-point links) MUST 
appear exactly once per Link TLV. This sub-TLV MUST be processed as 
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 17 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Local TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Remote TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t understand why the Remote Te Router ID? 
IsnÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

ÃƒÂ¢Ã¢'Â¬Ã…"A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.ÃƒÂ¢Ã¢'Â¬Ã‚Â

In G.8080 I read:
ÃƒÂ¢Ã¢'Â¬Ã…".... A routing area is defined by a set of subnetworks, the 
SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.ÃƒÂ¢Ã¢'Â¬Ã‚Â

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Get your own web address.
Have a HUGE year through Yahoo! Small Business.

 8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.

---------------------------------
Don't get soaked.  Take a quick peek at the forecast 
 with theYahoo! Search weather shortcut.
--0-914139335-1173532245=:30300
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,<br><br>But who said that linkID must be unique per routerID? Of course, not. It must be unique per TE Router ID. The fact that the same RC manages several TE RTRs does not change a thing. The paths are computed on the network TE graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE links must be uniqely identifed either as numbered or unnumbered (combination of TERtrID and LinkID). How the links are advertised - by separate RCs, the same RC or via no RC (statically configured) - is of no importance.<br><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;"> igor<br><br>not an issue of TE router ID uniqueness, without this additional sub-TLV, <br>an unnumbered local id may not be unique per router_id, hence the addition <br>of this sub-TLV (TE Router ID being unique per router_id)
 <br><br>-d<br><br><br><br><br><br>Igor Bryskin <[email-masked]><br>09/03/2007 22:36<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked], "Brungard, Deborah A, ALABS" <br><[email-masked]>, "Ong, Lyndon" <[email-masked]>, <br>[email-masked]<br>        Subject:        RE: Two questions on <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Dimitri,<br><br>I don't see how we can manage the situation where TENodeIds are not <br>unique. At the end of the day we must process EROs/RROs that are build<br>of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not <br>unique, how then we can identify the specified link? So what do you <br>suggest we put in each of these two fields?<br><br>[email-masked] wrote:<br>igor <br><br>but it doesn't solve the issue (and introduces different setting and <br>processing of the link id value from rfc 3630) indeed, in ASON RC can be
 <br>associated to multiple "nodes", each of these nodes can have overlapping <br>id spaces (to identify the "links") <br><br>for that reason the solution is that each TE link (top level) TLV has a <br>new sub-TLV that associates the local and remote "node id" (the former and <br><br>latter takes the TE Router ID as value)<br><br>it is the substance of what i have been pointing to you in my initial <br>e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing <br>protocol MUST be able to disambiguate the advertised TE links so that they <br><br>can be associated with the correct TE Router ID.")<br><br>-d.<br><br><br><br><br><br><br><br>Igor Bryskin <br>Sent by: [email-masked]<br>09/03/2007 20:29<br><br>To: "Ong, Lyndon" , Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br>, [email-masked]<br>Subject: RE: Two questions on
 <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Lyndon,<br><br>Let me try to explain my point. <br><br>Basically, we have two solutions to address the situation when the <br>relationship between a router controller and data plane switches (TE nodes <br><br>or TE routers) are 1:N, that is, when a single controller manages multiple <br><br>TE routers.<br><br>Solution 1 (suggested in the draft):<br><br>Each TE Link advertising is extended with Local/Remote TE Router IDs pair. <br><br>In this case, what is in the LinkID sub-TLV is not important really.<br><br>Solution 2 (mine)<br><br>The Router Address TLV is extended to advertise all TE Router IDs <br>controlled by the advertising controller as routable addresses. The TE <br>Link TLV is extended to advertise the local TE Router ID. However, there <br>is no need to advertise the remote TE Router ID, because this is the <br>function of the existing LinkID sub-TLV, which is to identify the remote <br>end of the
 advertised TE link â€“ remote TE Router ID.<br><br>Both these approaches solve the problem; however, an important question to <br><br>answer is:<br><br>Do we need the TE Router IDs to be routable addresses?<br><br>The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. <br>For example, if the network<br>is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will <br>contain<br>path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable <br>solves the problem how to signal the Path message along the provisioned <br>path..<br>If you agree with this, than you will also agree that all TE Router IDs <br>should be advertised within Router Address TLV<br>Hope that this helps.<br><br>Igor<br><br><br><br><br>"Ong, Lyndon" wrote:<br>Hi Dimitri,<br><br>That was my understanding also, I don't see any issue with this.<br><br>Cheers,<br><br>Lyndon <br><br>-----Original Message-----<br>From: [email-masked]
 [mailto:[email-masked]] On Behalf <br><br>Of [email-masked]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [email-masked]; Brungard, Deborah A, ALABS; <br>[email-masked]<br>Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf <br><br>igor<br><br>the drafts says<br><br>"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. <br><br><br>Router ID of the neighbor for point-to-point links) MUST appear exactly <br>once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. <br><br><br>" <br><br>which is exactly what you are saying - when i say "it identifies the <br>remote RC not the remote data plane "node" in case the remote RC is <br>associate to n nodes" read "it is set to the router_id that identifies the <br><br>remote RC..."<br>in brief, we keep the semantic and add a discriminator (that does not <br>apply in case of colocated 1:1 LSR) - this closes the
 first point -<br><br>concerning the second point, since there is a possibility to have multiple <br><br>associations in different LSAs i don't where the problem is ?<br><br>thanks,<br>-d.<br><br><br><br><br><br>Igor Bryskin <br>Sent by: [email-masked]<br>09/03/2007 16:05<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br><br>&gt; Is the LinkID is the same as Remote TE Router ID? <br><br>no<br><br>&gt; LinkID unambiguosly identifies remote data plane node,<br><br>no, it identifies the remote RC not the remote data plane "node" in case <br>the remote RC is associate to n "nodes"<br><br>IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the<br>RFCs/drafts, because people often interpret them differently.<br><br>In RFC 3630 we read:<br>"<br>2.5.2. Link ID<br><br><br><br>The
 Link ID sub-TLV identifies the other end of the link. For<br><br>point-to-point links, this is the Router ID of the neighbor.<br><br>"<br><br>Note that it does not say whether this is the advertising Router ID <br><br>(identifying neighbor RC) or TE Router ID (identifying the<br>neighbor TE node). However, it does say that it "identifies the other end <br>of the link". Because a link is terminated by TE nodes (and not <br>advertising routers) I conclude that LinkID identifies the remote TE node.<br><br>Furthermore, earlier in RFC 3630 we read:<br>"<br>2.4.1. Router Address TLV<br><br>The Router Address TLV specifies a stable IP address of the<br>advertising router that is always reachable if there is any<br>connectivity to it; this is typically implemented as a "loopback<br>address". The key attribute is that the address does not become<br>unusable if an<br>interface is down. In other protocols, this is known<br>as the "router ID"<br><br>I interpret that this is the same
 router ID as in the upper quote. It is <br>advertised in the Router Address TLV, which is the only way today to <br>advertise TE Router ID. Hence the router ID in the context of this RFC is <br>the TE Router ID.<br><br>The conclusion #1: the TE Link TLV, as it is today, always contains the ID <br><br><br>of the remote TE node. <br><br>The conclusion #2: there is a need to advertise several TE Router IDs <br>supported by the same RC (advertising router), which, I think, should be <br>proposed in your draft<br><br>ps: second question is trivial, mathematical vs networking formulation (no <br><br><br><br>real difference)<br><br>IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br>am asking why is that in the draft which is supposed to define ways to <br>support G.8080 <br><br>Igor<br><br>pps: if you want to put guidelines on e-mail responses probably directing <br>your e-mail to the GEN AREA would be more suitable <br><br>hope this
 helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>09/03/2007 00:03<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri, no, it does not help.<br><br>You didn't answer the first question, which is:<br><br>Is the LinkID is the same as Remote TE Router ID? If no, what is the <br>difference? If yes, why do you need the latter? Both your pointers explain <br><br><br><br>why do you need advertising of the local TE Router ID (advertising router <br>may cover multiple data plane nodes), However, LinkID unambiguosly <br>identifies remote data plane node, and the need for the advertising of <br>Remote TE Router ID is not obvious<br><br>BTW, You didn't answer the second question either.<br><br>Igor<br><br>PS, I have a suggestion for the working group: Let us disallow responding <br>to the comments/questions by just
 pointing to RFCs or drafts. In my view <br>it is quite unfriendly. It is always possible to cut and paste a piece <br>from the relevant RFC or draft confirming the points the writer is trying <br>to make.<br><br>[email-masked] wrote:<br>igor<br><br><br>pls use version (or 03 <br>when available to make comments)<br><br>in that version you will see in Section 5.2<br><br>" Note: The Link ID sub-TLV that identifies the other end of the link <br>(i.e. Router ID of the neighbor for point-to-point links) MUST <br>appear exactly once per Link TLV. This sub-TLV MUST be processed as <br>defined in [RFC3630]. "<br><br>now why this sub-TLV 17, well for the reason explained at the beginning of <br><br><br><br><br>par.5.2<br>but also in RFC 4652 Section 5.7<br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>08/03/2007 22:11<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject:
 Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br>I have a couple questions wrt the <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br>local and remote TE Router ID:<br><br>0 1 2 3 <br>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| 17 | Length | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Local TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Remote TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br><br>Although I do understand why there is a need for advertising the Local TE <br>Router ID, I donÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t understand why the Remote Te Router ID? <br>IsnÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t <br>this is <br>the
 same<br>information <br>that is carried in the Link ID sub-TLV?<br>In 6. you write:<br><br>ÃƒÂ¢Ã¢'Â¬Ã…"A RA may contain smaller RAs inter-connected by links. <br>The limit of the subdivision results in<br>a RA that contains two sub-networks interconnected by a single <br>link.ÃƒÂ¢Ã¢'Â¬Ã‚Â<br><br>In G.8080 I read:<br>ÃƒÂ¢Ã¢'Â¬Ã…".... A routing area is defined by a set of subnetworks, the <br>SNPP <br>links <br><br>that interconnect them, and the SNPPs representing the ends of the SNPP <br>links exiting that routing area. A routing area may contain smaller <br>routing areas interconnected by SNPP links. The limit of subdivision <br>results in a routing area that contains ]one subnetwork.ÃƒÂ¢Ã¢'Â¬Ã‚Â<br><br>Why is the discrepancy?<br><br>Thanks,<br>Igor<br><br><br>[<br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br>Now that's room service! Choose from over 150,000 hotels <br>in
 45,000 destinations on Yahoo! Travel to find your fit.<br><br><br><br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br><br>Get your own web address.<br>Have a HUGE year through Yahoo! Small Business.<br><br><br> 8:00? 8:25? 8:40? Find a flick in no time<br>with theYahoo! Search movie showtime shortcut.<br><br></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>
Don't get soaked.  Take a<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> quick peek at the forecast </a><br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search weather shortcut.</a>
--0-914139335-1173532245=:30300--

Delivery-date: Sat, 10 Mar 2007 02:12:07 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
From: [email-masked]
Date: Sat, 10 Mar 2007 03:08:44 +0100

Delivery-date: Fri, 09 Mar 2007 21:37:50 +0000
Date: Fri, 9 Mar 2007 13:36:27 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]

--0-1698436596-1173476187=:26675
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,

I don't see how we can manage the situation where TENodeIds are not unique. At the end of the day we must process EROs/RROs that are build
of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not unique, how then we can identify the specified link? So what do you suggest we put in each of these two fields?

[email-masked] wrote: igor 

but it doesn't solve the issue (and introduces different setting and 
processing of the link id value from rfc 3630) indeed, in ASON RC can be 
associated to multiple "nodes", each of these nodes can have overlapping 
id spaces (to identify the "links") 

for that reason the solution is that each TE link (top level) TLV has a 
new sub-TLV that associates the local and remote "node id" (the former and 
latter takes the TE Router ID as value)

it is the substance of what i have been pointing to you in my initial 
e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing 
protocol MUST be able to disambiguate the advertised TE links so that they 
can be associated with the correct TE Router ID.")

-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 20:29
 
        To:     "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
, [email-masked]
        Subject:        RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Lyndon,
 
Let me try to explain my point. 
 
Basically, we have two solutions to address the situation when the 
relationship between a router controller and data plane switches (TE nodes 
or TE routers) are 1:N, that is, when a single controller manages multiple 
TE routers.
 
Solution 1 (suggested in the draft):
 
Each TE Link advertising is extended with Local/Remote TE Router IDs pair. 
In this case, what is in the LinkID sub-TLV is not important really.
 
Solution 2 (mine)
 
The Router Address TLV is extended to advertise all TE Router IDs 
controlled by the advertising controller as routable addresses. The TE 
Link TLV is extended to advertise the local TE Router ID. However, there 
is no need to advertise the remote TE Router ID, because this is the 
function of the existing LinkID sub-TLV, which is to identify the remote 
end of the advertised TE link – remote TE Router ID.
 
Both these approaches solve the problem; however, an important question to 
answer is:
 
Do we need the TE Router IDs to be routable addresses?
 
The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. 
For example, if the network
 is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will 
contain
 path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable 
solves the problem how to signal the Path message along the provisioned 
path..
If you agree with this, than you will also agree that all TE Router IDs 
should be advertised within Router Address TLV
Hope that this helps.
 
Igor

"Ong, Lyndon"  wrote:
Hi Dimitri,

That was my understanding also, I don't see any issue with this.

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; 
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 

Router ID of the neighbor for point-to-point links) MUST appear exactly 
once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 

" 

which is exactly what you are saying - when i say "it identifies the 
remote RC not the remote data plane "node" in case the remote RC is 
associate to n nodes" read "it is set to the router_id that identifies the 
remote RC..."
in brief, we keep the semantic and add a discriminator (that does not 
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple 
associations in different LSAs i don't where the problem is ?

thanks,
-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID? 

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case 
the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2. Link ID

The Link ID sub-TLV identifies the other end of the link. For

point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the
neighbor TE node). However, it does say that it "identifies the other end 
of the link". Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.

Furthermore, earlier in RFC 3630 we read:
"
2.4.1. Router Address TLV

The Router Address TLV specifies a stable IP address of the
advertising router that is always reachable if there is any
connectivity to it; this is typically implemented as a "loopback
address". The key attribute is that the address does not become
unusable if an
interface is down. In other protocols, this is known
as the "router ID"

I interpret that this is the same router ID as in the upper quote. It is 
advertised in the Router Address TLV, which is the only way today to 
advertise TE Router ID. Hence the router ID in the context of this RFC is 
the TE Router ID.

The conclusion #1: the TE Link TLV, as it is today, always contains the ID 

of the remote TE node. 

The conclusion #2: there is a need to advertise several TE Router IDs 
supported by the same RC (advertising router), which, I think, should be 
proposed in your draft

ps: second question is trivial, mathematical vs networking formulation (no 

real difference)

IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080 

Igor

pps: if you want to put guidelines on e-mail responses probably directing 
your e-mail to the GEN AREA would be more suitable 

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the 
difference? If yes, why do you need the latter? Both your pointers explain 

why do you need advertising of the local TE Router ID (advertising router 
may cover multiple data plane nodes), However, LinkID unambiguosly 
identifies remote data plane node, and the need for the advertising of 
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding 
to the comments/questions by just pointing to RFCs or drafts. In my view 
it is quite unfriendly. It is always possible to cut and paste a piece 
from the relevant RFC or draft confirming the points the writer is trying 
to make.

[email-masked] wrote:
igor

pls use version (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
(i.e. Router ID of the neighbor for point-to-point links) MUST 
appear exactly once per Link TLV. This sub-TLV MUST be processed as 
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 17 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Local TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Remote TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃ¢â'¬â"¢t understand why the Remote Te Router ID? 
IsnÃ¢â'¬â"¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

Ã¢â'¬Å"A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.Ã¢â'¬Â

In G.8080 I read:
Ã¢â'¬Å".... A routing area is defined by a set of subnetworks, the SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.Ã¢â'¬Â

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

 Get your own web address.
Have a HUGE year through Yahoo! Small Business.

---------------------------------
8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.
--0-1698436596-1173476187=:26675
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,<br><br>I don't see how we can manage the situation where TENodeIds are not unique. At the end of the day we must process EROs/RROs that are build<br>of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not unique, how then we can identify the specified link? So what do you suggest we put in each of these two fields?<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;"> igor <br><br>but it doesn't solve the issue (and introduces different setting and <br>processing of the link id value from rfc 3630) indeed, in ASON RC can be <br>associated to multiple "nodes", each of these nodes can have overlapping <br>id spaces (to identify the "links") <br><br>for that reason the solution is that each TE link (top level) TLV has a <br>new sub-TLV that associates the local and remote "node id" (the former and <br>latter takes the TE
 Router ID as value)<br><br>it is the substance of what i have been pointing to you in my initial <br>e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing <br>protocol MUST be able to disambiguate the advertised TE links so that they <br>can be associated with the correct TE Router ID.")<br><br>-d.<br><br><br><br><br><br><br><br>Igor Bryskin <[email-masked]><br>Sent by: [email-masked]<br>09/03/2007 20:29<br> <br>        To:     "Ong, Lyndon" <[email-masked]>, Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked], "Brungard, Deborah A, ALABS" <br><[email-masked]>, [email-masked]<br>        Subject:        RE: Two questions on <br>draft-ietf-ccamp-gmpls-ason-routing-ospf<br><br><br>Lyndon,<br> <br>Let me try to explain my point. <br> <br>Basically, we have two solutions to address the situation when the <br>relationship between a router controller and data plane switches (TE nodes <br>or TE routers)
 are 1:N, that is, when a single controller manages multiple <br>TE routers.<br> <br>Solution 1 (suggested in the draft):<br> <br>Each TE Link advertising is extended with Local/Remote TE Router IDs pair. <br>In this case, what is in the LinkID sub-TLV is not important really.<br> <br>Solution 2 (mine)<br> <br>The Router Address TLV is extended to advertise all TE Router IDs <br>controlled by the advertising controller as routable addresses. The TE <br>Link TLV is extended to advertise the local TE Router ID. However, there <br>is no need to advertise the remote TE Router ID, because this is the <br>function of the existing LinkID sub-TLV, which is to identify the remote <br>end of the advertised TE link – remote TE Router ID.<br> <br>Both these approaches solve the problem; however, an important question to <br>answer is:<br> <br>Do we need the TE Router IDs to be routable addresses?<br> <br>The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. <br>For
 example, if the network<br> is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will <br>contain<br> path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable <br>solves the problem how to signal the Path message along the provisioned <br>path..<br>If you agree with this, than you will also agree that all TE Router IDs <br>should be advertised within Router Address TLV<br>Hope that this helps.<br> <br>Igor<br> <br> <br><br><br>"Ong, Lyndon" <[email-masked]> wrote:<br>Hi Dimitri,<br><br>That was my understanding also, I don't see any issue with this.<br><br>Cheers,<br><br>Lyndon <br><br>-----Original Message-----<br>From: [email-masked] [mailto:[email-masked]] On Behalf <br>Of [email-masked]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [email-masked]; Brungard, Deborah A, ALABS; <br>[email-masked]<br>Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
 <br><br>igor<br><br>the drafts says<br><br>"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. <br><br>Router ID of the neighbor for point-to-point links) MUST appear exactly <br>once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. <br><br>" <br><br>which is exactly what you are saying - when i say "it identifies the <br>remote RC not the remote data plane "node" in case the remote RC is <br>associate to n nodes" read "it is set to the router_id that identifies the <br>remote RC..."<br>in brief, we keep the semantic and add a discriminator (that does not <br>apply in case of colocated 1:1 LSR) - this closes the first point -<br><br>concerning the second point, since there is a possibility to have multiple <br>associations in different LSAs i don't where the problem is ?<br><br>thanks,<br>-d.<br><br><br><br><br><br>Igor Bryskin <br>Sent by: [email-masked]<br>09/03/2007 16:05<br><br>To: Dimitri
 PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br><br>&gt; Is the LinkID is the same as Remote TE Router ID? <br><br>no<br><br>&gt; LinkID unambiguosly identifies remote data plane node,<br><br>no, it identifies the remote RC not the remote data plane "node" in case <br>the remote RC is associate to n "nodes"<br><br>IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the<br>RFCs/drafts, because people often interpret them differently.<br><br>In RFC 3630 we read:<br>"<br>2.5.2. Link ID<br><br><br><br>The Link ID sub-TLV identifies the other end of the link. For<br><br>point-to-point links, this is the Router ID of the neighbor.<br><br>"<br><br>Note that it does not say whether this is the advertising Router ID <br><br>(identifying neighbor RC) or TE Router ID (identifying the<br>neighbor TE node).
 However, it does say that it "identifies the other end <br>of the link". Because a link is terminated by TE nodes (and not <br>advertising routers) I conclude that LinkID identifies the remote TE node.<br><br>Furthermore, earlier in RFC 3630 we read:<br>"<br>2.4.1. Router Address TLV<br><br>The Router Address TLV specifies a stable IP address of the<br>advertising router that is always reachable if there is any<br>connectivity to it; this is typically implemented as a "loopback<br>address". The key attribute is that the address does not become<br>unusable if an<br>interface is down. In other protocols, this is known<br>as the "router ID"<br><br>I interpret that this is the same router ID as in the upper quote. It is <br>advertised in the Router Address TLV, which is the only way today to <br>advertise TE Router ID. Hence the router ID in the context of this RFC is <br>the TE Router ID.<br><br>The conclusion #1: the TE Link TLV, as it is today, always contains the ID
 <br><br>of the remote TE node. <br><br>The conclusion #2: there is a need to advertise several TE Router IDs <br>supported by the same RC (advertising router), which, I think, should be <br>proposed in your draft<br><br>ps: second question is trivial, mathematical vs networking formulation (no <br><br><br>real difference)<br><br>IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br>am asking why is that in the draft which is supposed to define ways to <br>support G.8080 <br><br>Igor<br><br>pps: if you want to put guidelines on e-mail responses probably directing <br>your e-mail to the GEN AREA would be more suitable <br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>09/03/2007 00:03<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri, no, it does not
 help.<br><br>You didn't answer the first question, which is:<br><br>Is the LinkID is the same as Remote TE Router ID? If no, what is the <br>difference? If yes, why do you need the latter? Both your pointers explain <br><br><br>why do you need advertising of the local TE Router ID (advertising router <br>may cover multiple data plane nodes), However, LinkID unambiguosly <br>identifies remote data plane node, and the need for the advertising of <br>Remote TE Router ID is not obvious<br><br>BTW, You didn't answer the second question either.<br><br>Igor<br><br>PS, I have a suggestion for the working group: Let us disallow responding <br>to the comments/questions by just pointing to RFCs or drafts. In my view <br>it is quite unfriendly. It is always possible to cut and paste a piece <br>from the relevant RFC or draft confirming the points the writer is trying <br>to make.<br><br>[email-masked] wrote:<br>igor<br><br><br>pls use version (or 03 <br>when
 available to make comments)<br><br>in that version you will see in Section 5.2<br><br>" Note: The Link ID sub-TLV that identifies the other end of the link <br>(i.e. Router ID of the neighbor for point-to-point links) MUST <br>appear exactly once per Link TLV. This sub-TLV MUST be processed as <br>defined in [RFC3630]. "<br><br>now why this sub-TLV 17, well for the reason explained at the beginning of <br><br><br><br>par.5.2<br>but also in RFC 4652 Section 5.7<br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>08/03/2007 22:11<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br>I have a couple questions wrt the <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br>local and remote TE Router ID:<br><br>0 1 2 3 <br>0 1
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| 17 | Length | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Local TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Remote TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br><br>Although I do understand why there is a need for advertising the Local TE <br>Router ID, I donÃ¢â'¬â"¢t understand why the Remote Te Router ID? <br>IsnÃ¢â'¬â"¢t <br>this is <br>the same<br>information <br>that is carried in the Link ID sub-TLV?<br>In 6. you write:<br><br>Ã¢â'¬Å"A RA may contain smaller RAs inter-connected by links. <br>The limit of the subdivision results in<br>a RA that contains two sub-networks interconnected by a single <br>link.Ã¢â'¬Â<br><br>In G.8080 I read:<br>Ã¢â'¬Å".... A routing area is
 defined by a set of subnetworks, the SNPP <br>links <br><br>that interconnect them, and the SNPPs representing the ends of the SNPP <br>links exiting that routing area. A routing area may contain smaller <br>routing areas interconnected by SNPP links. The limit of subdivision <br>results in a routing area that contains ]one subnetwork.Ã¢â'¬Â<br><br>Why is the discrepancy?<br><br>Thanks,<br>Igor<br><br><br>[<br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br>Now that's room service! Choose from over 150,000 hotels <br>in 45,000 destinations on Yahoo! Travel to find your fit.<br><br><br><br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br> <br> Get your own web address.<br>Have a HUGE year through Yahoo! Small Business.<br><br></[email-masked]></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>8:00? 8:25? 8:40? <a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> Find a flick</a> in no time<br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search movie showtime shortcut.</a>
--0-1698436596-1173476187=:26675--

Delivery-date: Fri, 09 Mar 2007 20:59:44 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
From: [email-masked]
Date: Fri, 9 Mar 2007 21:58:55 +0100

Delivery-date: Fri, 09 Mar 2007 20:48:16 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, [email-masked]
Subject: RE: New communication from the OIF
From: [email-masked]
Date: Fri, 9 Mar 2007 21:46:24 +0100

lyndon

a C-Type 3 label can help here with a VLAN bundle ID 

note that in this case, you will have the possibility to optionally list 
(set of) intervals

hope this will help you,
-d. 

"Ong, Lyndon" <[email-masked]>
09/03/2007 19:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, 
"MEURIC Julien RD-CORE-LAN" <[email-masked]>, 
<[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Dimitri,

I understand what you are saying, however it is still not clear what
the solution should be:

a) it is not clear as you say what "label" value you would use for the
EVC

b) there still needs to be some method of enumerating the VIDs carried
by 
the EVC (for this type of EVC).  If the signaling does not enumerate the
VIDs, 
then some other mechanism is necessary, to create what I think you refer
to as 
a "bundle index".

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 4:27 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
MEURIC Julien RD-CORE-LAN; [email-masked]
Subject: RE: New communication from the OIF

lyndon

o) first you will observe that the doc. MEF traffic parameters does not
speak about "label distribution" 

reason: you will observe (by section 3.4 of RFC 3209) that label per
sender (shared reservation or not) and label per link reservation
(de-facto shared) are possible

hence the usage of RSVP-TE traffic parameters result also in using these
rules (i will add a statement to make this clearer in the next release)
but remember the doc does not define any "label" format for MEF purposes

o) second you will observe that the document does not infer any "VID" to
EVC relationship, noticing that single CoS and multiple CoS per EVC are
covered in the draft, and this, independently of the number of VIDs per
EVC 

o) third closing the loop, the draft is not inferring any "label" to
"VID" 
relationship (that relationship when equating an EVC with single or
multiple CoS to an RSVP session is straightforward) 

the questions are thus the following

1. to which entity the traffic parameters are applied in case of a
single EVC with multiple VIDs ? if you are following the reasoning since
so far it should be per EVC (for the set of VIDs) 

note: per EVC+VID taken individually requires separate signaling
otherwise you need a list of tspecs and a list of label + correspondance
and this is another protocol, in fact boiling down to a simple
relationship 

2. what is the "label" value(s) in this case ? using the set of VIDs to
represent a "reservation" at the control plane level is completely
useless as the control plane doesn't need this info to create PSB/RSB
and the entity to which the reservation is associated is the "EVC" ...
so you will need to find a unique per-EVC characteristic when the 1:1
relationship between label and EVC is limitative e.g. a bundle index or
so (something that boils you down to a 1:1 relationship because
indepedently of the "protocol" being explicit in the enumeration IS
cumbersome)

 thanks,
-d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, 
"Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which 
causes a problem if you are 
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case 
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to 
understand how this would work - any solutions coming out of CCAMP would
be
very welcome. 

- not sure if there is an issue on point-to-multipoint, we were just
trying to 
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows based on the associated Ethernet labels, each with
some associated bandwidth.  The receiving node creates a corresponding
tunnel and aggregates these flows into the tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking with our MEF 'experts' on this), the originator requests
an EVC service, which has an associated bandwidth from one edge of the
network to another, and can support within it several Ethernet flows
that share this bandwidth.  If there are multiple EVCs, the originator
uses signaling to identify which labels should be carried in EVCx and
which should be carried in EVCy - if EVCx carries 200 Ethernet flows,
then you would need to identify 200 labels as belonging to EVCx.
However there is one transport requirement for the EVC, not one for each
flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs but in
the proposed cases i see more rationales to unbundle than bundle the
VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the VLAN
per customer the question is simple, are all customers specs identical
and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
====
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked], IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating large numbers of VLAN IDs in the Label objects in control
signaling messages for Ethernet connections with frame switching
granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Lyndon Ong,
OIF TC Vice Chair Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Fri, 09 Mar 2007 19:30:48 +0000
Date: Fri, 9 Mar 2007 11:29:17 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
To: "Ong, Lyndon" <[email-masked]>, [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]

--0-1600286524-1173468557=:45458
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Lyndon,
   
  Let me try to explain my point. 
   
  Basically, we have two solutions to address the situation when the relationship between a router controller and data plane switches (TE nodes or TE routers) are 1:N, that is, when a single controller manages multiple TE routers.
   
  Solution 1 (suggested in the draft):
   
  Each TE Link advertising is extended with Local/Remote TE Router IDs pair. In this case, what is in the LinkID sub-TLV is not important really.
   
  Solution 2 (mine)
   
  The Router Address TLV is extended to advertise all TE Router IDs controlled by the advertising controller as routable addresses. The TE Link TLV is extended to advertise the local TE Router ID. However, there is no need to advertise the remote TE Router ID, because this is the function of the existing LinkID sub-TLV, which is to identify the remote end of the advertised TE link &#8211; remote TE Router ID.
   
  Both these approaches solve the problem; however, an important question to answer is:
   
  Do we need the TE Router IDs to be routable addresses?

The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. For example, if the network
 is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will contain path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable solves the problem how to signal the Path message along the provisioned path..

If you agree with this, than you will also agree that all TE Router IDs should be advertised within Router Address TLV

Hope that this helps.

Igor

 "Ong, Lyndon" <[email-masked]> wrote:
  Hi Dimitri,
 
 That was my understanding also, I don't see any issue with this.
 
 Cheers,
 
 Lyndon 
 
 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
 Sent: Friday, March 09, 2007 7:56 AM
 To: Igor Bryskin
 Cc: [email-masked]; Brungard, Deborah A, ALABS; [email-masked]
 Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 
 
 igor
 
 the drafts says
 
 "Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 
 Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 
 " 
 
 which is exactly what you are saying - when i say "it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n nodes" read "it is set to the router_id that identifies the remote RC..."
 in brief, we keep the semantic and add a discriminator (that does not apply in case of colocated 1:1 LSR) - this closes the first point -
 
 concerning the second point, since there is a possibility to have multiple associations in different LSAs i don't where the problem is ?
 
 thanks,
 -d.

 Igor Bryskin 
 Sent by: [email-masked]
 09/03/2007 16:05
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [email-masked], "Brungard, Deborah A, ALABS" 
 
 Subject: Re: Two questions on 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

 Dimitri,
 
 > Is the LinkID is the same as Remote TE Router ID? 
 
 no
 
 > LinkID unambiguosly identifies remote data plane node,
 
 no, it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n "nodes"
 
 IB>> No, I disagree. You see that's why it's so important to quote the
 RFCs/drafts, because people often interpret them differently.
 
 In RFC 3630 we read:
 "
 2.5.2. Link ID

 The Link ID sub-TLV identifies the other end of the link. For
 
 point-to-point links, this is the Router ID of the neighbor.
 
 "
 
 Note that it does not say whether this is the advertising Router ID 
 
 (identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it "identifies the other end 
 of the link". Because a link is terminated by TE nodes (and not 
 advertising routers) I conclude that LinkID identifies the remote TE node.
 
 Furthermore, earlier in RFC 3630 we read:
 "
 2.4.1. Router Address TLV
 
 The Router Address TLV specifies a stable IP address of the
 advertising router that is always reachable if there is any
 connectivity to it; this is typically implemented as a "loopback
 address". The key attribute is that the address does not become
 unusable if an
 interface is down. In other protocols, this is known
 as the "router ID"
 
 I interpret that this is the same router ID as in the upper quote. It is 
 advertised in the Router Address TLV, which is the only way today to 
 advertise TE Router ID. Hence the router ID in the context of this RFC is 
 the TE Router ID.
 
 The conclusion #1: the TE Link TLV, as it is today, always contains the ID 
 of the remote TE node. 
 
 The conclusion #2: there is a need to advertise several TE Router IDs 
 supported by the same RC (advertising router), which, I think, should be 
 proposed in your draft
 
 ps: second question is trivial, mathematical vs networking formulation (no 
 
 real difference)
 
 IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
 am asking why is that in the draft which is supposed to define ways to 
 support G.8080 
 
 Igor
 
 pps: if you want to put guidelines on e-mail responses probably directing 
 your e-mail to the GEN AREA would be more suitable 
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 09/03/2007 00:03
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [email-masked], "Brungard, Deborah A, ALABS" 
 
 Subject: Re: Two questions on 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

 Dimitri, no, it does not help.
 
 You didn't answer the first question, which is:
 
 Is the LinkID is the same as Remote TE Router ID? If no, what is the 
 difference? If yes, why do you need the latter? Both your pointers explain 
 
 why do you need advertising of the local TE Router ID (advertising router 
 may cover multiple data plane nodes), However, LinkID unambiguosly 
 identifies remote data plane node, and the need for the advertising of 
 Remote TE Router ID is not obvious
 
 BTW, You didn't answer the second question either.
 
 Igor
 
 PS, I have a suggestion for the working group: Let us disallow responding 
 to the comments/questions by just pointing to RFCs or drafts. In my view 
 it is quite unfriendly. It is always possible to cut and paste a piece 
 from the relevant RFC or draft confirming the points the writer is trying 
 to make.
 
 [email-masked] wrote:
 igor

 pls use version (or 03 
 when available to make comments)
 
 in that version you will see in Section 5.2
 
 " Note: The Link ID sub-TLV that identifies the other end of the link 
 (i.e. Router ID of the neighbor for point-to-point links) MUST 
 appear exactly once per Link TLV. This sub-TLV MUST be processed as 
 defined in [RFC3630]. "
 
 now why this sub-TLV 17, well for the reason explained at the beginning of 

 par.5.2
 but also in RFC 4652 Section 5.7
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 08/03/2007 22:11
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [email-masked], "Brungard, Deborah A, ALABS" 
 
 Subject: Two questions on 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

 Dimitri,
 I have a couple questions wrt the 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
 In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
 local and remote TE Router ID:
 
 0 1 2 3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | 17 | Length | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | Local TE Router Identifier | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | Remote TE Router Identifier | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 Although I do understand why there is a need for advertising the Local TE 
 Router ID, I donâ�'��"�t understand why the Remote Te Router ID? 
 Isnâ�'��"�t 
 this is 
 the same
 information 
 that is carried in the Link ID sub-TLV?
 In 6. you write:
 
 â�'��"A RA may contain smaller RAs inter-connected by links. 
 The limit of the subdivision results in
 a RA that contains two sub-networks interconnected by a single 
 link.â�'�
 
 In G.8080 I read:
 â�'��".... A routing area is defined by a set of subnetworks, the SNPP 
 links 
 
 that interconnect them, and the SNPPs representing the ends of the SNPP 
 links exiting that routing area. A routing area may contain smaller 
 routing areas interconnected by SNPP links. The limit of subdivision 
 results in a routing area that contains ]one subnetwork.â�'�
 
 Why is the discrepancy?
 
 Thanks,
 Igor

 [
 Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.

 Now that's room service! Choose from over 150,000 hotels 
 in 45,000 destinations on Yahoo! Travel to find your fit.

 Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.

 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.
--0-1600286524-1173468557=:45458
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  <div class="MsoNormal">Lyndon,</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Let me try to explain my point. </div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Basically, we have two solutions to address the situation when the relationship between a router controller and data plane switches (TE nodes or TE routers) are 1:N, that is, when a single controller manages multiple TE routers.</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Solution 1 (suggested in the draft):</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Each TE Link advertising is extended with Local/Remote TE Router IDs pair. In this case, what is in the LinkID sub-TLV is not important really.</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Solution 2 (mine)</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">The Router Address TLV is
 extended to advertise all TE Router IDs controlled by the advertising controller as routable addresses. The TE Link TLV is extended to advertise the local TE Router ID. However, there is no need to advertise the remote TE Router ID, because this is the function of the existing LinkID sub-TLV, which is to identify the remote end of the advertised TE link &#8211; remote TE Router ID.</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Both these approaches solve the problem; however, an important question to answer is:</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Do we need the TE Router IDs to be routable addresses?</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <pre><span style="font-family: &quot;Times New Roman&quot;;">The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. For example, if the network<br>&nbsp;is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will contain
 path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable solves the problem how to signal the Path message along the provisioned path..<o:p></o:p></span></pre><pre><span style="font-family: &quot;Times New Roman&quot;;">If you agree with this, than you will also agree that all TE Router IDs should be advertised within Router Address TLV<o:p></o:p></span></pre><pre><span style="font-family: &quot;Times New Roman&quot;;">Hope that this helps.<o:p></o:p></span></pre><pre><span style="font-family: &quot;Times New Roman&quot;;"><o:p>&nbsp;</o:p></span></pre><pre><span style="font-family: &quot;Times New Roman&quot;;">Igor<o:p></o:p></span></pre><pre><o:p>&nbsp;</o:p></pre>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal"><br> <br> <b><i>"Ong, Lyndon" &lt;[email-masked]&gt;</i></b> wrote:<o:p></o:p></div>  <div class="MsoNormal">Hi Dimitri,<br> <br> That was my understanding also, I don't see any issue with this.<br> <br> Cheers,<br> <br>
 Lyndon <br> <br> -----Original Message-----<br> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]<br> Sent: Friday, March 09, 2007 7:56 AM<br> To: <st1:PersonName w:st="on">Igor Bryskin</st1:PersonName><br> Cc: [email-masked]; Brungard, Deborah A, ALABS; [email-masked]<br> Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf <br> <br> igor<br> <br> the drafts says<br> <br> "Note: The Link ID sub-TLV that identifies the other end of the link (i.e. <br> Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. <br> " <br> <br> which is exactly what you are saying - when i say "it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n nodes" read "it is set to the router_id that identifies the remote RC..."<br> in brief, we keep the semantic and add a
 discriminator (that does not apply in case of colocated 1:1 LSR) - this closes the first point -<br> <br> concerning the second point, since there is a possibility to have multiple <Router_ID, te="" router_id="">associations in different LSAs i don't where the problem is ?<br> <br> thanks,<br> -d.<br> <br> <br> <br> <br> <br> <st1:PersonName w:st="on">Igor Bryskin</st1:PersonName> <br> <[email-masked]>Sent by: [email-masked]<br> 09/03/2007 16:05<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [email-masked], "Brungard, Deborah A, ALABS" <br> <br> <[email-masked]>Subject: Re: Two questions on <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br> <br> <br> Dimitri,<br> <br> &gt; Is the LinkID is the same as Remote TE Router ID? <br> <br> no<br> <br> &gt; LinkID unambiguosly identifies remote data plane node,<br> <br> no, it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n "nodes"<br>
 <br> IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the<br> RFCs/drafts, because people often interpret them differently.<br> <br> In RFC 3630 we read:<br> "<br> 2.5.2. Link ID<br> <br> <br> <br> The Link ID sub-TLV identifies the other end of the link. For<br> <br> point-to-point links, this is the Router ID of the neighbor.<br> <br> "<br> <br> Note that it does not say whether this is the advertising Router ID <br> <br> (identifying neighbor RC) or TE Router ID (identifying the<br> neighbor TE node). However, it does say that it "identifies the other end <br> of the link". Because a link is terminated by TE nodes (and not <br> advertising routers) I conclude that LinkID identifies the remote TE node.<br> <br> Furthermore, earlier in RFC 3630 we read:<br> "<br> 2.4.1. Router Address TLV<br> <br> The Router Address TLV specifies a stable IP address of the<br> advertising router that is always reachable if there is any<br> connectivity to it; this
 is typically implemented as a "loopback<br> address". The key attribute is that the address does not become<br> unusable if an<br> interface is down. In other protocols, this is known<br> as the "router ID"<br> <br> I interpret that this is the same router ID as in the upper quote. It is <br> advertised in the Router Address TLV, which is the only way today to <br> advertise TE Router ID. Hence the router ID in the context of this RFC is <br> the TE Router ID.<br> <br> The conclusion #1: the TE Link TLV, as it is today, always contains the ID <br> of the remote TE node. <br> <br> The conclusion #2: there is a need to advertise several TE Router IDs <br> supported by the same RC (advertising router), which, I think, should be <br> proposed in your draft<br> <br> ps: second question is trivial, mathematical vs networking formulation (no <br> <br> real difference)<br> <br> IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br> am asking why is
 that in the draft which is supposed to define ways to <br> support G.8080 <br> <br> Igor<br> <br> pps: if you want to put guidelines on e-mail responses probably directing <br> your e-mail to the GEN AREA would be more suitable <br> <br> hope this helps,<br> -d.<br> <br> <br> <br> <br> <st1:PersonName w:st="on">Igor Bryskin</st1:PersonName> <br> 09/03/2007 00:03<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [email-masked], "Brungard, Deborah A, ALABS" <br> <br> Subject: Re: Two questions on <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br> <br> <br> Dimitri, no, it does not help.<br> <br> You didn't answer the first question, which is:<br> <br> Is the LinkID is the same as Remote TE Router ID? If no, what is the <br> difference? If yes, why do you need the latter? Both your pointers explain <br> <br> why do you need advertising of the local TE Router ID (advertising router <br> may cover multiple data plane nodes), However, LinkID unambiguosly
 <br> identifies remote data plane node, and the need for the advertising of <br> Remote TE Router ID is not obvious<br> <br> BTW, You didn't answer the second question either.<br> <br> Igor<br> <br> PS, I have a suggestion for the working group: Let us disallow responding <br> to the comments/questions by just pointing to RFCs or drafts. In my view <br> it is quite unfriendly. It is always possible to cut and paste a piece <br> from the relevant RFC or draft confirming the points the writer is trying <br> to make.<br> <br> [email-masked] wrote:<br> igor<br> <br> <br> pls use version (or 03 <br> when available to make comments)<br> <br> in that version you will see in Section 5.2<br> <br> " Note: The Link ID sub-TLV that identifies the other end of the link <br> (i.e. Router ID of the neighbor for point-to-point links) MUST <br> appear exactly once per Link TLV. This sub-TLV MUST be processed as <br> defined in [RFC3630]. "<br> <br> now why this
 sub-TLV 17, well for the reason explained at the beginning of <br> <br> <br> par.5.2<br> but also in RFC 4652 Section 5.7<br> <br> hope this helps,<br> -d.<br> <br> <br> <br> <br> <st1:PersonName w:st="on">Igor Bryskin</st1:PersonName> <br> 08/03/2007 22:11<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [email-masked], "Brungard, Deborah A, ALABS" <br> <br> Subject: Two questions on <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br> <br> <br> Dimitri,<br> I have a couple questions wrt the <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br> In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br> local and remote TE Router ID:<br> <br> 0 1 2 3 <br> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | 17 | Length | <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | Local TE Router Identifier | <br>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | Remote TE Router Identifier | <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> <br> Although I do understand why there is a need for advertising the Local TE <br> Router ID, I donâ�'��"�t understand why the Remote Te Router ID? <br> Isnâ�'��"�t <br> this is <br> the same<br> information <br> that is carried in the Link ID sub-TLV?<br> In 6. you write:<br> <br> â�'��"A RA may contain smaller RAs inter-connected by links. <br> The limit of the subdivision results in<br> a RA that contains two sub-networks interconnected by a single <br> link.â�'�<br> <br> In G.8080 I read:<br> â�'��".... A routing area is defined by a set of subnetworks, the SNPP <br> links <br> <br> that interconnect them, and the SNPPs representing the ends of the SNPP <br> links exiting that routing area. A routing area may contain smaller <br> routing areas interconnected by SNPP links. The limit of
 subdivision <br> results in a routing area that contains ]one subnetwork.â�'�<br> <br> Why is the discrepancy?<br> <br> Thanks,<br> Igor<br> <br> <br> [<br> Sucker-punch spam with award-winning protection.<br> Try the free Yahoo! Mail Beta.<br> <br> <br> Now that's room service! Choose from over 150,000 hotels <br> in 45,000 destinations on Yahoo! Travel to find your fit.<br> <br> <br> <br> Sucker-punch spam with award-winning protection.<br> Try the free Yahoo! Mail Beta.<br> <br style=""> <!--[if !supportLineBreakNewLine]--><br style=""> <!--[endif]--><o:p></o:p></[email-masked]></[email-masked]></Router_ID,></div>    <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <p>&#32;

<hr size=1>
<a href="http://us.rd.yahoo.com/evt=49678/*http://smallbusiness.yahoo.com/domains/?p=BESTDEAL"> Get your own web address.</a><br> Have a HUGE year through <a href="
http://us.rd.yahoo.com/evt=49678/*http://smallbusiness.yahoo.com/domains/?p=BESTDEAL">Yahoo! Small Business.</a>
--0-1600286524-1173468557=:45458--

Delivery-date: Fri, 09 Mar 2007 18:29:57 +0000
Content-class: urn:content-classes:message
Subject: RE: New communication from the OIF
Date: Fri, 9 Mar 2007 13:29:03 -0500
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>

Hi Dimitri,

I understand what you are saying, however it is still not clear what
the solution should be:

a) it is not clear as you say what "label" value you would use for the
EVC

b) there still needs to be some method of enumerating the VIDs carried
by=20
the EVC (for this type of EVC).  If the signaling does not enumerate the
VIDs,=20
then some other mechanism is necessary, to create what I think you refer
to as=20
a "bundle index".

Cheers,

Lyndon=20

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]=20
Sent: Wednesday, March 07, 2007 4:27 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
MEURIC Julien RD-CORE-LAN; [email-masked]
Subject: RE: New communication from the OIF

lyndon

o) first you will observe that the doc. MEF traffic parameters does not
speak about "label distribution"=20

reason: you will observe (by section 3.4 of RFC 3209) that label per
sender (shared reservation or not) and label per link reservation
(de-facto shared) are possible

hence the usage of RSVP-TE traffic parameters result also in using these
rules (i will add a statement to make this clearer in the next release)
but remember the doc does not define any "label" format for MEF purposes

o) second you will observe that the document does not infer any "VID" to
EVC relationship, noticing that single CoS and multiple CoS per EVC are
covered in the draft, and this, independently of the number of VIDs per
EVC=20

o) third closing the loop, the draft is not inferring any "label" to
"VID"=20
relationship (that relationship when equating an EVC with single or
multiple CoS to an RSVP session is straightforward)=20

the questions are thus the following

1. to which entity the traffic parameters are applied in case of a
single EVC with multiple VIDs ? if you are following the reasoning since
so far it should be per EVC (for the set of VIDs)=20

note: per EVC+VID taken individually requires separate signaling
otherwise you need a list of tspecs and a list of label + correspondance
and this is another protocol, in fact boiling down to a simple
relationship=20

2. what is the "label" value(s) in this case ? using the set of VIDs to
represent a "reservation" at the control plane level is completely
useless as the control plane doesn't need this info to create PSB/RSB
and the entity to which the reservation is associated is the "EVC" ...
so you will need to find a unique per-EVC characteristic when the 1:1
relationship between label and EVC is limitative e.g. a bundle index or
so (something that boils you down to a 1:1 relationship because
indepedently of the "protocol" being explicit in the enumeration IS
cumbersome)

 thanks,
-d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
08/03/2007 00:28
=20
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,=20
"Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN"=20
<[email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which=20
causes a problem if you are=20
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case=20
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to=20
understand how this would work - any solutions coming out of CCAMP would
be
very welcome.=20

- not sure if there is an issue on point-to-multipoint, we were just
trying to=20
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]=20
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows based on the associated Ethernet labels, each with
some associated bandwidth.  The receiving node creates a corresponding
tunnel and aggregates these flows into the tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking with our MEF 'experts' on this), the originator requests
an EVC service, which has an associated bandwidth from one edge of the
network to another, and can support within it several Ethernet flows
that share this bandwidth.  If there are multiple EVCs, the originator
uses signaling to identify which labels should be carried in EVCx and
which should be carried in EVCy - if EVCx carries 200 Ethernet flows,
then you would need to identify 200 labels as belonging to EVCx.
However there is one transport requirement for the EVC, not one for each
flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs but in
the proposed cases i see more rationales to unbundle than bundle the
VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the VLAN
per customer the question is simple, are all customers specs identical
and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
=3D=3D=3D=3D
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked], IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating large numbers of VLAN IDs in the Label objects in control
signaling messages for Ethernet connections with frame switching
granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Lyndon Ong,
OIF TC Vice Chair Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Fri, 09 Mar 2007 18:29:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
Date: Fri, 9 Mar 2007 13:22:23 -0500
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>

Hi Dimitri,

That was my understanding also, I don't see any issue with this.

Cheers,

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; =
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf=20

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link =
(i.e.=20
Router ID of the neighbor for point-to-point links) MUST appear exactly =
once per Link TLV. This sub-TLV MUST be processed as defined in =
[RFC3630].=20
"=20

which is exactly what you are saying - when i say "it identifies the =
remote RC not the remote data plane "node" in case the remote RC is =
associate to n nodes" read "it is set to the router_id that identifies =
the remote RC..."
in brief, we keep the semantic and add a discriminator (that does not =
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have =
multiple <Router_ID, TE Router_ID> associations in different LSAs i =
don't where the problem is ?

thanks,
-d.

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
09/03/2007 16:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS"=20
<[email-masked]>
        Subject:        Re: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID?=20

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case =
the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2.  Link ID

   The Link ID sub-TLV identifies the other end of the link.  For

   point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID=20

(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it "identifies the other =
end=20
of the link". Because a link is terminated by TE nodes (and not=20
advertising routers) I conclude that LinkID identifies the remote TE =
node.
=20
Furthermore, earlier in RFC 3630 we read:
"
2.4.1.  Router Address TLV
=20
   The Router Address TLV specifies a stable IP address of the
   advertising router that is always reachable if there is any
   connectivity to it; this is typically implemented as a "loopback
   address".  The key attribute is that the address does not become
   unusable if an
 interface is down.  In other protocols, this is known
   as the "router ID"
=20
I interpret that this is the same router ID as in the upper quote. It is =

advertised in the Router Address TLV, which is the only way today to=20
advertise TE Router ID. Hence the router ID in the context of this RFC =
is=20
the TE Router ID.
=20
The conclusion #1: the TE Link TLV, as it is today, always contains the =
ID=20
of the remote TE node.=20
=20
The conclusion #2: there is a need to advertise several TE Router IDs=20
supported by the same RC (advertising router), which, I think, should be =

proposed in your draft
=20
ps: second question is trivial, mathematical vs networking formulation =
(no=20

real difference)
=20
IB>> Well, it changes one of the fundamental definitions of G.8080, and =
I=20
am asking why is that in the draft which is supposed to define ways to=20
support G.8080=20
=20
Igor

pps: if you want to put guidelines on e-mail responses probably =
directing=20
your e-mail to the GEN AREA would be more suitable=20

hope this helps,
-d.

Igor Bryskin=20
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS"=20

Subject: Re: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the=20
difference? If yes, why do you need the latter? Both your pointers =
explain=20

why do you need advertising of the local TE Router ID (advertising =
router=20
may cover multiple data plane nodes), However, LinkID unambiguosly=20
identifies remote data plane node, and the need for the advertising of=20
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow =
responding=20
to the comments/questions by just pointing to RFCs or drafts. In my view =

it is quite unfriendly. It is always possible to cut and paste a piece=20
from the relevant RFC or draft confirming the points the writer is =
trying=20
to make.

[email-masked] wrote:
igor

pls use version (or 03=20
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link=20
(i.e. Router ID of the neighbor for point-to-point links) MUST=20
appear exactly once per Link TLV. This sub-TLV MUST be processed as=20
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning =
of=20

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin=20
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS"=20

Subject: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising=20
local and remote TE Router ID:

0 1 2 3=20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| 17 | Length |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| Local TE Router Identifier |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| Remote TE Router Identifier |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

Although I do understand why there is a need for advertising the Local =
TE=20
Router ID, I don=C3=A2=E2'=AC=E2"=A2t understand why the Remote Te =
Router ID?=20
Isn=C3=A2=E2'=AC=E2"=A2t=20
this is=20
the same
information=20
that is carried in the Link ID sub-TLV?
In 6. you write:

=C3=A2=E2'=AC=C5"A RA may contain smaller RAs inter-connected by links.=20
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single=20
link.=C3=A2=E2'=AC=C2=9D

In G.8080 I read:
=C3=A2=E2'=AC=C5".... A routing area is defined by a set of subnetworks, =
the SNPP=20
links=20

that interconnect them, and the SNPPs representing the ends of the SNPP=20
links exiting that routing area. A routing area may contain smaller=20
routing areas interconnected by SNPP links. The limit of subdivision=20
results in a routing area that contains ]one =
subnetwork.=C3=A2=E2'=AC=C2=9D

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels=20
in 45,000 destinations on Yahoo! Travel to find your fit.

=20
 Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Delivery-date: Fri, 09 Mar 2007 18:14:28 +0000
Date: Fri, 9 Mar 2007 10:13:19 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]

--0-635280490-1173463999=:55319
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Thanks, that is exactly what I expected to hear.

Igor

"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> wrote: Hi Igor,

To save Dimitri time on scanning G8080, I can quickly answer your 2nd question (if I determine it correctly as it is a long thread), you ask:
"In 6. you write:
A RA may contain smaller RAs inter-connected by links. The limit of the subdivision results in a RA that contains two sub-networks interconnected by a single link.
 
In G.8080 I read:
.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains one subnetwork.
Why is the discrepancy?"

And you continued to say in your follow up mail:
"IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080"

CCAMP has already agreed to update this definition to the new definition in the next version of the draft. CCAMP was informed via Q14/15's Liaison in November 2006 that the definition was changed. The draft used the definition of G.8080 (2001 and 2003). The definition was updated by an amendment in 2005 to the new definition which you reference. We did not receive any further details except to say that it was updated.

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 
Router ID of the neighbor for point-to-point links) MUST appear exactly 
once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 
" 

which is exactly what you are saying - when i say "it identifies the 
remote RC not the remote data plane "node" in case the remote RC is 
associate to n nodes" read "it is set to the router_id that identifies the 
remote RC..."
in brief, we keep the semantic and add a discriminator (that does not 
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple 
 associations in different LSAs i don't where the 
problem is ?

thanks,
-d.

Igor Bryskin 
Sent by: [email-masked]
09/03/2007 16:05
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 

        Subject:        Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID? 

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case 
the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the 
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2.  Link ID

   The Link ID sub-TLV identifies the other end of the link.  For

   point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it "identifies the other end 
of the link". Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.
 
Furthermore, earlier in RFC 3630 we read:
"
2.4.1.  Router Address TLV
 
   The Router Address TLV specifies a stable IP address of the
   advertising router that is always reachable if there is any
   connectivity to it; this is typically implemented as a "loopback
   address".  The key attribute is that the address does not become
   unusable if an
 interface is down.  In other protocols, this is known
   as the "router ID"
 
I interpret that this is the same router ID as in the upper quote. It is 
advertised in the Router Address TLV, which is the only way today to 
advertise TE Router ID. Hence the router ID in the context of this RFC is 
the TE Router ID.
 
The conclusion #1: the TE Link TLV, as it is today, always contains the ID 
of the remote TE node. 
 
The conclusion #2: there is a need to advertise several TE Router IDs 
supported by the same RC (advertising router), which, I think, should be 
proposed in your draft
 
ps: second question is trivial, mathematical vs networking formulation (no 

real difference)
 
IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080 
 
Igor

pps: if you want to put guidelines on e-mail responses probably directing 
your e-mail to the GEN AREA would be more suitable 

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the 
difference? If yes, why do you need the latter? Both your pointers explain 

why do you need advertising of the local TE Router ID (advertising router 
may cover multiple data plane nodes), However, LinkID unambiguosly 
identifies remote data plane node, and the need for the advertising of 
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding 
to the comments/questions by just pointing to RFCs or drafts. In my view 
it is quite unfriendly. It is always possible to cut and paste a piece 
from the relevant RFC or draft confirming the points the writer is trying 
to make.

[email-masked] wrote:
igor

pls use version (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
(i.e. Router ID of the neighbor for point-to-point links) MUST 
appear exactly once per Link TLV. This sub-TLV MUST be processed as 
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS" 

Subject: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:

0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 17 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Local TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Remote TE Router Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donâ�'��"�t understand why the Remote Te Router ID? 
Isnâ�'��"�t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

â�'��"A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.â�'�

In G.8080 I read:
â�'��".... A routing area is defined by a set of subnetworks, the SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.â�'�

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

 Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

---------------------------------
Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.
--0-635280490-1173463999=:55319
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Thanks, that is exactly what I expected to hear.<br><br>Igor<br><br><b><i>"BRUNGARD, DEBORAH A, ATTLABS" &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 Igor,<br><br>To save Dimitri time on scanning G8080, I can quickly answer your 2nd question (if I determine it correctly as it is a long thread), you ask:<br>"In 6. you write:<br>A RA may contain smaller RAs inter-connected by links. The limit of the subdivision results in a RA that contains two sub-networks interconnected by a single link.<br> <br>In G.8080 I read:<br>.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains one subnetwork.<br>Why is the
 discrepancy?"<br><br>And you continued to say in your follow up mail:<br>"IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br>am asking why is that in the draft which is supposed to define ways to <br>support G.8080"<br><br>CCAMP has already agreed to update this definition to the new definition in the next version of the draft. CCAMP was informed via Q14/15's Liaison in November 2006 that the definition was changed. The draft used the definition of G.8080 (2001 and 2003). The definition was updated by an amendment in 2005 to the new definition which you reference. We did not receive any further details except to say that it was updated.<br><br>Deborah <br>  <br><br>-----Original Message-----<br>From: [email-masked] [mailto:[email-masked]] <br>Sent: Friday, March 09, 2007 10:56 AM<br>To: Igor Bryskin<br>Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]<br>Subject:
 Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf <br><br>igor<br><br>the drafts says<br><br>"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. <br>Router ID of the neighbor for point-to-point links) MUST appear exactly <br>once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. <br>" <br><br>which is exactly what you are saying - when i say "it identifies the <br>remote RC not the remote data plane "node" in case the remote RC is <br>associate to n nodes" read "it is set to the router_id that identifies the <br>remote RC..."<br>in brief, we keep the semantic and add a discriminator (that does not <br>apply in case of colocated 1:1 LSR) - this closes the first point -<br><br>concerning the second point, since there is a possibility to have multiple <br><Router_ID, te="" router_id=""> associations in different LSAs i don't where the <br>problem is ?<br><br>thanks,<br>-d.<br><br><br><br><br><br>Igor Bryskin
 <[email-masked]><br>Sent by: [email-masked]<br>09/03/2007 16:05<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked], "Brungard, Deborah A, ALABS" <br><[email-masked]><br>        Subject:        Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br><br>&gt; Is the LinkID is the same as Remote TE Router ID? <br><br>no<br><br>&gt; LinkID unambiguosly identifies remote data plane node,<br><br>no, it identifies the remote RC not the remote data plane "node" in case <br>the remote RC is associate to n "nodes"<br><br>IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the <br>RFCs/drafts, because people often interpret them differently.<br><br>In RFC 3630 we read:<br>"<br>2.5.2.  Link ID<br><br><br><br>   The Link ID sub-TLV identifies the other end of the link.  For<br><br>   point-to-point links, this is the Router ID of the
 neighbor.<br><br>"<br><br>Note that it does not say whether this is the advertising Router ID <br><br>(identifying neighbor RC) or TE Router ID (identifying the<br> neighbor TE node). However, it does say that it "identifies the other end <br>of the link". Because a link is terminated by TE nodes (and not <br>advertising routers) I conclude that LinkID identifies the remote TE node.<br> <br>Furthermore, earlier in RFC 3630 we read:<br>"<br>2.4.1.  Router Address TLV<br> <br>   The Router Address TLV specifies a stable IP address of the<br>   advertising router that is always reachable if there is any<br>   connectivity to it; this is typically implemented as a "loopback<br>   address".  The key attribute is that the address does not become<br>   unusable if an<br> interface is down.  In other protocols, this is known<br>   as the "router ID"<br> <br>I interpret that this is the same router ID as in the upper quote. It is <br>advertised in the Router Address TLV, which is
 the only way today to <br>advertise TE Router ID. Hence the router ID in the context of this RFC is <br>the TE Router ID.<br> <br>The conclusion #1: the TE Link TLV, as it is today, always contains the ID <br>of the remote TE node. <br> <br>The conclusion #2: there is a need to advertise several TE Router IDs <br>supported by the same RC (advertising router), which, I think, should be <br>proposed in your draft<br> <br>ps: second question is trivial, mathematical vs networking formulation (no <br><br>real difference)<br> <br>IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I <br>am asking why is that in the draft which is supposed to define ways to <br>support G.8080 <br> <br>Igor<br><br>pps: if you want to put guidelines on e-mail responses probably directing <br>your e-mail to the GEN AREA would be more suitable <br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>09/03/2007 00:03<br><br>To: Dimitri
 PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Re: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri, no, it does not help.<br><br>You didn't answer the first question, which is:<br><br>Is the LinkID is the same as Remote TE Router ID? If no, what is the <br>difference? If yes, why do you need the latter? Both your pointers explain <br><br>why do you need advertising of the local TE Router ID (advertising router <br>may cover multiple data plane nodes), However, LinkID unambiguosly <br>identifies remote data plane node, and the need for the advertising of <br>Remote TE Router ID is not obvious<br><br>BTW, You didn't answer the second question either.<br><br>Igor<br><br>PS, I have a suggestion for the working group: Let us disallow responding <br>to the comments/questions by just pointing to RFCs or drafts. In my view <br>it is quite unfriendly. It is always possible to cut
 and paste a piece <br>from the relevant RFC or draft confirming the points the writer is trying <br>to make.<br><br>[email-masked] wrote:<br>igor<br><br><br>pls use version (or 03 <br>when available to make comments)<br><br>in that version you will see in Section 5.2<br><br>" Note: The Link ID sub-TLV that identifies the other end of the link <br>(i.e. Router ID of the neighbor for point-to-point links) MUST <br>appear exactly once per Link TLV. This sub-TLV MUST be processed as <br>defined in [RFC3630]. "<br><br>now why this sub-TLV 17, well for the reason explained at the beginning of <br><br><br>par.5.2<br>but also in RFC 4652 Section 5.7<br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <br>08/03/2007 22:11<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked], "Brungard, Deborah A, ALABS" <br><br>Subject: Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br><br><br>Dimitri,<br>I have a
 couple questions wrt the <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br>local and remote TE Router ID:<br><br>0 1 2 3 <br>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| 17 | Length | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Local TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>| Remote TE Router Identifier | <br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br><br>Although I do understand why there is a need for advertising the Local TE <br>Router ID, I donâ�'��"�t understand why the Remote Te Router ID? <br>Isnâ�'��"�t <br>this is <br>the same<br>information <br>that is carried in the Link ID sub-TLV?<br>In 6. you write:<br><br>â�'��"A RA may contain smaller RAs inter-connected by links.
 <br>The limit of the subdivision results in<br>a RA that contains two sub-networks interconnected by a single <br>link.â�'�<br><br>In G.8080 I read:<br>â�'��".... A routing area is defined by a set of subnetworks, the SNPP <br>links <br><br>that interconnect them, and the SNPPs representing the ends of the SNPP <br>links exiting that routing area. A routing area may contain smaller <br>routing areas interconnected by SNPP links. The limit of subdivision <br>results in a routing area that contains ]one subnetwork.â�'�<br><br>Why is the discrepancy?<br><br>Thanks,<br>Igor<br><br><br>[<br>Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail Beta.<br><br><br>Now that's room service! Choose from over 150,000 hotels <br>in 45,000 destinations on Yahoo! Travel to find your fit.<br><br><br> <br> Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail
 Beta.<br><br><br></[email-masked]></[email-masked]></Router_ID,></blockquote><br><p>&#32;

<hr size=1>Now that's room service! <a href="http://travel.yahoo.com/hotelsearchpage;_ylc=X3oDMTFtaTIzNXVjBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzIEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--
">Choose from over 150,000 hotels <br>in 45,000 destinations on Yahoo! Travel</a> to find your fit.
--0-635280490-1173463999=:55319--

Delivery-date: Fri, 09 Mar 2007 17:35:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
Date: Fri, 9 Mar 2007 11:33:42 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>, "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Igor,

To save Dimitri time on scanning G8080, I can quickly answer your 2nd =
question (if I determine it correctly as it is a long thread), you ask:
"In 6. you write:
A RA may contain smaller RAs inter-connected by links. The limit of the =
subdivision results in a RA that contains two sub-networks =
interconnected by a single link.
=20
In G.8080 I read:
.... A routing area is defined by a set of subnetworks, the SNPP links =
that interconnect them, and the SNPPs representing the ends of the SNPP =
links exiting that routing area. A routing area may contain smaller =
routing areas interconnected by SNPP links. The limit of subdivision =
results in a routing area that contains one subnetwork.
Why is the discrepancy?"

And you continued to say in your follow up mail:
"IB>> Well, it changes one of the fundamental definitions of G.8080, and =
I=20
am asking why is that in the draft which is supposed to define ways to=20
support G.8080"

CCAMP has already agreed to update this definition to the new definition =
in the next version of the draft. CCAMP was informed via Q14/15's =
Liaison in November 2006 that the definition was changed. The draft used =
the definition of G.8080 (2001 and 2003). The definition was updated by =
an amendment in 2005 to the new definition which you reference. We did =
not receive any further details except to say that it was updated.

Deborah=20
 =20

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]=20
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS; =
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf=20

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link =
(i.e.=20
Router ID of the neighbor for point-to-point links) MUST appear exactly=20
once per Link TLV. This sub-TLV MUST be processed as defined in =
[RFC3630].=20
"=20

which is exactly what you are saying - when i say "it identifies the=20
remote RC not the remote data plane "node" in case the remote RC is=20
associate to n nodes" read "it is set to the router_id that identifies =
the=20
remote RC..."
in brief, we keep the semantic and add a discriminator (that does not=20
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have =
multiple=20
<Router_ID, TE Router_ID> associations in different LSAs i don't where =
the=20
problem is ?

thanks,
-d.

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
09/03/2007 16:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS"=20
<[email-masked]>
        Subject:        Re: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,

> Is the LinkID is the same as Remote TE Router ID?=20

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case =

the remote RC is associate to n "nodes"

IB>> No, I disagree. You see that's why it's so important to quote the=20
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2.  Link ID

   The Link ID sub-TLV identifies the other end of the link.  For

   point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID=20

(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it "identifies the other =
end=20
of the link". Because a link is terminated by TE nodes (and not=20
advertising routers) I conclude that LinkID identifies the remote TE =
node.
=20
Furthermore, earlier in RFC 3630 we read:
"
2.4.1.  Router Address TLV
=20
   The Router Address TLV specifies a stable IP address of the
   advertising router that is always reachable if there is any
   connectivity to it; this is typically implemented as a "loopback
   address".  The key attribute is that the address does not become
   unusable if an
 interface is down.  In other protocols, this is known
   as the "router ID"
=20
I interpret that this is the same router ID as in the upper quote. It is =

advertised in the Router Address TLV, which is the only way today to=20
advertise TE Router ID. Hence the router ID in the context of this RFC =
is=20
the TE Router ID.
=20
The conclusion #1: the TE Link TLV, as it is today, always contains the =
ID=20
of the remote TE node.=20
=20
The conclusion #2: there is a need to advertise several TE Router IDs=20
supported by the same RC (advertising router), which, I think, should be =

proposed in your draft
=20
ps: second question is trivial, mathematical vs networking formulation =
(no=20

real difference)
=20
IB>> Well, it changes one of the fundamental definitions of G.8080, and =
I=20
am asking why is that in the draft which is supposed to define ways to=20
support G.8080=20
=20
Igor

pps: if you want to put guidelines on e-mail responses probably =
directing=20
your e-mail to the GEN AREA would be more suitable=20

hope this helps,
-d.

Igor Bryskin=20
09/03/2007 00:03

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS"=20

Subject: Re: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the=20
difference? If yes, why do you need the latter? Both your pointers =
explain=20

why do you need advertising of the local TE Router ID (advertising =
router=20
may cover multiple data plane nodes), However, LinkID unambiguosly=20
identifies remote data plane node, and the need for the advertising of=20
Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow =
responding=20
to the comments/questions by just pointing to RFCs or drafts. In my view =

it is quite unfriendly. It is always possible to cut and paste a piece=20
from the relevant RFC or draft confirming the points the writer is =
trying=20
to make.

[email-masked] wrote:
igor

pls use version (or 03=20
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link=20
(i.e. Router ID of the neighbor for point-to-point links) MUST=20
appear exactly once per Link TLV. This sub-TLV MUST be processed as=20
defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning =
of=20

par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin=20
08/03/2007 22:11

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked], "Brungard, Deborah A, ALABS"=20

Subject: Two questions on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
I have a couple questions wrt the=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising=20
local and remote TE Router ID:

0 1 2 3=20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| 17 | Length |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| Local TE Router Identifier |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
| Remote TE Router Identifier |=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

Although I do understand why there is a need for advertising the Local =
TE=20
Router ID, I don=C3=A2=E2'=AC=E2"=A2t understand why the Remote Te =
Router ID?=20
Isn=C3=A2=E2'=AC=E2"=A2t=20
this is=20
the same
information=20
that is carried in the Link ID sub-TLV?
In 6. you write:

=C3=A2=E2'=AC=C5"A RA may contain smaller RAs inter-connected by links.=20
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single=20
link.=C3=A2=E2'=AC=C2=9D

In G.8080 I read:
=C3=A2=E2'=AC=C5".... A routing area is defined by a set of subnetworks, =
the SNPP=20
links=20

that interconnect them, and the SNPPs representing the ends of the SNPP=20
links exiting that routing area. A routing area may contain smaller=20
routing areas interconnected by SNPP links. The limit of subdivision=20
results in a routing area that contains ]one =
subnetwork.=C3=A2=E2'=AC=C2=9D

Why is the discrepancy?

Thanks,
Igor

[
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Now that's room service! Choose from over 150,000 hotels=20
in 45,000 destinations on Yahoo! Travel to find your fit.

=20
 Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

Delivery-date: Fri, 09 Mar 2007 15:57:19 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
From: [email-masked]
Date: Fri, 9 Mar 2007 16:56:29 +0100

Delivery-date: Fri, 09 Mar 2007 15:07:33 +0000
Date: Fri, 9 Mar 2007 07:05:02 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>

--0-421440143-1173452702=:92923
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Dimitri,
  
 > Is the LinkID is the same as Remote TE Router ID? 
 
 no
 
 > LinkID unambiguosly identifies remote data plane node,
 
 no, it identifies the remote RC not the remote data plane "node" in case 
 the remote RC is associate to n "nodes"
 
 IB>> No, I disagree. You see that's why it's so important to quote the RFCs/drafts, because people often interpret them differently.
 
 In RFC 3630 we read:
 "
  
2.5.2.  Link ID

   The Link ID sub-TLV identifies the other end of the link.  For

   point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the neighbor TE node). However, it does say that it &#8220;identifies the other end of the link&#8221;. Because a link is terminated by TE nodes (and not advertising routers) I conclude that LinkID identifies the remote TE node.

Furthermore, earlier in RFC 3630 we read:

&#8220;

2.4.1.  Router Address TLV

   The Router Address TLV specifies a stable IP address of the

   advertising router that is always reachable if there is any

   connectivity to it; this is typically implemented as a "loopback

   address".  The key attribute is that the address does not become

   unusable if an interface is down.  In other protocols, this is known

   as the "router ID"

I interpret that this is the same router ID as in the upper quote. It is advertised in the Router Address TLV, which is the only way today to advertise TE Router ID. Hence the router ID in the context of this RFC is the TE Router ID.

The conclusion #1: the TE Link TLV, as it is today, always contains the ID of the remote TE node. 

The conclusion #2: there is a need to advertise several TE Router IDs supported by the same RC (advertising router), which, I think, should be proposed in your draft

  ps: second question is trivial, mathematical vs networking formulation (no 
 real difference)
   
  IB>> Well, it changes one of the fundamental definitions of G.8080, and I am asking why is that in the draft which is supposed to define ways to support G.8080 
   
  Igor
 
 pps: if you want to put guidelines on e-mail responses probably directing 
 your e-mail to the GEN AREA would be more suitable 
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 09/03/2007 00:03
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [email-masked], "Brungard, Deborah A, ALABS" 
 
 Subject: Re: Two questions on 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

 Dimitri, no, it does not help.
 
 You didn't answer the first question, which is:
 
 Is the LinkID is the same as Remote TE Router ID? If no, what is the 
 difference? If yes, why do you need the latter? Both your pointers explain 
 why do you need advertising of the local TE Router ID (advertising router 
 may cover multiple data plane nodes), However, LinkID unambiguosly 
 identifies remote data plane node, and the need for the advertising of 
 Remote TE Router ID is not obvious
 
 BTW, You didn't answer the second question either.
 
 Igor
 
 PS, I have a suggestion for the working group: Let us disallow responding 
 to the comments/questions by just pointing to RFCs or drafts. In my view 
 it is quite unfriendly. It is always possible to cut and paste a piece 
 from the relevant RFC or draft confirming the points the writer is trying 
 to make.
 
 [email-masked] wrote:
 igor

 pls use version (or 03 
 when available to make comments)
 
 in that version you will see in Section 5.2
 
 " Note: The Link ID sub-TLV that identifies the other end of the link 
 (i.e. Router ID of the neighbor for point-to-point links) MUST 
 appear exactly once per Link TLV. This sub-TLV MUST be processed as 
 defined in [RFC3630]. "
 
 now why this sub-TLV 17, well for the reason explained at the beginning of 
 
 par.5.2
 but also in RFC 4652 Section 5.7
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 08/03/2007 22:11
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [email-masked], "Brungard, Deborah A, ALABS" 
 
 Subject: Two questions on 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

 Dimitri,
 I have a couple questions wrt the 
 draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
 In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
 local and remote TE Router ID:
 
 0 1 2 3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | 17 | Length | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | Local TE Router Identifier | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | Remote TE Router Identifier | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 Although I do understand why there is a need for advertising the Local TE 
 Router ID, I donâ€™t understand why the Remote Te Router ID? Isnâ€™t 
 this is 
 the same
 information 
 that is carried in the Link ID sub-TLV?
 In 6. you write:
 
 â€œA RA may contain smaller RAs inter-connected by links. 
 The limit of the subdivision results in
 a RA that contains two sub-networks interconnected by a single link.â€
 
 In G.8080 I read:
 â€œ.... A routing area is defined by a set of subnetworks, the SNPP links 
 
 that interconnect them, and the SNPPs representing the ends of the SNPP 
 links exiting that routing area. A routing area may contain smaller 
 routing areas interconnected by SNPP links. The limit of subdivision 
 results in a routing area that contains ]one subnetwork.â€
 
 Why is the discrepancy?
 
 Thanks,
 Igor

 [
 Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.

 Now that's room service! Choose from over 150,000 hotels 
 in 45,000 destinations on Yahoo! Travel to find your fit.

 
---------------------------------
Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.
--0-421440143-1173452702=:92923
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  <div class="MsoNormal">Dimitri,<o:p></o:p></div>  <div class="MsoNormal"><br> &gt; Is the LinkID is the same as Remote TE Router ID? <br> <br> no<br> <br> &gt; LinkID unambiguosly identifies remote data plane node,<br> <br> no, it identifies the remote RC not the remote data plane "node" in case <br> the remote RC is associate to n "nodes"<br> <br> IB&gt;&gt; No, I disagree. You see that's why it's so important to quote the RFCs/drafts, because people often interpret them differently.<br> <br> In RFC 3630 we read:<br> "<o:p></o:p></div>  <pre>2.5.2.<span style="">&nbsp; </span>Link ID<br><br><br><br><span style="">&nbsp;&nbsp; </span>The Link ID sub-TLV identifies the other end of the link.<span style="">&nbsp; </span>For<br><br><span style="">&nbsp;&nbsp; </span>point-to-point links, this is the Router ID of the neighbor.<br><br>"<br><br>Note that it does not say whether this is the advertising Router ID <br><br>(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it &#8220;identifies the other end of the link&#8221;. Because a link is terminated by TE nodes (and not advertising routers) I conclude that LinkID identifies the remote TE node.</pre><pre><o:p>&nbsp;</o:p></pre><pre>Furthermore, earlier in RFC 3630 we read:</pre><pre>&#8220;</pre><pre>2.4.1.<span style="">&nbsp; </span>Router Address TLV<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span style="">&nbsp;&nbsp; </span>The Router Address TLV specifies a stable IP address of the<o:p></o:p></pre><pre><span style="">&nbsp;&nbsp; </span>advertising router that is always reachable if there is any<o:p></o:p></pre><pre><span style="">&nbsp;&nbsp; </span>connectivity to it; this is typically implemented as a "loopback<o:p></o:p></pre><pre><span style="">&nbsp;&nbsp; </span>address".<span style="">&nbsp; </span>The key attribute is that the address does not become<o:p></o:p></pre><pre><span style="">&nbsp;&nbsp; </span>unusable if an
 interface is down.<span style="">&nbsp; </span>In other protocols, this is known<o:p></o:p></pre><pre><span style="">&nbsp;&nbsp; </span>as the "router ID"<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>I interpret that this is the same router ID as in the upper quote. It is advertised in the Router Address TLV, which is the only way today to advertise TE Router ID. Hence the router ID in the context of this RFC is the TE Router ID.</pre><pre><o:p>&nbsp;</o:p></pre><pre>The conclusion #1: the TE Link TLV, as it is today, always contains the ID of the remote TE node. </pre><pre><o:p>&nbsp;</o:p></pre><pre>The conclusion #2: there is a need to advertise several TE Router IDs supported by the same RC (advertising router), which, I think, should be proposed in your draft</pre><pre><o:p>&nbsp;</o:p></pre>  <div class="MsoNormal">ps: second question is trivial, mathematical vs networking formulation (no <br> real difference)</div>  <div
 class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">IB&gt;&gt; Well, it changes one of the fundamental definitions of G.8080, and I am asking why is that in the draft which is supposed to define ways to support G.8080 </div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Igor<br> <br> pps: if you want to put guidelines on e-mail responses probably directing <br> your e-mail to the GEN AREA would be more suitable <br> <br> hope this helps,<br> -d.<br> <br> <br> <br> <br> Igor Bryskin <br> <[email-masked]>09/03/2007 00:03<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [email-masked], "Brungard, Deborah A, ALABS" <br> <br> <[email-masked]>Subject: Re: Two questions on <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br> <br> <br> Dimitri, no, it does not help.<br> <br> You didn't answer the first question, which is:<br> <br> Is the LinkID is the same as Remote TE Router ID? If no, what is the <br>
 difference? If yes, why do you need the latter? Both your pointers explain <br> why do you need advertising of the local TE Router ID (advertising router <br> may cover multiple data plane nodes), However, LinkID unambiguosly <br> identifies remote data plane node, and the need for the advertising of <br> Remote TE Router ID is not obvious<br> <br> BTW, You didn't answer the second question either.<br> <br> Igor<br> <br> PS, I have a suggestion for the working group: Let us disallow responding <br> to the comments/questions by just pointing to RFCs or drafts. In my view <br> it is quite unfriendly. It is always possible to cut and paste a piece <br> from the relevant RFC or draft confirming the points the writer is trying <br> to make.<br> <br> [email-masked] wrote:<br> igor<br> <br> <br> pls use version (or 03 <br> when available to make comments)<br> <br> in that version you will see in Section 5.2<br> <br> " Note: The Link ID sub-TLV that
 identifies the other end of the link <br> (i.e. Router ID of the neighbor for point-to-point links) MUST <br> appear exactly once per Link TLV. This sub-TLV MUST be processed as <br> defined in [RFC3630]. "<br> <br> now why this sub-TLV 17, well for the reason explained at the beginning of <br> <br> par.5.2<br> but also in RFC 4652 Section 5.7<br> <br> hope this helps,<br> -d.<br> <br> <br> <br> <br> Igor Bryskin <br> 08/03/2007 22:11<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [email-masked], "Brungard, Deborah A, ALABS" <br> <br> Subject: Two questions on <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft<br> <br> <br> Dimitri,<br> I have a couple questions wrt the <br> draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br> In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br> local and remote TE Router ID:<br> <br> 0 1 2 3 <br> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | 17 | Length | <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | Local TE Router Identifier | <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> | Remote TE Router Identifier | <br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> <br> Although I do understand why there is a need for advertising the Local TE <br> Router ID, I donâ€™t understand why the Remote Te Router ID? Isnâ€™t <br> this is <br> the same<br> information <br> that is carried in the Link ID sub-TLV?<br> In 6. you write:<br> <br> â€œA RA may contain smaller RAs inter-connected by links. <br> The limit of the subdivision results in<br> a RA that contains two sub-networks interconnected by a single link.â€<br> <br> In G.8080 I read:<br> â€œ.... A routing area is defined by a set of subnetworks, the SNPP links <br> <br> that interconnect
 them, and the SNPPs representing the ends of the SNPP <br> links exiting that routing area. A routing area may contain smaller <br> routing areas interconnected by SNPP links. The limit of subdivision <br> results in a routing area that contains ]one subnetwork.â€<br> <br> Why is the discrepancy?<br> <br> Thanks,<br> Igor<br> <br> <br> [<br> Sucker-punch spam with award-winning protection.<br> Try the free Yahoo! Mail Beta.<br> <br> <br> Now that's room service! Choose from over 150,000 hotels <br> in 45,000 destinations on Yahoo! Travel to find your fit.<br> <br style=""> <!--[if !supportLineBreakNewLine]--><br style=""> <!--[endif]--><o:p></o:p></[email-masked]></[email-masked]></div>    <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <p>&#32;

<hr size=1><a href="
http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">Sucker-punch spam</a> with award-winning protection.<br> Try the <a href="
http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">free Yahoo! Mail Beta.</a>
--0-421440143-1173452702=:92923--

Delivery-date: Fri, 09 Mar 2007 06:54:30 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Fri, 9 Mar 2007 06:51:49 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Dimitri,
=20
> [email-masked]
> Sent: 08 March 2007 23:34
>=20
> igor=20
>=20
> "Hence, if we are to support Ethernet layer by GMPLS, we must=20
> consider=20
> mapping them on single bi-directional LSPs."
>=20
> this statement is fundamentally incorrect,
NH=3D> You are correct, but for a different reason that you seem to talk
about below.  GMPLS is a suite of control-plane protocols...a server
layer control-plane does not support/create client layer network
topology, it is the server layer *data-plane* that does that job.

I attempted to explain a few days ago why a p2p bidirectionally
congruent server layer *data-plane* construct is THE atomic building
block for client topology creation (any client)...and I tried to show an
example here from fault management (eg OAM, prot-sw) considerations why
this is important.  As a thought experiment try constructing a client
layer topology from anything other than p2p server layer building
blocks.

The way native cl-ps mode Ethernet works however makes this
(bidirectionally congruent server requirement) rather obvious/important
anyway IMO....which is the point Igor is making above, so he is actually
correct in this respect.  And this has nothing to do with whether one
uses a GMPLS control-plane in the server layer network or not, it is
only relevant to the server layer data-plane.

regards, Neil

> the association of control=20
> plane state to data plane state is independent on the Ethernet=20
> constraints,
> one may device control plane techniques that are=20
> facilitating=20
> operations but there are by no means reason to constrain the=20
> way nodes are=20
> performing such association
>=20
> as i wrote a couple of days ago
>=20
> "i am also reading that some Ethernet equipment are=20
> introducing several=20
> specific (data plane) constraints, indeed, but the control=20
> plane is not=20
> going to elevate those, in part.
> these constraints are=20
> independent whether=20
> one has unidirectional LSP, or asym bandwidth LSP=20
> provisioning capability=20
> at control plane level (adrian pointed this out numerous=20
> times but this is=20
> one of the cornerstone of the whole discussion)"
>=20
> -d.
>=20
>=20
>=20
>=20
>=20
>=20
> Igor Bryskin <[email-masked]>
> Sent by: [email-masked]
> 07/03/2007 15:34
> =20
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,=20
> Adrian Farrel=20
> <[email-masked]>
>         cc:     "Attila Takacs \(IJ/ETH\)"=20
> <[email-masked]>,=20
> [email-masked], Don Fedyk <[email-masked]>,=20
> [email-masked], "Pandian, Vijay"=20
> <[email-masked]>
>         Subject:        Re: What is this fate sharing thing? [Was:=20
> Questions on draft-takacs-asym-bw-lsp-00.txt]
>=20
>=20
> Dimitri.
>=20
> See in-line.
>=20
> [email-masked] wrote:
> adrian, all
>=20
> the point is not whether "We need asymmetrical bidirectional=20
> services" but "Do we have a clear requirement for=20
> asymmetrical bidirectional LSPs?"=20
>=20
> when i look at some of the examples that have been cited, it would=20
> surprise me that we would provision an LSP per micro-flow across the=20
> network (being Ethernet or whatever packet technology), even=20
> more, GMPLS=20
> is mostly used as an edge-to-edge technology in most cases,=20
> GMPLS capable=20
> devices do not even interact with the sources of traffic some where=20
> mentioning in their examples
>=20
> i am also reading that some Ethernet equipment are=20
> introducing several=20
> specific (data plane) constraints, indeed, but the control=20
> plane is not=20
> going to elevate those, in part. these constraints are=20
> independent whether=20
>=20
> one has unidirectional LSP, or asym bandwidth LSP=20
> provisioning capability=20
> at control plane level (adrian pointed this out numerous=20
> times but this is=20
>=20
> one of the cornerstone of the whole discussion)
>=20
> hence, the point since so far, is that they are no convincing=20
> argument in=20
> favor of an asymmetric LSP bandwidth provisioning WITHIN a single=20
> signaling exchange, indeed, most arguments are boiling down to=20
> hypothetical control plane efficiency that can be ensured by=20
> other means=20
> if we consider the restricting conditions where the proposed approach=20
> would be workable=20
>=20
>=20
> IB>> What Neil and Don are saying is that some signifficant Ethernet
> functionality will be lost if an Ethernet bi-directional=20
> service is mapped=20
> on non-congruent paths. This exactly coincides with what I=20
> hear from our=20
> local Ethernet experts. Hence, if we are to support Ethernet layer by=20
> GMPLS, we must consider mapping them on single bi-directional=20
> LSPs. This=20
> is not "hypothetical control plane efficiency" discussion.=20
> Bi-directional=20
> LSPs are as important in Ethernet as in TDM or optical=20
> layers. But I do=20
> agree with you that so far there were no convincing examples=20
> presented=20
> just yet that illustrate the need of bandwidth asymetrical services.=20
>=20
> Igor
>=20
> -d.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> "Adrian Farrel"=20
> Sent by: [email-masked]
> 06/03/2007 12:05
> Please respond to "Adrian Farrel"
>=20
> To: "Attila Takacs \(IJ/ETH\)" ,=20
> "Pandian, Vijay" , "Don Fedyk"=20
>=20
> cc:=20
> Subject: What is this fate sharing thing? [Was: Questions=20
> on draft-takacs-asym-bw-lsp-00.txt]
>=20
>=20
> Hi,
>=20
> There has been a lot of discussion about "fate-sharing" and I=20
> am not sure=20
> what problem we are trying to solve.
>=20
> - Is this a data plane feature where a data plane fault in=20
> one direction must cause data plane interruption in both directions?
>=20
> - Is this a protection feature where the switch-over of one=20
> direction to its backup path must be accompanied by a=20
> switch-over of the other direction, too?
>=20
> - Is this a control plane feature where the removal of=20
> control plane state in one direction must cause the removal=20
> of control plane state in the other direction?
>=20
> The use of a single control plane state (bidirectional signaling)=20
> obviously=20
> makes control plane fate-sharing automatic, but the use of associated=20
> signaling does not preclude control plane fate sharing - it=20
> just needs=20
> additional message exchanges.
>=20
> The use of an identical path for both directions can provide=20
> some elements=20
>=20
>=20
> of data plane fate sharing, but it is important to note that=20
> it does not=20
> guarantee it. For example, a unidirectional fiber could fail.=20
> This issue=20
> is=20
> not impacted by bidirectional or associated signaling as the=20
> directions=20
> can=20
> be installed on the path by associated signaling, and as a=20
> failure might=20
> only impact one direction in bidirectional signaling.
>=20
> End-to-end protection features are implemented at a different=20
> level and=20
> seem=20
> to be beyond this debate.
>=20
>=20
> So I am wondering what relevance fate-sharing has to the=20
> discussion of=20
> asymmetrical bandwidth. Maybe the discussion has reduced to:
> - We need asymmetrical bidirectional services
> - Does the value of a single signaling exchange outweigh the=20
> cost of new signaling objects and procedures?
>=20
> Adrian
>=20
> ----- Original Message -----=20
> From: "Attila Takacs (IJ/ETH)"=20
> To: "Pandian, Vijay" ; "Don Fedyk"=20
>=20
> Cc:=20
> Sent: Tuesday, March 06, 2007 10:34 AM
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay,
>=20
> let me answer this.
>=20
> If you need different protection for each direction then you=20
> likely will need differently routed LSPs. In this case one=20
> better uses separate sessions for the two directions since=20
> all the benefits of having a single session (like fate=20
> sharing) is gone if the LSPs take different routes. The ID=20
> only proposes to relax the symmetrical bandwidth property of=20
> the bidirectional LSP establishment given in RFC3471.
>=20
> Regards,
> Attila
>=20
> ________________________________
>=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [email-masked]
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
>=20
> Don,
>=20
> The question I had regarding P&R was trying to figure out if=20
> one direction required a better P&R (say 1+1) and the reverse=20
> direction probably required some basic P&R (say Re-routing).
>=20
> So the requirement is to use the same "physical link" for the=20
> forward and reverse direction. Am I right?
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [email-masked]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [email-masked]
> Subject: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi,
>=20
> I have some basic questions, primarily trying to
> understand the scope of this ID as well as the application=20
> behind such a requirement.
>=20
> 1. Does this ID address just an asymmetric
> Bandwidth requirement?
>=20
> The postulation was that GMPLS today supports
> bi-directional service with a single RSVP-TE session creating=20
> a bidirectional LSP. The most common implementation of this=20
> is Optical TDM networks. Since this was the starting point,=20
> the ID postulates setting up an asymmetric service with a=20
> single asymmetric LSP. (Like many new drafts it sets a=20
> requirement and postulates a an
> implementation.)
>=20
> So to your question besides bandwidth there is also
> underlying requirement to align with GMPLS single session=20
> procedures and support a bi-directional packet data plane as=20
> Ethernet does today. A single bidirectional (in this case=20
> asymmetric BW capable) LSP. In other words a single RSVP-TE=20
> session. Several people have pointed out this is also=20
> achievable with two unidirectional RSVP-TE sessions (one at=20
> each end). Rather than reopen that debate on this thread I=20
> will acknowledge the authors had a single session in mind=20
> more as a requirement of the technology. Ethernet data=20
> forwarding is bi-directional symmetric and there are=20
> efficiencies in a single session of a bi-directional LSP. On=20
> the other hand the issue is there is currently no way to=20
> specify the asymmetric BW. If you want to discuss the pros=20
> and cons of multiple sessions versus single there is already=20
> a thread on this (RE: I-D
> ACTION:draft-takacs-asym-bw-lsp-00.txt)
>=20
> | 2. How about other attributes? in particular LSP
> Protection & Recovery (P&R) related attributes?
>=20
> With respect to GMPLS, the plan was to allow
> bi-directional Protection or Recovery LSPs controlled by=20
> separate RSVP-TE sessions in separate from the single RSVP-TE=20
> session associated with the primary bidirectional LSP.
>=20
> 3. If P&R are indeed different, doesn't it make
> sense to route them separately (separate CSPF calculation at=20
> each end) and eventually signal them independently as well?
>=20
>=20
> Hopefully I addressed part of this already. Recovery of
> the bi-directional LSP could be handled by another RSVP-TE=20
> session & LSP. The data plane in our case must have a=20
> bi-directional symmetric path so you can only do a CSPF at=20
> one end and/or force the paths to align.
>=20
> 4. Is there a need for the forward and reverse
> flows to be on the same path?
>=20
>=20
> That is the way an Ethernet data plane works, and in my
> case this is where the requirement comes from. There is=20
> Ethernet data plane OAM and in some cases Ethernet forwarding=20
> rules that both require bi-directional symmetric paths. The=20
> requirement is to be able to support native Ethernet loopback=20
> and data plane trace functions and bi-directional symmetry in=20
> the data plane is required.
>=20
> 5. What is "fate sharing"? I couldn't find this
> in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
>=20
>=20
> Yes it is related. A shared resource link group
> identifies shared resources at some granularity. Fate shared=20
> paths have shared resources at a very high level of=20
> granularity. Disjoint paths have none or very few shared=20
> resources. For a bidirectional path the shared fate comes=20
> from the fact that both direction have common resources and=20
> if one fails the other is likely to fail.
>=20
> Regards,
> Don
>=20
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>  8:00? 8:25? 8:40? Find a flick in no time
> with theYahoo! Search movie showtime shortcut.
>=20
>=20
>=20

Delivery-date: Thu, 08 Mar 2007 23:35:13 +0000
To: Igor Bryskin <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>, [email-masked], "Pandian, Vijay" <[email-masked]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
From: [email-masked]
Date: Fri, 9 Mar 2007 00:34:13 +0100

igor 

"Hence, if we are to support Ethernet layer by GMPLS, we must consider 
mapping them on single bi-directional LSPs."

this statement is fundamentally incorrect, the association of control 
plane state to data plane state is independent on the Ethernet 
constraints, one may device control plane techniques that are facilitating 
operations but there are by no means reason to constrain the way nodes are 
performing such association

as i wrote a couple of days ago

"i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 
one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 
one of the cornerstone of the whole discussion)"

-d.

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
07/03/2007 15:34
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[email-masked]>
        cc:     "Attila Takacs \(IJ/ETH\)" <[email-masked]>, 
[email-masked], Don Fedyk <[email-masked]>, 
[email-masked], "Pandian, Vijay" <[email-masked]>
        Subject:        Re: What is this fate sharing thing? [Was: 
Questions on draft-takacs-asym-bw-lsp-00.txt]

Dimitri.

See in-line.

[email-masked] wrote:
adrian, all

the point is not whether "We need asymmetrical bidirectional services"
but "Do we have a clear requirement for asymmetrical bidirectional LSPs?" 

when i look at some of the examples that have been cited, it would 
surprise me that we would provision an LSP per micro-flow across the 
network (being Ethernet or whatever packet technology), even more, GMPLS 
is mostly used as an edge-to-edge technology in most cases, GMPLS capable 
devices do not even interact with the sources of traffic some where 
mentioning in their examples

i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 

one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 

one of the cornerstone of the whole discussion)

hence, the point since so far, is that they are no convincing argument in 
favor of an asymmetric LSP bandwidth provisioning WITHIN a single 
signaling exchange, indeed, most arguments are boiling down to 
hypothetical control plane efficiency that can be ensured by other means 
if we consider the restricting conditions where the proposed approach 
would be workable 

IB>> What Neil and Don are saying is that some signifficant Ethernet 
functionality will be lost if an Ethernet bi-directional service is mapped 
on non-congruent paths. This exactly coincides with what I hear from our 
local Ethernet experts. Hence, if we are to support Ethernet layer by 
GMPLS, we must consider mapping them on single bi-directional LSPs. This 
is not "hypothetical control plane efficiency" discussion. Bi-directional 
LSPs are as important in Ethernet as in TDM or optical layers. But I do 
agree with you that so far there were no convincing examples presented 
just yet that illustrate the need of bandwidth asymetrical services. 

Igor

-d.

"Adrian Farrel" 
Sent by: [email-masked]
06/03/2007 12:05
Please respond to "Adrian Farrel"

To: "Attila Takacs \(IJ/ETH\)" , 
"Pandian, Vijay" , "Don Fedyk" 

cc: 
Subject: What is this fate sharing thing? [Was: Questions 
on draft-takacs-asym-bw-lsp-00.txt]

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
direction to its backup path must be accompanied by a
switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
plane state in one direction must cause the removal of control
plane state in the other direction?

The use of a single control plane state (bidirectional signaling) 
obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 

of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue 
is 
not impacted by bidirectional or associated signaling as the directions 
can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and 
seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" 
To: "Pandian, Vijay" ; "Don Fedyk" 

Cc: 
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP. The most common implementation of this is Optical
TDM networks. Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP. (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today. A
single bidirectional (in this case asymmetric BW capable) LSP. In other
words a single RSVP-TE session. Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end). Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology. Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP. On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

| 2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP. The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths. The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related. A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity. Disjoint paths
have none or very few shared resources. For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

 8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.

Delivery-date: Thu, 08 Mar 2007 23:10:53 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
From: [email-masked]
Date: Fri, 9 Mar 2007 00:10:24 +0100

Delivery-date: Thu, 08 Mar 2007 23:05:29 +0000
Date: Thu, 8 Mar 2007 15:03:06 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>

--0-889844309-1173394986=:23655
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the difference? If yes, why do you need the latter? Both your pointers explain why do you need advertising of the local TE Router ID (advertising router may cover multiple data plane nodes), However, LinkID unambiguosly identifies remote data plane node, and the need for the advertising of Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding to the comments/questions by just pointing to RFCs or drafts. In my view it is quite unfriendly. It is always possible to cut and paste a piece from the relevant RFC or draft confirming the points the writer is trying to make.

[email-masked] wrote: igor

pls use version  (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
   (i.e. Router ID of the neighbor for point-to-point links) MUST 
   appear exactly once per Link TLV. This sub-TLV MUST be processed as 
   defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 
par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 

        Subject:        Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
 I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:
 
  0                   1                   2                   3 
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |              17               |             Length            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                 Local TE Router Identifier                    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                Remote TE Router Identifier                    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
Although I do understand why there is a need for advertising the Local TE 
Router ID, I don’t understand why the Remote Te Router ID? Isn’t this is 
the same
 information 
that is carried in the Link ID sub-TLV?
In 6. you write:
 
“A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
 a RA that contains two sub-networks interconnected by a single link.”
 
In G.8080 I read:
“.... A routing area is defined by a set of subnetworks, the SNPP links 
that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.”
 
Why is the discrepancy?
 
Thanks,
Igor

 [
 Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.

---------------------------------
Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.
--0-889844309-1173394986=:23655
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, no, it does not help.<br><br>You didn't answer the first question, which is:<br><br>Is the LinkID is the same as Remote TE Router ID? If no, what is the difference? If yes, why do you need the latter? Both your pointers explain why do you need advertising of the local TE Router ID (advertising router may cover multiple data plane nodes), However, LinkID unambiguosly identifies remote data plane node, and the need for the advertising of Remote TE Router ID is not obvious<br><br>BTW, You didn't answer the second question either.<br><br>Igor<br><br>PS, I have a suggestion for the working group: Let us disallow responding to the comments/questions by just pointing to RFCs or drafts. In my view it is quite unfriendly. It is always possible to cut and paste a piece from the relevant RFC or draft confirming the points the writer is trying to make.<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;"> igor<br><br><br>pls use version <draft-dimitri-ccamp-gmpls-ason-routing-ospf-02> (or 03 <br>when available to make comments)<br><br>in that version you will see in Section 5.2<br><br>" Note: The Link ID sub-TLV that identifies the other end of the link <br>   (i.e. Router ID of the neighbor for point-to-point links) MUST <br>   appear exactly once per Link TLV. This sub-TLV MUST be processed as <br>   defined in [RFC3630]. "<br><br>now why this sub-TLV 17, well for the reason explained at the beginning of <br>par.5.2<br>but also in RFC 4652 Section 5.7<br><br>hope this helps,<br>-d.<br><br><br><br><br>Igor Bryskin <[email-masked]><br>08/03/2007 22:11<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked], "Brungard, Deborah A, ALABS" <br><[email-masked]><br>        Subject:        Two questions on <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf
 draft<br><br><br>Dimitri,<br> I have a couple questions wrt the <br>draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.<br>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising <br>local and remote TE Router ID:<br> <br>  0                   1                   2                   3 <br>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>    |              17               |             Length            | <br>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>    |                 Local TE Router Identifier                    | <br>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>    |                Remote TE Router Identifier                    | <br>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br> <br>Although I do understand why there is a need for advertising the Local TE <br>Router ID,
 I don’t understand why the Remote Te Router ID? Isn’t this is <br>the same<br> information <br>that is carried in the Link ID sub-TLV?<br>In 6. you write:<br> <br>“A RA may contain smaller RAs inter-connected by links. <br>The limit of the subdivision results in<br> a RA that contains two sub-networks interconnected by a single link.”<br> <br>In G.8080 I read:<br>“.... A routing area is defined by a set of subnetworks, the SNPP links <br>that interconnect them, and the SNPPs representing the ends of the SNPP <br>links exiting that routing area. A routing area may contain smaller <br>routing areas interconnected by SNPP links. The limit of subdivision <br>results in a routing area that contains ]one subnetwork.”<br> <br>Why is the discrepancy?<br> <br>Thanks,<br>Igor<br> <br><br> [<br> Sucker-punch spam with award-winning protection.<br>Try the free Yahoo! Mail
 Beta.<br><br></[email-masked]></[email-masked]></draft-dimitri-ccamp-gmpls-ason-routing-ospf-02></blockquote><br><p>&#32;

<hr size=1>Now that's room service! <a href="http://travel.yahoo.com/hotelsearchpage;_ylc=X3oDMTFtaTIzNXVjBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzIEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--
">Choose from over 150,000 hotels <br>in 45,000 destinations on Yahoo! Travel</a> to find your fit.
--0-889844309-1173394986=:23655--

Delivery-date: Thu, 08 Mar 2007 21:24:03 +0000
To: Igor Bryskin <[email-masked]>
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
From: [email-masked]
Date: Thu, 8 Mar 2007 22:23:21 +0100

Delivery-date: Thu, 08 Mar 2007 21:13:11 +0000
Date: Thu, 8 Mar 2007 13:11:42 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [email-masked]
Cc: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>

--0-988701227-1173388302=:36530
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Dimitri,
   I have a couple questions wrt the draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
  
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising local and remote TE Router ID:

  0                   1                   2                   3 

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    |              17               |             Length            | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

    |                 Local TE Router Identifier                    | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    |                Remote TE Router Identifier                    | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE Router ID, I don�t understand why the Remote Te Router ID? Isn�t this is the same information 
that is carried in the Link ID sub-TLV?

In 6. you write:

�A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
 a RA that contains two sub-networks interconnected by a single link.�

In G.8080 I read:
  �.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains ]one subnetwork.�

Why is the discrepancy?

Thanks,

Igor

---------------------------------
         [

---------------------------------
Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.
--0-988701227-1173388302=:36530
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  <div class="MsoNormal">Dimitri,</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p>I have a couple questions wrt the draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.</div>  <pre>In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising local and remote TE Router ID:</pre><pre><o:p>&nbsp;</o:p></pre><pre><span style="">&nbsp; </span>0<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>1<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>2<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>3 <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <o:p></o:p></pre><pre><span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>17<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Length<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>| <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<span style="">&nbsp; </span><o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Local TE Router Identifier<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>| <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Remote TE Router Identifier<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>| <o:p></o:p></pre><pre><span style="">&nbsp;&nbsp;&nbsp;&nbsp;</span>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Although I do understand why there is a need for advertising the Local TE Router ID, I don�t understand why the Remote Te Router ID? Isn�t this is the same
 information <br>that is carried in the Link ID sub-TLV?</pre><pre>In 6. you write:</pre><pre><o:p>&nbsp;</o:p></pre><pre>�A RA may contain smaller RAs inter-connected by links. <br>The limit of the subdivision results in<br>&nbsp;a RA that contains two sub-networks interconnected by a single link.�</pre><pre><o:p>&nbsp;</o:p></pre><pre>In G.8080 I read:</pre>  <div class="MsoNormal">�.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains <span class="MsoCommentReference"><span style="font-size: 8pt;"><!--[if !supportAnnotations]--><a class="msocomanchor" id="_anchor_1" onmouseover="msoCommentShow('_anchor_1','_com_1')" onmouseout="msoCommentHide('_com_1')" href="#_msocom_1" language="JavaScript"
 name="_msoanchor_1">]</a><span style="display: none;"><span style=""></span></span></span></span><span style="color: rgb(51, 153, 102);">one</span> subnetwork.�</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <pre>Why is the discrepancy?</pre><pre><o:p>&nbsp;</o:p></pre><pre>Thanks,</pre><pre>Igor<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre>  <div style=""><!--[if !supportAnnotations]-->  <hr class="msocomoff" align="left" size="1" width="33%">  <!--[endif]-->  <div style=""><!--[if !supportAnnotations]-->  <div id="_com_1" class="msocomtxt" language="JavaScript" onmouseover="msoCommentShow('_anchor_1','_com_1')" onmouseout="msoCommentHide('_com_1')"><!--[endif]--><span style=""><!--[if !supportAnnotations]--><a name="_msocom_1"></a><!--[endif]--></span>  <div class="MsoCommentText"><span class="MsoCommentReference"><span style="font-size: 8pt;" lang="EN-GB"><span style="">&nbsp;<!--[if !supportAnnotations]--><a href="#_msoanchor_1"
 class="msocomoff">[</a></span></span></span><span lang="EN-GB"></span></div>  <!--[if !supportAnnotations]--></div>  <!--[endif]--></div>  </div>  <p>&#32;

<hr size=1><a href="
http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">Sucker-punch spam</a> with award-winning protection.<br> Try the <a href="
http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">free Yahoo! Mail Beta.</a>
--0-988701227-1173388302=:36530--

Delivery-date: Thu, 08 Mar 2007 16:55:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Draft agenda posted
Date: Thu, 8 Mar 2007 16:52:15 -0000
Organization: Old Dog Consulting

Hi,

One agenda file contains the agendas for both meetings.

http://www3.ietf.org/proceedings/07mar/agenda/ccamp.htm

Please comment.

Please send us your slides before the end of Friday 16th.

Adrian and Deborah

Delivery-date: Thu, 08 Mar 2007 07:06:35 +0000
Date: Thu, 08 Mar 2007 15:02:47 +0800
From: Dan Li <[email-masked]>
Subject: draft-li-ccamp-multinodes-gr-proc-01.txt
To: ccamp <[email-masked]>
Cc: "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian" <[email-masked]>, Arun Satyanarayana <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_UK/Vf7JRXnoLgeHKF5kHnQ)
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT

Dear CCAMPers, 

A revised version of the Procedure for Multiple Node Graceful Restart draft has been published:
http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt

Some changes are made based on the previous discussions: 
- MUST, SHOULD, etc. are replaced by must, should etc. to make sure this is an informational draft 
- Added the details of the single node GR procedure, try to widen the scope of applicability to single-node & multi-node
- Added Arun Satyanarayana as a co-author

Any comments and suggestions are greatly appreciated.

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_UK/Vf7JRXnoLgeHKF5kHnQ)
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>Dear CCAMPers, <BR><BR>A&nbsp;revised version of the Procedure for Multiple 
Node Graceful Restart draft has been published:<BR><A 
href="http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt">http://tools.ietf.org/wg/ccamp/draft-li-ccamp-multinodes-gr-proc-01.txt</A></DIV>
<DIV><BR>Some&nbsp;changes are made based on the previous 
discussions:&nbsp;<BR>-&nbsp;<SPAN lang=EN-US 
style="FONT-SIZE: 10.5pt; LAYOUT-GRID-MODE: line; LINE-HEIGHT: 150%; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: &#23435;&#20307;; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">MUST, 
SHOULD, etc. are replaced by must, should etc.&nbsp;to make&nbsp;sure this is an 
informational draft&nbsp;</SPAN><BR>- Added the details of the single node GR 
procedure, try to <SPAN lang=EN-US>widen the scope of applicability to 
single-node &amp; </SPAN><SPAN lang=EN-US 
style="FONT-SIZE: 10.5pt; LAYOUT-GRID-MODE: line; LINE-HEIGHT: 150%; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: &#23435;&#20307;; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">multi-node</SPAN></DIV>
<DIV>- Added Arun Satyanarayana as a co-author<BR><BR>Any comments and 
suggestions are&nbsp;greatly appreciated.<BR><BR>Regards,<BR></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_UK/Vf7JRXnoLgeHKF5kHnQ)--

Delivery-date: Thu, 08 Mar 2007 00:28:31 +0000
To: "Zafar Ali \(zali\)" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Jean Philippe Vasseur \(jvasseur\)" <[email-masked]>, [email-masked]
Subject: Re: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
From: [email-masked]
Date: Thu, 8 Mar 2007 01:28:05 +0100

zafar -

o) would it be possible to sum'up changes you have been provided 
since so far ?

o) would it be possible to clarify the following statement

"- Graceful shutdown mechanisms are required to address TE LSPs 
   spanning multiple domains, as well as intra domain TE LSPs. "

afaik you don't shutdown LSPs but Links - right ?

thanks,
-d.

"Zafar Ali \(zali\)" <[email-masked]>
Sent by: [email-masked]
02/03/2007 00:41
 
        To:     "Adrian Farrel" <[email-masked]>, "Brungard, Deborah 
A, ALABS" <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "Jean Philippe Vasseur \(jvasseur\)" 
<[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>
        Subject:        Next steps for 
draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....

Hi Adrian, Deborah, Dimitri, and campers- 
 
As we mentioned at the last IETF meeting, 
http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm, we have 
addressed all outstanding comments, except the following comment from 
Dimitri, related to this ID. Should you have any further comment, please 
share. 
 
The only remaining comment that is not closed is "should this ID be 
informational or standard track". IMO the ID defines a new error-subcode 
and some specific behavior, and should be standard track. Can you please 
comment on this. 
 
The ID has been stable for quite some time and following the closure of 
the above, we would like to request last call. 
 
Thanks
 
Regards... Zafar  

Delivery-date: Thu, 08 Mar 2007 00:28:23 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, [email-masked]
Subject: RE: New communication from the OIF
From: [email-masked]
Date: Thu, 8 Mar 2007 01:26:33 +0100

lyndon

o) first you will observe that the doc. MEF traffic parameters does not 
speak about "label distribution" 

reason: you will observe (by section 3.4 of RFC 3209) that label per 
sender (shared reservation or not) and label per link reservation 
(de-facto shared) are possible

hence the usage of RSVP-TE traffic parameters result also in using these 
rules (i will add a statement to make this clearer in the next release) 
but remember the doc does not define any "label" format for MEF purposes

o) second you will observe that the document does not infer any "VID" to 
EVC relationship, noticing that single CoS and multiple CoS per EVC are 
covered in the draft, and this, independently of the number of VIDs per 
EVC 

o) third closing the loop, the draft is not inferring any "label" to "VID" 
relationship (that relationship when equating an EVC with single or 
multiple CoS to an RSVP session is straightforward) 

the questions are thus the following

1. to which entity the traffic parameters are applied in case of a single 
EVC with multiple VIDs ? if you are following the reasoning since so far 
it should be per EVC (for the set of VIDs) 

note: per EVC+VID taken individually requires separate signaling otherwise 
you need a list of tspecs and a list of label + correspondance and this is 
another protocol, in fact boiling down to a simple relationship 

2. what is the "label" value(s) in this case ? using the set of VIDs to 
represent a "reservation" at the control plane level is completely useless 
as the control plane doesn't need this info to create PSB/RSB and the 
entity to which the reservation is associated is the "EVC" ... so you will 
need to find a unique per-EVC characteristic when the 1:1 relationship 
between label and EVC is limitative e.g. a bundle index or so (something 
that boils you down to a 1:1 relationship because indepedently of the 
"protocol" being explicit in the enumeration IS cumbersome)

 thanks,
-d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, 
"Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which 
causes a problem if you are 
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case 
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to 
understand how this would work - any solutions coming out of CCAMP would
be
very welcome. 

- not sure if there is an issue on point-to-multipoint, we were just
trying to 
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows based on the associated Ethernet labels, each with
some associated bandwidth.  The receiving node creates a corresponding
tunnel and aggregates these flows into the tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking with our MEF 'experts' on this), the originator requests
an EVC service, which has an associated bandwidth from one edge of the
network to another, and can support within it several Ethernet flows
that share this bandwidth.  If there are multiple EVCs, the originator
uses signaling to identify which labels should be carried in EVCx and
which should be carried in EVCy - if EVCx carries 200 Ethernet flows,
then you would need to identify 200 labels as belonging to EVCx.
However there is one transport requirement for the EVC, not one for each
flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs but in
the proposed cases i see more rationales to unbundle than bundle the
VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the VLAN
per customer the question is simple, are all customers specs identical
and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
====
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked], IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating large numbers of VLAN IDs in the Label objects in control
signaling messages for Ethernet connections with frame switching
granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Lyndon Ong,
OIF TC Vice Chair Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Wed, 07 Mar 2007 23:32:54 +0000
Content-class: urn:content-classes:message
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 18:28:50 -0500
From: "Ong, Lyndon" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which=20
causes a problem if you are=20
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case=20
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to=20
understand how this would work - any solutions coming out of CCAMP would
be
very welcome. =20

- not sure if there is an issue on point-to-multipoint, we were just
trying to=20
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]=20
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows based on the associated Ethernet labels, each with
some associated bandwidth.  The receiving node creates a corresponding
tunnel and aggregates these flows into the tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking with our MEF 'experts' on this), the originator requests
an EVC service, which has an associated bandwidth from one edge of the
network to another, and can support within it several Ethernet flows
that share this bandwidth.  If there are multiple EVCs, the originator
uses signaling to identify which labels should be carried in EVCx and
which should be carried in EVCy - if EVCx carries 200 Ethernet flows,
then you would need to identify 200 labels as belonging to EVCx.
However there is one transport requirement for the EVC, not one for each
flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs but in
the proposed cases i see more rationales to unbundle than bundle the
VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the VLAN
per customer the question is simple, are all customers specs identical
and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
=3D=3D=3D=3D
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked], IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating large numbers of VLAN IDs in the Label objects in control
signaling messages for Ethernet connections with frame switching
granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Lyndon Ong,
OIF TC Vice Chair Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Wed, 07 Mar 2007 22:29:48 +0000
Content-class: urn:content-classes:message
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 16:28:11 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows=20
based on the associated Ethernet labels, each with some associated
bandwidth.  The receiving=20
node creates a corresponding tunnel and aggregates these flows into the
tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking
with our MEF 'experts' on this), the originator requests an EVC service,
which has an=20
associated bandwidth from one edge of the network to another, and can
support within it
several Ethernet flows that share this bandwidth.  If there are multiple
EVCs, the=20
originator uses signaling to identify which labels should be carried in
EVCx and which
should be carried in EVCy - if EVCx carries 200 Ethernet flows, then you
would need to
identify 200 labels as belonging to EVCx.  However there is one
transport requirement
for the EVC, not one for each flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
=3D=3D=3D=3D
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked],
IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating
large numbers of VLAN IDs in the Label objects in control signaling
messages
for Ethernet connections with frame switching granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on
October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further
definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Wed, 07 Mar 2007 20:52:32 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-01.txt 
Date: Wed, 07 Mar 2007 15:50:04 -0500

--NextPart

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

	Title		: Traffic Engineering Database Management Information Base in support of GMPLS
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-ted-mib-01.txt
	Pages		: 23
	Date		: 2007-3-7
	
This memo defines the Management Information Base (MIB) objects in 
   order to manage traffic engineering database (TED) information with 
   extension in support of Multi-protocol label switching (MPLS) as well 
   as Generalized MPLS (GMPLS) for use with network management protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-01.txt

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-01.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 07 Mar 2007 17:46:36 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Wed, 7 Mar 2007 12:43:49 -0500
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pandian, Vijay" <[email-masked]>

Hi Dimitri=20

Inline [DF]

> -----Original Message-----
> From: [email-masked]=20
>=20
> adrian, all
>=20
> the point is not whether "We need asymmetrical bidirectional services"
> but "Do we have a clear requirement for asymmetrical=20
> bidirectional LSPs?"=20
[DF]  I agree.=20

>=20
> when i look at some of the examples that have been cited, it would=20
> surprise me that we would provision an LSP per micro-flow across the=20

> network (being Ethernet or whatever packet technology), even=20
> more, GMPLS=20
> is mostly used as an edge-to-edge technology in most cases,=20
> GMPLS capable=20
> devices do not even interact with the sources of traffic some where=20
> mentioning in their examples
[DF] Two points. The GMPLS for Ethernet Provider Backbone Bridges-TE is
hardly a micro flow but you are correct that at high bandwidth levels it
would likely be symmetric BW.=20

>=20
> i am also reading that some Ethernet equipment are=20
> introducing several=20
> specific (data plane) constraints, indeed, but the control=20
> plane is not=20
> going to elevate those, in part. these constraints are=20
> independent whether=20
> one has unidirectional LSP, or asym bandwidth LSP=20
> provisioning capability=20
> at control plane level (adrian pointed this out numerous=20
> times but this is=20
> one of the cornerstone of the whole discussion)

[DF] Sorry I'm missing your point here.=20
>=20
> hence, the point since so far, is that they are no convincing=20
> argument in=20
> favor of an asymmetric LSP bandwidth provisioning WITHIN a single=20
> signaling exchange, indeed, most arguments are boiling down to=20
> hypothetical control plane efficiency that can be ensured by=20
> other means=20
> if we consider the restricting conditions where the proposed approach=20
> would be workable=20

[DF] I don't agree on the efficiency point.  By any measure of
efficiency a single RSVP-TE session that handles both directions and
possibly different bandwidths is better that 2 that do 1/2 the job each.
If bandwidth is the same, in each direction today we don't need an
extension.  Igor gave a nice summary. =20

BTW I do believe that there will be an association object to correlate
at the very least primary and back-up bi-directional LSP.  I agree an
association object can manage 2 RSVP-TE uni-directional sessions for a
full bi-directional connection, and while there is some merit to not
extending current BW semantics there are also a set of new correlation
rules that have not been implemented.=20

So if we enumerate the GMPLS LSP building block possibilities I see:=20

Unidirectional LSP with BW (supported today by existing procedures)
- 1 RSVP-TE session=20

Symmetric BW bi-directional LSP (supported today by existing procedures)
- 1 RSVP-TE session can be used by existing GMPLS=20

Asymmetric BW bi-directional LSP (not yet defined).
- 2 Unidirectional LSPs with BW + an association object need to be used
plus a set of extensions to path correlation=20
OR=20
- 1 Symmetric BW bi-directional LSP can be used and no BW objects (many
MPLS TE sessions have no real BW in the control plane)
OR
- 1 Symmetric BW bi-directional LSP a bi-directional BW object.=20

Regards,
Don=20

>=20
> -d.
>=20
>=20
> =20
>=20
>=20
>=20
>=20
>=20
<snip>=20

Delivery-date: Wed, 07 Mar 2007 16:38:06 +0000
Content-class: urn:content-classes:message
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 11:35:41 -0500
From: "Ong, Lyndon" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows=20
based on the associated Ethernet labels, each with some associated
bandwidth.  The receiving=20
node creates a corresponding tunnel and aggregates these flows into the
tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking
with our MEF 'experts' on this), the originator requests an EVC service,
which has an=20
associated bandwidth from one edge of the network to another, and can
support within it
several Ethernet flows that share this bandwidth.  If there are multiple
EVCs, the=20
originator uses signaling to identify which labels should be carried in
EVCx and which
should be carried in EVCy - if EVCx carries 200 Ethernet flows, then you
would need to
identify 200 labels as belonging to EVCx.  However there is one
transport requirement
for the EVC, not one for each flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
=3D=3D=3D=3D
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked],
IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating
large numbers of VLAN IDs in the Label objects in control signaling
messages
for Ethernet connections with frame switching granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on
October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further
definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Wed, 07 Mar 2007 15:51:36 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-02.txt 
Date: Wed, 07 Mar 2007 10:50:02 -0500

--NextPart

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

	Title		: Graceful Shutdown in GMPLS Traffic Engineering Networks
	Author(s)	: Z. Ali, et al.
	Filename	: draft-ietf-ccamp-mpls-graceful-shutdown-02.txt
	Pages		: 9
	Date		: 2007-3-7
	
GMPLS-TE Graceful shutdown is a method for explicitly notifying 
   the nodes in a Traffic Engineering (TE) enabled network that the 
   TE capability on a link or on an entire Label Switching Router 
   (LSR) is going to be disabled. GMPLS-TE graceful shutdown 
   mechanisms are tailored towards addressing the planned outage in 
   the network.  
    
   This document provides requirements and protocol mechanisms so as 
   to reduce/eliminate traffic disruption in the event of a planned 
   shutdown of a network resource. These operations are equally 
   applicable for both MPLS and its GMPLS extensions.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-graceful-shutdown-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: Wed, 07 Mar 2007 14:37:03 +0000
Date: Wed, 7 Mar 2007 06:34:18 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>, [email-masked], "Pandian, Vijay" <[email-masked]>

--0-1027318012-1173278058=:50727
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri.

See in-line.

[email-masked] wrote: adrian, all

the point is not whether "We need asymmetrical bidirectional services"
but "Do we have a clear requirement for asymmetrical bidirectional LSPs?" 

when i look at some of the examples that have been cited, it would 
surprise me that we would provision an LSP per micro-flow across the 
network (being Ethernet or whatever packet technology), even more, GMPLS 
is mostly used as an edge-to-edge technology in most cases, GMPLS capable 
devices do not even interact with the sources of traffic some where 
mentioning in their examples

i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 
one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 
one of the cornerstone of the whole discussion)

hence, the point since so far, is that they are no convincing argument in 
favor of an asymmetric LSP bandwidth provisioning WITHIN a single 
signaling exchange, indeed, most arguments are boiling down to 
hypothetical control plane efficiency that can be ensured by other means 
if we consider the restricting conditions where the proposed approach 
would be workable 

IB>> What Neil and Don are saying is that some signifficant Ethernet functionality will be lost if an Ethernet bi-directional service is mapped on non-congruent paths. This exactly coincides with what I hear from our local Ethernet experts. Hence, if we are to support Ethernet layer by GMPLS, we must consider mapping them on single bi-directional LSPs. This is not "hypothetical control plane efficiency" discussion. Bi-directional LSPs are as important in Ethernet as in TDM or optical layers. But I do agree with you that so far there were no convincing examples presented just yet that illustrate the need of bandwidth asymetrical services. 

Igor

-d.

"Adrian Farrel" 
Sent by: [email-masked]
06/03/2007 12:05
Please respond to "Adrian Farrel"
 
        To:     "Attila Takacs \(IJ/ETH\)" , 
"Pandian, Vijay" , "Don Fedyk" 

        cc:     
        Subject:        What is this fate sharing thing? [Was: Questions 
on draft-takacs-asym-bw-lsp-00.txt]

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) 
obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 

of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue 
is 
not impacted by bidirectional or associated signaling as the directions 
can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and 
seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" 
To: "Pandian, Vijay" ; "Don Fedyk" 

Cc: 
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

---------------------------------
8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.
--0-1027318012-1173278058=:50727
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri.<br><br>See in-line.<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;"> adrian, all<br><br>the point is not whether "We need asymmetrical bidirectional services"<br>but "Do we have a clear requirement for asymmetrical bidirectional LSPs?" <br><br>when i look at some of the examples that have been cited, it would <br>surprise me that we would provision an LSP per micro-flow across the <br>network (being Ethernet or whatever packet technology), even more, GMPLS <br>is mostly used as an edge-to-edge technology in most cases, GMPLS capable <br>devices do not even interact with the sources of traffic some where <br>mentioning in their examples<br><br>i am also reading that some Ethernet equipment are introducing several <br>specific (data plane) constraints, indeed, but the control plane is not <br>going to elevate those, in part. these
 constraints are independent whether <br>one has unidirectional LSP, or asym bandwidth LSP provisioning capability <br>at control plane level (adrian pointed this out numerous times but this is <br>one of the cornerstone of the whole discussion)<br><br>hence, the point since so far, is that they are no convincing argument in <br>favor of an asymmetric LSP bandwidth provisioning WITHIN a single <br>signaling exchange, indeed, most arguments are boiling down to <br>hypothetical control plane efficiency that can be ensured by other means <br>if we consider the restricting conditions where the proposed approach <br>would be workable <br><br><br>IB&gt;&gt; What Neil and Don are saying is that some signifficant Ethernet functionality will be lost if an Ethernet bi-directional service is mapped on non-congruent paths. This exactly coincides with what I hear from our local Ethernet experts. Hence, if we are to support Ethernet layer by GMPLS, we must consider mapping them on single
 bi-directional LSPs. This is not "hypothetical control plane efficiency" discussion. Bi-directional LSPs are as important in Ethernet as in TDM or optical layers. But I do agree with you that so far there were no convincing examples presented just yet that illustrate the need of bandwidth asymetrical services. <br><br>Igor<br><br>-d.<br><br><br> <br><br><br><br><br><br>"Adrian Farrel" <[email-masked]><br>Sent by: [email-masked]<br>06/03/2007 12:05<br>Please respond to "Adrian Farrel"<br> <br>        To:     "Attila Takacs \(IJ/ETH\)" <[email-masked]>, <br>"Pandian, Vijay" <[email-masked]>, "Don Fedyk" <br><[email-masked]><br>        cc:     <[email-masked]><br>        Subject:        What is this fate sharing thing? [Was: Questions <br>on draft-takacs-asym-bw-lsp-00.txt]<br><br><br>Hi,<br><br>There has been a lot of discussion about "fate-sharing" and I am not sure <br>what problem we are trying to solve.<br><br>- Is this a
 data plane feature where a data plane fault in one<br>  direction must cause data plane interruption in both directions?<br><br>- Is this a protection feature where the switch-over of one<br>  direction to its backup path must be accompanied by a<br>  switch-over of the other direction, too?<br><br>- Is this a control plane feature where the removal of control<br>  plane state in one direction must cause the removal of control<br>  plane state in the other direction?<br><br>The use of a single control plane state (bidirectional signaling) <br>obviously <br>makes control plane fate-sharing automatic, but the use of associated <br>signaling does not preclude control plane fate sharing - it just needs <br>additional message exchanges.<br><br>The use of an identical path for both directions can provide some elements <br><br>of data plane fate sharing, but it is important to note that it does not <br>guarantee it. For example, a unidirectional fiber could fail. This issue
 <br>is <br>not impacted by bidirectional or associated signaling as the directions <br>can <br>be installed on the path by associated signaling, and as a failure might <br>only impact one direction in bidirectional signaling.<br><br>End-to-end protection features are implemented at a different level and <br>seem <br>to be beyond this debate.<br><br><br>So I am wondering what relevance fate-sharing has to the discussion of <br>asymmetrical bandwidth. Maybe the discussion has reduced to:<br>- We need asymmetrical bidirectional services<br>- Does the value of a single signaling exchange outweigh the<br>   cost of new signaling objects and procedures?<br><br>Adrian<br><br>----- Original Message ----- <br>From: "Attila Takacs (IJ/ETH)" <[email-masked]><br>To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" <br><[email-masked]><br>Cc: <[email-masked]><br>Sent: Tuesday, March 06, 2007 10:34 AM<br>Subject: RE: Questions on
 draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay,<br><br>let me answer this.<br><br>If you need different protection for each direction then you likely will<br>need differently routed LSPs. In this case one better uses separate<br>sessions for the two directions since all the benefits of having a<br>single session (like fate sharing) is gone if the LSPs take different<br>routes. The ID only proposes to relax the symmetrical bandwidth property<br>of the bidirectional LSP establishment given in RFC3471.<br><br>Regards,<br>Attila<br><br>________________________________<br><br>From: [email-masked] [mailto:[email-masked]] On<br>Behalf Of Pandian, Vijay<br>Sent: Tuesday, March 06, 2007 1:36 AM<br>To: Don Fedyk<br>Cc: [email-masked]<br>Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt<br><br><br><br>Don,<br><br>The question I had regarding P&amp;R was trying to figure out if one<br>direction required a better P&amp;R (say 1+1) and the reverse
 direction<br>probably required some basic P&amp;R (say Re-routing).<br><br>So the requirement is to use the same "physical link" for the<br>forward and reverse direction. Am I right?<br><br>Regards,<br><br>Vijay<br><br><br><br>-----Original Message-----<br>From: Don Fedyk [mailto:[email-masked]]<br>Sent: Monday, March 05, 2007 6:41 PM<br>To: Pandian, Vijay; [email-masked]<br>Subject: RE: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay<br><br><br>________________________________<br><br>From: [email-masked]<br>[mailto:[email-masked]] On Behalf Of Pandian, Vijay<br>Sent: Monday, March 05, 2007 2:07 PM<br>To: [email-masked]<br>Subject: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi,<br><br>I have some basic questions, primarily trying to<br>understand the scope of this ID as well as the application behind such a<br>requirement.<br><br>1. Does this ID address just an asymmetric<br>Bandwidth
 requirement?<br><br>The postulation was that GMPLS today supports<br>bi-directional service with a single RSVP-TE session creating a<br>bidirectional LSP.  The most common implementation of this is Optical<br>TDM networks.  Since this was the starting point, the ID postulates<br>setting up an asymmetric service with a single asymmetric LSP.  (Like<br>many new drafts it sets a requirement and postulates a an<br>implementation.)<br><br>So to your question besides bandwidth there is also<br>underlying requirement to align with GMPLS single session procedures and<br>support a bi-directional packet data plane as Ethernet does today.  A<br>single bidirectional (in this case asymmetric BW capable) LSP.  In other<br>words a single RSVP-TE session.  Several people have pointed out this is<br>also achievable with two unidirectional RSVP-TE sessions (one at each<br>end).  Rather than reopen that debate on this thread I will acknowledge<br>the authors had a single session in mind more
 as a requirement of the<br>technology.  Ethernet data forwarding is bi-directional symmetric and<br>there are efficiencies in a single session of a bi-directional LSP.  On<br>the other hand the issue is there is currently no way to specify the<br>asymmetric BW. If you want to discuss the pros and cons of multiple<br>sessions versus single there is already a thread on this (RE: I-D<br>ACTION:draft-takacs-asym-bw-lsp-00.txt)<br><br>|  2. How about other attributes? in particular LSP<br>Protection &amp; Recovery (P&amp;R) related attributes?<br><br>With respect to GMPLS, the plan was to allow<br>bi-directional Protection or Recovery LSPs controlled by separate<br>RSVP-TE sessions in separate from the single RSVP-TE session associated<br>with the primary bidirectional LSP.<br><br>3. If P&amp;R are indeed different, doesn't it make<br>sense to route them separately (separate CSPF calculation at each end)<br>and eventually signal them independently as well?<br><br><br>Hopefully
 I addressed part of this already. Recovery of<br>the bi-directional LSP could be handled by another RSVP-TE session &amp;<br>LSP.  The data plane in our case must have a bi-directional symmetric<br>path so you can only do a CSPF at one end and/or force the paths to<br>align.<br><br>4. Is there a need for the forward and reverse<br>flows to be on the same path?<br><br><br>That is the way an Ethernet data plane works, and in my<br>case this is where the requirement comes from. There is Ethernet data<br>plane OAM and in some cases Ethernet forwarding rules that both require<br>bi-directional symmetric paths.  The requirement is to be able to<br>support native Ethernet loopback and data plane trace functions and<br>bi-directional symmetry in the data plane is required.<br><br>5. What is "fate sharing"? I couldn't find this<br>in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?<br><br><br>Yes it is related.  A shared resource link group<br>identifies shared
 resources at some granularity. Fate shared paths have<br>shared resources at a very high level of granularity.  Disjoint paths<br>have none or very few shared resources.  For a bidirectional path the<br>shared fate comes from the fact that both direction have common<br>resources and if one fails the other is likely to fail.<br><br>Regards,<br>Don<br><br><br>Regards,<br><br>Vijay<br><br><br><br><br><br><br><br></[email-masked]></[email-masked]></[email-masked]></[email-masked]></[email-masked]></[email-masked]></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>8:00? 8:25? 8:40? <a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> Find a flick</a> in no time<br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search movie showtime shortcut.</a>
--0-1027318012-1173278058=:50727--

Delivery-date: Wed, 07 Mar 2007 07:08:21 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Wed, 7 Mar 2007 07:05:44 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

John....tend to agree with these points.  The only truly recursive
topological construct is p2p.....one can almost consider this as THE
topological atomic building block of hierarchy (ie a client/server layer
network relationship).  This becomes quite evident when we consider the
fact that a link connection in layer network N is provided by a trail in
layer network N-1...a relationship which is clearly recursive across a
stack of nested layer networks.

Now a p2mp construct (like a p2p construct) is also a connection (Note -
A trail is specific p2p relationship, so in a p2mp connection a trail
exists between the root and each leaf).  However mp2p and mp2mp
constructs are not connections.

As previously noted, one can only recursively construct topology with a
p2p connection. So if we want to create p2mp connections (and we will)
these should only exist at the very top of a network stack in the
context of a some service instance, ie we cannot use p2mp connections
(and certainly not mp2p and mp2mp constructs) for recursive topology
creation.

Why is this important?=20

Well, its all about deterministic resource assignment and
management....and this plays through to a whole raft of practical
considerations (eg OAM/fault management, performance/SLAs, etc) that
should be important to operators and their customers (which can be other
operators).  The key point about a connection is that it must only have
a single source and no internal routing once created....this is
essentially a definition of a connection, and it comes from information
theory considerations of resource determinism.  Connections do not
(obviously) exist in the cl-ps mode. In the co-cs mode connections can
be created using time (eg SDH/PDH), freq (eg WDM) and space (eg per
fibre) dimension resource partitions.  In the co-ps mode connections can
only be practically created by resource partitioning of the time
dimension.  Note that the key difference between the co-cs and co-ps
mode in the time dimension is one of regular or irregular (respectively)
partitioning of resource.  What this essentially means is that labelling
and resource assignment are coupled/fixed processes and always
deterministic in the co-cs mode but not in the co-ps mode.  This has
many immediate practical consequences too, eg one can't create mp2p
constructs in the co-cs mode but one can in the co-ps mode.

Aside=3D> A practical consideration (but not axiomatic to its =
definition)
is that once created a connection is only consciously moved by (i) a
customer request (most obvious for SVC case), (ii) from failures (eg
prot-sw) or (iii) by premeditated planned works.  Counter example:  If
we add nodes/links to a cl-ps mode network than traffic can move at will
under the routing rules of the IGP, but this is not true (or should not
be true) in co-ps and co-cs mode networks....nothing intrinsically wrong
with that, its purely a function of the connection object and how this
must be defined wrt BOTH labelling and resource assignment
considerations.  And a key point to grasp in all this is that the 3
network modes are quite different and it is folly to try and treat them
all identically alike.

Now, the above was what I was hinting at in my last mail to Igor wrt to
the point about the binding of CV OAM messages (forward
defect-detection) and BDI OAM messages (backward defect-detection
indication) for fault management.  It's quite an important point, and
its why in a client/server relationship for creating topology we require
congruent bidirectional routings of the symmetric atomic p2p connection
building block.

regards, Neil

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: 06 March 2007 22:24
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: What is this fate sharing thing? [Was: Questions=20
> on draft-takacs-asym-bw-lsp-00.txt]
>=20
>=20
> Dimitri,
>=20
> I think you're absolutely right.  Furthermore, this=20
> application seems to be a natural for LSP hierarchy, where=20
> there would be a containing symmetric bi-directional LSP with=20
> contained asymmetric uni-directional LSPs.  The latter would=20
> be correlated with the Association object.
>=20
> This would give you fate sharing and fast recovery via the=20
> re-instantiation of the containing LSP, and reasonable=20
> control plane performance, since the contained LSP signaling=20
> is only between the containing LSP endpoints.
>=20
> Thanks,
>=20
> John=20
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]=20
> > Sent: Tuesday, March 06, 2007 1:45 PM
> > To: Adrian Farrel
> > Cc: Attila Takacs (IJ/ETH); [email-masked]; Don Fedyk;=20
> > [email-masked]; Pandian, Vijay
> > Subject: Re: What is this fate sharing thing? [Was: Questions=20
> > on draft-takacs-asym-bw-lsp-00.txt]
> >=20
> > adrian, all
> >=20
> > the point is not whether "We need asymmetrical=20
> bidirectional services"=20
> > but "Do we have a clear requirement for asymmetrical bidirectional=20
> > LSPs?"
> >=20
> > when i look at some of the examples that have been cited, it
> > would surprise me that we would provision an LSP per=20
> > micro-flow across the network (being Ethernet or whatever=20
> > packet technology), even more, GMPLS is mostly used as an=20
> > edge-to-edge technology in most cases, GMPLS capable devices=20
> > do not even interact with the sources of traffic some where=20
> > mentioning in their examples
> >=20
> > i am also reading that some Ethernet equipment are
> > introducing several specific (data plane) constraints,=20
> > indeed, but the control plane is not going to elevate those,=20
> > in part. these constraints are independent whether one has=20
> > unidirectional LSP, or asym bandwidth LSP provisioning=20
> > capability at control plane level (adrian pointed this out=20
> > numerous times but this is one of the cornerstone of the=20
> > whole discussion)
> >=20
> > hence, the point since so far, is that they are no convincing
> > argument in favor of an asymmetric LSP bandwidth provisioning=20
> > WITHIN a single signaling exchange, indeed, most arguments=20
> > are boiling down to hypothetical control plane efficiency=20
> > that can be ensured by other means if we consider the=20
> > restricting conditions where the proposed approach would be=20
> workable=20
> >=20
> > -d.
> >=20
> >=20
> > =20
> >=20
> >=20
> >=20
> >=20
> >=20
> > "Adrian Farrel" <[email-masked]>
> > Sent by: [email-masked]
> > 06/03/2007 12:05
> > Please respond to "Adrian Farrel"
> > =20
> >         To:     "Attila Takacs \(IJ/ETH\)"=20
> > <[email-masked]>,
> > "Pandian, Vijay" <[email-masked]>, "Don Fedyk"=20
> > <[email-masked]>
> >         cc:     <[email-masked]>
> >         Subject:        What is this fate sharing thing?=20
> > [Was: Questions=20
> > on draft-takacs-asym-bw-lsp-00.txt]
> >=20
> >=20
> > Hi,
> >=20
> > There has been a lot of discussion about "fate-sharing" and I
> > am not sure what problem we are trying to solve.
> >=20
> > - Is this a data plane feature where a data plane fault in one
> >   direction must cause data plane interruption in both directions?
> >=20
> > - Is this a protection feature where the switch-over of one
> >   direction to its backup path must be accompanied by a
> >   switch-over of the other direction, too?
> >=20
> > - Is this a control plane feature where the removal of control
> >   plane state in one direction must cause the removal of control
> >   plane state in the other direction?
> >=20
> > The use of a single control plane state (bidirectional
> > signaling) obviously makes control plane fate-sharing=20
> > automatic, but the use of associated signaling does not=20
> > preclude control plane fate sharing - it just needs=20
> > additional message exchanges.
> >=20
> > The use of an identical path for both directions can provide
> > some elements=20
> >=20
> > of data plane fate sharing, but it is important to note that
> > it does not guarantee it. For example, a unidirectional fiber=20
> > could fail. This issue is not impacted by bidirectional or=20
> > associated signaling as the directions can be installed on=20
> > the path by associated signaling, and as a failure might only=20
> > impact one direction in bidirectional signaling.
> >=20
> > End-to-end protection features are implemented at a different
> > level and seem to be beyond this debate.
> >=20
> >=20
> > So I am wondering what relevance fate-sharing has to the
> > discussion of asymmetrical bandwidth. Maybe the discussion=20
> > has reduced to:
> > - We need asymmetrical bidirectional services
> > - Does the value of a single signaling exchange outweigh the
> >    cost of new signaling objects and procedures?
> >=20
> > Adrian
> >=20
> > From: "Attila Takacs (IJ/ETH)" <[email-masked]>
> > To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk"
> > <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Tuesday, March 06, 2007 10:34 AM
> > Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
> >=20
> >=20
> > Hi Vijay,
> >=20
> > let me answer this.
> >=20
> > If you need different protection for each direction then you
> > likely will
> > need differently routed LSPs. In this case one better uses separate
> > sessions for the two directions since all the benefits of having a
> > single session (like fate sharing) is gone if the LSPs take=20
> different
> > routes. The ID only proposes to relax the symmetrical=20
> > bandwidth property
> > of the bidirectional LSP establishment given in RFC3471.
> >=20
> > Regards,
> > Attila
> >=20
> > ________________________________
> >=20
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of Pandian, Vijay
> > Sent: Tuesday, March 06, 2007 1:36 AM
> > To: Don Fedyk
> > Cc: [email-masked]
> > Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
> >=20
> >=20
> >=20
> > Don,
> >=20
> > The question I had regarding P&R was trying to figure out if one=20
> > direction required a better P&R (say 1+1) and the reverse direction=20
> > probably required some basic P&R (say Re-routing).
> >=20
> > So the requirement is to use the same "physical link" for=20
> the forward=20
> > and reverse direction. Am I right?
> >=20
> > Regards,
> >=20
> > Vijay
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: Don Fedyk [mailto:[email-masked]]
> > Sent: Monday, March 05, 2007 6:41 PM
> > To: Pandian, Vijay; [email-masked]
> > Subject: RE: Questions on
> > draft-takacs-asym-bw-lsp-00.txt
> >=20
> >=20
> > Hi Vijay
> >=20
> >=20
> > ________________________________
> >=20
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of Pandian, Vijay
> > Sent: Monday, March 05, 2007 2:07 PM
> > To: [email-masked]
> > Subject: Questions on
> > draft-takacs-asym-bw-lsp-00.txt
> >=20
> >=20
> > Hi,
> >=20
> > I have some basic questions, primarily trying to
> > understand the scope of this ID as well as the application
> > behind such a
> > requirement.
> >=20
> > 1. Does this ID address just an asymmetric
> > Bandwidth requirement?
> >=20
> > The postulation was that GMPLS today supports
> > bi-directional service with a single RSVP-TE session creating a=20
> > bidirectional LSP.  The most common implementation of this=20
> is Optical=20
> > TDM networks.  Since this was the starting point, the ID postulates=20
> > setting up an asymmetric service with a single asymmetric=20
> LSP.  (Like=20
> > many new drafts it sets a requirement and postulates a an
> > implementation.)
> >=20
> > So to your question besides bandwidth there is also underlying=20
> > requirement to align with GMPLS single session procedures and
> > support a bi-directional packet data plane as Ethernet does=20
> today.  A
> > single bidirectional (in this case asymmetric BW capable)=20
> > LSP.  In other
> > words a single RSVP-TE session.  Several people have pointed=20
> > out this is
> > also achievable with two unidirectional RSVP-TE sessions=20
> (one at each
> > end).  Rather than reopen that debate on this thread I will=20
> > acknowledge
> > the authors had a single session in mind more as a=20
> requirement of the
> > technology.  Ethernet data forwarding is bi-directional=20
> symmetric and
> > there are efficiencies in a single session of a=20
> > bi-directional LSP.  On
> > the other hand the issue is there is currently no way to specify the
> > asymmetric BW. If you want to discuss the pros and cons of multiple
> > sessions versus single there is already a thread on this (RE: I-D
> > ACTION:draft-takacs-asym-bw-lsp-00.txt)
> >=20
> > |  2. How about other attributes? in particular LSP
> > Protection & Recovery (P&R) related attributes?
> >=20
> > With respect to GMPLS, the plan was to allow
> > bi-directional Protection or Recovery LSPs controlled by separate=20
> > RSVP-TE sessions in separate from the single RSVP-TE session=20
> > associated with the primary bidirectional LSP.
> >=20
> > 3. If P&R are indeed different, doesn't it make
> > sense to route them separately (separate CSPF calculation=20
> at each end)=20
> > and eventually signal them independently as well?
> >=20
> >=20
> > Hopefully I addressed part of this already. Recovery of
> > the bi-directional LSP could be handled by another RSVP-TE=20
> session &=20
> > LSP.  The data plane in our case must have a bi-directional=20
> symmetric=20
> > path so you can only do a CSPF at one end and/or force the paths to=20
> > align.
> >=20
> > 4. Is there a need for the forward and reverse
> > flows to be on the same path?
> >=20
> >=20
> > That is the way an Ethernet data plane works, and in my
> > case this is where the requirement comes from. There is=20
> Ethernet data=20
> > plane OAM and in some cases Ethernet forwarding rules that both=20
> > require bi-directional symmetric paths.  The requirement is=20
> to be able=20
> > to support native Ethernet loopback and data plane trace=20
> functions and
> > bi-directional symmetry in the data plane is required.
> >=20
> > 5. What is "fate sharing"? I couldn't find this
> > in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
> >=20
> >=20
> > Yes it is related.  A shared resource link group
> > identifies shared resources at some granularity. Fate shared
> > paths have
> > shared resources at a very high level of granularity. =20
> Disjoint paths
> > have none or very few shared resources.  For a=20
> bidirectional path the
> > shared fate comes from the fact that both direction have common
> > resources and if one fails the other is likely to fail.
> >=20
> > Regards,
> > Don
> >=20
> >=20
> > Regards,
> >=20
> > Vijay
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Tue, 06 Mar 2007 22:25:15 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 14:24:06 -0800
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

Dimitri,

I think you're absolutely right.  Furthermore, this application seems to
be a natural for LSP hierarchy, where there would be a containing
symmetric bi-directional LSP with contained asymmetric uni-directional
LSPs.  The latter would be correlated with the Association object.

This would give you fate sharing and fast recovery via the
re-instantiation of the containing LSP, and reasonable control plane
performance, since the contained LSP signaling is only between the
containing LSP endpoints.

Thanks,

John=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]=20
> Sent: Tuesday, March 06, 2007 1:45 PM
> To: Adrian Farrel
> Cc: Attila Takacs (IJ/ETH); [email-masked]; Don Fedyk;=20
> [email-masked]; Pandian, Vijay
> Subject: Re: What is this fate sharing thing? [Was: Questions=20
> on draft-takacs-asym-bw-lsp-00.txt]
>=20
> adrian, all
>=20
> the point is not whether "We need asymmetrical bidirectional services"
> but "Do we have a clear requirement for asymmetrical=20
> bidirectional LSPs?"=20
>=20
> when i look at some of the examples that have been cited, it=20
> would surprise me that we would provision an LSP per=20
> micro-flow across the network (being Ethernet or whatever=20
> packet technology), even more, GMPLS is mostly used as an=20
> edge-to-edge technology in most cases, GMPLS capable devices=20
> do not even interact with the sources of traffic some where=20
> mentioning in their examples
>=20
> i am also reading that some Ethernet equipment are=20
> introducing several specific (data plane) constraints,=20
> indeed, but the control plane is not going to elevate those,=20
> in part. these constraints are independent whether one has=20
> unidirectional LSP, or asym bandwidth LSP provisioning=20
> capability at control plane level (adrian pointed this out=20
> numerous times but this is one of the cornerstone of the=20
> whole discussion)
>=20
> hence, the point since so far, is that they are no convincing=20
> argument in favor of an asymmetric LSP bandwidth provisioning=20
> WITHIN a single signaling exchange, indeed, most arguments=20
> are boiling down to hypothetical control plane efficiency=20
> that can be ensured by other means if we consider the=20
> restricting conditions where the proposed approach would be workable=20
>=20
> -d.
>=20
>=20
> =20
>=20
>=20
>=20
>=20
>=20
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 06/03/2007 12:05
> Please respond to "Adrian Farrel"
> =20
>         To:     "Attila Takacs \(IJ/ETH\)"=20
> <[email-masked]>,=20
> "Pandian, Vijay" <[email-masked]>, "Don Fedyk"=20
> <[email-masked]>
>         cc:     <[email-masked]>
>         Subject:        What is this fate sharing thing?=20
> [Was: Questions=20
> on draft-takacs-asym-bw-lsp-00.txt]
>=20
>=20
> Hi,
>=20
> There has been a lot of discussion about "fate-sharing" and I=20
> am not sure what problem we are trying to solve.
>=20
> - Is this a data plane feature where a data plane fault in one
>   direction must cause data plane interruption in both directions?
>=20
> - Is this a protection feature where the switch-over of one
>   direction to its backup path must be accompanied by a
>   switch-over of the other direction, too?
>=20
> - Is this a control plane feature where the removal of control
>   plane state in one direction must cause the removal of control
>   plane state in the other direction?
>=20
> The use of a single control plane state (bidirectional=20
> signaling) obviously makes control plane fate-sharing=20
> automatic, but the use of associated signaling does not=20
> preclude control plane fate sharing - it just needs=20
> additional message exchanges.
>=20
> The use of an identical path for both directions can provide=20
> some elements=20
>=20
> of data plane fate sharing, but it is important to note that=20
> it does not guarantee it. For example, a unidirectional fiber=20
> could fail. This issue is not impacted by bidirectional or=20
> associated signaling as the directions can be installed on=20
> the path by associated signaling, and as a failure might only=20
> impact one direction in bidirectional signaling.
>=20
> End-to-end protection features are implemented at a different=20
> level and seem to be beyond this debate.
>=20
>=20
> So I am wondering what relevance fate-sharing has to the=20
> discussion of asymmetrical bandwidth. Maybe the discussion=20
> has reduced to:
> - We need asymmetrical bidirectional services
> - Does the value of a single signaling exchange outweigh the
>    cost of new signaling objects and procedures?
>=20
> Adrian
>=20
> From: "Attila Takacs (IJ/ETH)" <[email-masked]>
> To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk"=20
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, March 06, 2007 10:34 AM
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay,
>=20
> let me answer this.
>=20
> If you need different protection for each direction then you=20
> likely will
> need differently routed LSPs. In this case one better uses separate
> sessions for the two directions since all the benefits of having a
> single session (like fate sharing) is gone if the LSPs take different
> routes. The ID only proposes to relax the symmetrical=20
> bandwidth property
> of the bidirectional LSP establishment given in RFC3471.
>=20
> Regards,
> Attila
>=20
> ________________________________
>=20
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [email-masked]
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
>=20
> Don,
>=20
> The question I had regarding P&R was trying to figure out if one
> direction required a better P&R (say 1+1) and the reverse direction
> probably required some basic P&R (say Re-routing).
>=20
> So the requirement is to use the same "physical link" for the
> forward and reverse direction. Am I right?
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [email-masked]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [email-masked]
> Subject: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi,
>=20
> I have some basic questions, primarily trying to
> understand the scope of this ID as well as the application=20
> behind such a
> requirement.
>=20
> 1. Does this ID address just an asymmetric
> Bandwidth requirement?
>=20
> The postulation was that GMPLS today supports
> bi-directional service with a single RSVP-TE session creating a
> bidirectional LSP.  The most common implementation of this is Optical
> TDM networks.  Since this was the starting point, the ID postulates
> setting up an asymmetric service with a single asymmetric LSP.  (Like
> many new drafts it sets a requirement and postulates a an
> implementation.)
>=20
> So to your question besides bandwidth there is also
> underlying requirement to align with GMPLS single session=20
> procedures and
> support a bi-directional packet data plane as Ethernet does today.  A
> single bidirectional (in this case asymmetric BW capable)=20
> LSP.  In other
> words a single RSVP-TE session.  Several people have pointed=20
> out this is
> also achievable with two unidirectional RSVP-TE sessions (one at each
> end).  Rather than reopen that debate on this thread I will=20
> acknowledge
> the authors had a single session in mind more as a requirement of the
> technology.  Ethernet data forwarding is bi-directional symmetric and
> there are efficiencies in a single session of a=20
> bi-directional LSP.  On
> the other hand the issue is there is currently no way to specify the
> asymmetric BW. If you want to discuss the pros and cons of multiple
> sessions versus single there is already a thread on this (RE: I-D
> ACTION:draft-takacs-asym-bw-lsp-00.txt)
>=20
> |  2. How about other attributes? in particular LSP
> Protection & Recovery (P&R) related attributes?
>=20
> With respect to GMPLS, the plan was to allow
> bi-directional Protection or Recovery LSPs controlled by separate
> RSVP-TE sessions in separate from the single RSVP-TE session=20
> associated
> with the primary bidirectional LSP.
>=20
> 3. If P&R are indeed different, doesn't it make
> sense to route them separately (separate CSPF calculation at each end)
> and eventually signal them independently as well?
>=20
>=20
> Hopefully I addressed part of this already. Recovery of
> the bi-directional LSP could be handled by another RSVP-TE session &
> LSP.  The data plane in our case must have a bi-directional symmetric
> path so you can only do a CSPF at one end and/or force the paths to
> align.
>=20
> 4. Is there a need for the forward and reverse
> flows to be on the same path?
>=20
>=20
> That is the way an Ethernet data plane works, and in my
> case this is where the requirement comes from. There is Ethernet data
> plane OAM and in some cases Ethernet forwarding rules that=20
> both require
> bi-directional symmetric paths.  The requirement is to be able to
> support native Ethernet loopback and data plane trace functions and
> bi-directional symmetry in the data plane is required.
>=20
> 5. What is "fate sharing"? I couldn't find this
> in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
>=20
>=20
> Yes it is related.  A shared resource link group
> identifies shared resources at some granularity. Fate shared=20
> paths have
> shared resources at a very high level of granularity.  Disjoint paths
> have none or very few shared resources.  For a bidirectional path the
> shared fate comes from the fact that both direction have common
> resources and if one fails the other is likely to fail.
>=20
> Regards,
> Don
>=20
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Tue, 06 Mar 2007 21:46:14 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, [email-masked], "Don Fedyk" <[email-masked]>, [email-masked], "Pandian, Vijay" <[email-masked]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
From: [email-masked]
Date: Tue, 6 Mar 2007 22:44:40 +0100

adrian, all

the point is not whether "We need asymmetrical bidirectional services"
but "Do we have a clear requirement for asymmetrical bidirectional LSPs?" 

when i look at some of the examples that have been cited, it would 
surprise me that we would provision an LSP per micro-flow across the 
network (being Ethernet or whatever packet technology), even more, GMPLS 
is mostly used as an edge-to-edge technology in most cases, GMPLS capable 
devices do not even interact with the sources of traffic some where 
mentioning in their examples

i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 
one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 
one of the cornerstone of the whole discussion)

hence, the point since so far, is that they are no convincing argument in 
favor of an asymmetric LSP bandwidth provisioning WITHIN a single 
signaling exchange, indeed, most arguments are boiling down to 
hypothetical control plane efficiency that can be ensured by other means 
if we consider the restricting conditions where the proposed approach 
would be workable 

-d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
06/03/2007 12:05
Please respond to "Adrian Farrel"
 
        To:     "Attila Takacs \(IJ/ETH\)" <[email-masked]>, 
"Pandian, Vijay" <[email-masked]>, "Don Fedyk" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        What is this fate sharing thing? [Was: Questions 
on draft-takacs-asym-bw-lsp-00.txt]

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) 
obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 

of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue 
is 
not impacted by bidirectional or associated signaling as the directions 
can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and 
seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

Delivery-date: Tue, 06 Mar 2007 19:49:47 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 20:48:13 +0100
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76028.60F99471
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Igor,
=20
I think the point is on flexibility. If bandwidth is available with fine
granularity one can leverage this in many cases. To add a new example:
central office - branch office connectivity, in this scenario it seems
to be likely to have the same recovery...etc requirements but different
bw needs for up/down streams.
=20
Regarding "fate sharing", as you specified, it depends on how one
defines "a strong use case"...one may use diversely routed LSPs as well
to provide bidirectional connection for, e.g., the above service, but
with co routed LSPs issues may become simpler (like management, CP
states, OAM,...).=20
=20
Regards,
Attila

________________________________

	From: Igor Bryskin [mailto:[email-masked]]=20
	Sent: Tuesday, March 06, 2007 4:52 PM
	To: Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don
Fedyk
	Cc: [email-masked]
	Subject: Re: What is this fate sharing thing? [Was: Questions on
draft-takacs-asym-bw-lsp-00.txt]
=09
=09
	Adrian,
=09
	I would define "fate sharing" very simply: it is the situation
when both directions go through the same links at any time: after setup,
protection switchover, recovery, reroute, etc. In control plane the
bidirectional service where opposite directions fate-share we have some
nice by-products:
	a) CP states for both directions could be always combined
together with the summary state reduced in size;
	b) the management of both directions can be accomplished using a
single exchange of signaling messages, This holds for initial setup,
protection switchover, recovery, re-route
	c) number of RSVP refreshes also is half as much
=09
	My understanding is that we do like the notion of a symmetrical
bidirectional LSP in a packet switched network layer.  This is a (I'd
say big) reason why we want to migrate from MPLS to GMPLS, and you.
Adrian, I believe is still a big advocate of such migration. So, we
don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM
ACCEPTABLE LABEL SET).
=09
	I have just one question to the authors of the draft: do we have
a strong use case for a bidirectional service requiring the fate sharing
(as I defined it above) of both directions and fully symmetrical
(recovery requirements, colors, etc) apart from the bandwidth
requirements? If the answer is yes, than I say I don't mind a copule of
extra signaling objects.
=09
	Igor
=09
=09
	Adrian Farrel <[email-masked]> wrote:=20

		Hi,
	=09
		There has been a lot of discussion about "fate-sharing"
and I am not sure=20
		what problem we are trying to solve.
	=09
		- Is this a data plane feature where a data plane fault
in one
		direction must cause data plane interruption in both
directions?
	=09
		- Is this a protection feature where the switch-over of
one
		direction to its backup path must be accompanied by a
		switch-over of the other direction, too?
	=09
		- Is this a control plane feature where the removal of
control
		plane state in one direction must cause the removal of
control
		plane state in the other direction?
	=09
		The use of a single control plane state (bidirectional
signaling) obviously=20
		makes control plane fate-sharing automatic, but the use
of associated=20
		signaling does not preclude control plane fate sharing -
it just needs=20
		additional message exchanges.
	=09
		The use of an identical path for both directions can
provide some elements=20
		of data plane fate sharing, but it is important to note
that it does not=20
		guarantee it. For example, a unidirectional fiber could
fail. This issue is=20
		not impacted by bidirectional or associated signaling as
the directions can=20
		be installed on the path by associated signaling, and as
a failure might=20
		only impact one direction in bidirectional signaling.
	=09
		End-to-end protection features are implemented at a
different level and seem=20
		to be beyond this debate.
	=09
	=09
		So I am wondering what relevance fate-sharing has to the
discussion of=20
		asymmetrical bandwidth. Maybe the discussion has reduced
to:
		- We need asymmetrical bidirectional services
		- Does the value of a single signaling exchange outweigh
the
		cost of new signaling objects and procedures?
	=09
		Adrian
	=09
		----- Original Message -----=20
		From: "Attila Takacs (IJ/ETH)"=20
		To: "Pandian, Vijay" ; "Don Fedyk"=20
	=09
		Cc:=20
		Sent: Tuesday, March 06, 2007 10:34 AM
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay,
	=09
		let me answer this.
	=09
		If you need different protection for each direction then
you likely will
		need differently routed LSPs. In this case one better
uses separate
		sessions for the two directions since all the benefits
of having a
		single session (like fate sharing) is gone if the LSPs
take different
		routes. The ID only proposes to relax the symmetrical
bandwidth property
		of the bidirectional LSP establishment given in RFC3471.
	=09
		Regards,
		Attila
	=09
		________________________________
	=09
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Pandian, Vijay
		Sent: Tuesday, March 06, 2007 1:36 AM
		To: Don Fedyk
		Cc: [email-masked]
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
	=09
		Don,
	=09
		The question I had regarding P&R was trying to figure
out if one
		direction required a better P&R (say 1+1) and the
reverse direction
		probably required some basic P&R (say Re-routing).
	=09
		So the requirement is to use the same "physical link"
for the
		forward and reverse direction. Am I right?
	=09
		Regards,
	=09
		Vijay
	=09
	=09
	=09
		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay
	=09
	=09
		________________________________
	=09
		From: [email-masked]
		[mailto:[email-masked]] On Behalf Of Pandian,
Vijay
		Sent: Monday, March 05, 2007 2:07 PM
		To: [email-masked]
		Subject: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi,
	=09
		I have some basic questions, primarily trying to
		understand the scope of this ID as well as the
application behind such a
		requirement.
	=09
		1. Does this ID address just an asymmetric
		Bandwidth requirement?
	=09
		The postulation was that GMPLS today supports
		bi-directional service with a single RSVP-TE session
creating a
		bidirectional LSP. The most common implementation of
this is Optical
		TDM networks. Since this was the starting point, the ID
postulates
		setting up an asymmetric service with a single
asymmetric LSP. (Like
		many new drafts it sets a requirement and postulates a
an
		implementation.)
	=09
		So to your question besides bandwidth there is also
		underlying requirement to align with GMPLS single
session procedures and
		support a bi-directional packet data plane as Ethernet
does today. A
		single bidirectional (in this case asymmetric BW
capable) LSP. In other
		words a single RSVP-TE session. Several people have
pointed out this is
		also achievable with two unidirectional RSVP-TE sessions
(one at each
		end). Rather than reopen that debate on this thread I
will acknowledge
		the authors had a single session in mind more as a
requirement of the
		technology. Ethernet data forwarding is bi-directional
symmetric and
		there are efficiencies in a single session of a
bi-directional LSP. On
		the other hand the issue is there is currently no way to
specify the
		asymmetric BW. If you want to discuss the pros and cons
of multiple
		sessions versus single there is already a thread on this
(RE: I-D
		ACTION:draft-takacs-asym-bw-lsp-00.txt)
	=09
		| 2. How about other attributes? in particular LSP
		Protection & Recovery (P&R) related attributes?
	=09
		With respect to GMPLS, the plan was to allow
		bi-directional Protection or Recovery LSPs controlled by
separate
		RSVP-TE sessions in separate from the single RSVP-TE
session associated
		with the primary bidirectional LSP.
	=09
		3. If P&R are indeed different, doesn't it make
		sense to route them separately (separate CSPF
calculation at each end)
		and eventually signal them independently as well?
	=09
	=09
		Hopefully I addressed part of this already. Recovery of
		the bi-directional LSP could be handled by another
RSVP-TE session &
		LSP. The data plane in our case must have a
bi-directional symmetric
		path so you can only do a CSPF at one end and/or force
the paths to
		align.
	=09
		4. Is there a need for the forward and reverse
		flows to be on the same path?
	=09
	=09
		That is the way an Ethernet data plane works, and in my
		case this is where the requirement comes from. There is
Ethernet data
		plane OAM and in some cases Ethernet forwarding rules
that both require
		bi-directional symmetric paths. The requirement is to be
able to
		support native Ethernet loopback and data plane trace
functions and
		bi-directional symmetry in the data plane is required.
	=09
		5. What is "fate sharing"? I couldn't find this
		in other RFCs or IDs. Is it same as link/node/SRLG
disjoint paths?
	=09
	=09
		Yes it is related. A shared resource link group
		identifies shared resources at some granularity. Fate
shared paths have
		shared resources at a very high level of granularity.
Disjoint paths
		have none or very few shared resources. For a
bidirectional path the
		shared fate comes from the fact that both direction have
common
		resources and if one fails the other is likely to fail.
	=09
		Regards,
		Don
	=09
	=09
		Regards,
	=09
		Vijay
	=09
	=09
	=09
	=09
	=09

=09
________________________________

	Don't get soaked. Take a quick peak at the forecast
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news>=20
	with theYahoo! Search weather shortcut.
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news>=20

------_=_NextPart_001_01C76028.60F99471
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=3D269174218-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Igor,</FONT></SPAN></DIV>
<DIV><SPAN class=3D269174218-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D269174218-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think the point is on flexibility. If bandwidth is available with fine=20
granularity&nbsp;one can leverage this in many cases. To add a new =
example:=20
central office - branch office connectivity, in this&nbsp;scenario it=20
seems&nbsp;to be likely to have the same recovery...etc requirements but =

different bw needs for up/down streams.</FONT></SPAN></DIV>
<DIV><SPAN class=3D269174218-06032007><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Regarding "fate sharing", as you specified, it depends on how =
one defines=20
"a strong use case"...one may use diversely routed&nbsp;LSPs as well to =
provide=20
bidirectional connection for, e.g., the above service, but with co =
routed LSPs=20
issues may become simpler (like management, CP states, OAM,...).=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D269174218-06032007></SPAN><SPAN =
class=3D269174218-06032007><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D269174218-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D269174218-06032007><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> Igor Bryskin=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, March 06, 2007 =
4:52=20
  PM<BR><B>To:</B> Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, =
Vijay; Don=20
  Fedyk<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> Re: What is =
this=20
  fate sharing thing? [Was: Questions on=20
  draft-takacs-asym-bw-lsp-00.txt]<BR></FONT><BR></DIV>
  <DIV></DIV>Adrian,<BR><BR>I would define "fate sharing" very simply: =
it is the=20
  situation when both directions go through the same links at any time: =
after=20
  setup, protection switchover, recovery, reroute, etc. In control plane =
the=20
  bidirectional service where opposite directions fate-share we have =
some nice=20
  by-products:<BR>a) CP states for both directions could be always =
combined=20
  together with the summary state reduced in size;<BR>b) the management =
of both=20
  directions can be accomplished using a single exchange of signaling =
messages,=20
  This holds for initial setup, protection switchover, recovery, =
re-route<BR>c)=20
  number of RSVP refreshes also is half as much<BR><BR>My understanding =
is that=20
  we do like the notion of a symmetrical bidirectional LSP in a packet =
switched=20
  network layer.&nbsp; This is a (I'd say big) reason why we want to =
migrate=20
  from MPLS to GMPLS, and you. Adrian, I believe is still a big advocate =
of such=20
  migration. So, we don't mind an extra complexity (such as UPSTREAM =
LABEL,=20
  UPSTREAM ACCEPTABLE LABEL SET).<BR><BR>I have just one question to the =
authors=20
  of the draft: do we have a strong use case for a bidirectional service =

  requiring the fate sharing (as I defined it above) of both directions =
and=20
  fully symmetrical (recovery requirements, colors, etc) apart from the=20
  bandwidth requirements? If the answer is yes, than I say I don't mind =
a copule=20
  of extra signaling objects.<BR><BR>Igor<BR><BR><BR><B><I>Adrian Farrel =

  &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">Hi,<BR><BR>There=20
    has been a lot of discussion about "fate-sharing" and I am not sure =
<BR>what=20
    problem we are trying to solve.<BR><BR>- Is this a data plane =
feature where=20
    a data plane fault in one<BR>direction must cause data plane =
interruption in=20
    both directions?<BR><BR>- Is this a protection feature where the =
switch-over=20
    of one<BR>direction to its backup path must be accompanied by=20
    a<BR>switch-over of the other direction, too?<BR><BR>- Is this a =
control=20
    plane feature where the removal of control<BR>plane state in one =
direction=20
    must cause the removal of control<BR>plane state in the other=20
    direction?<BR><BR>The use of a single control plane state =
(bidirectional=20
    signaling) obviously <BR>makes control plane fate-sharing automatic, =
but the=20
    use of associated <BR>signaling does not preclude control plane fate =
sharing=20
    - it just needs <BR>additional message exchanges.<BR><BR>The use of =
an=20
    identical path for both directions can provide some elements <BR>of =
data=20
    plane fate sharing, but it is important to note that it does not=20
    <BR>guarantee it. For example, a unidirectional fiber could fail. =
This issue=20
    is <BR>not impacted by bidirectional or associated signaling as the=20
    directions can <BR>be installed on the path by associated signaling, =
and as=20
    a failure might <BR>only impact one direction in bidirectional=20
    signaling.<BR><BR>End-to-end protection features are implemented at =
a=20
    different level and seem <BR>to be beyond this debate.<BR><BR><BR>So =
I am=20
    wondering what relevance fate-sharing has to the discussion of=20
    <BR>asymmetrical bandwidth. Maybe the discussion has reduced =
to:<BR>- We=20
    need asymmetrical bidirectional services<BR>- Does the value of a =
single=20
    signaling exchange outweigh the<BR>cost of new signaling objects and =

    procedures?<BR><BR>Adrian<BR><BR>----- Original Message ----- =
<BR>From:=20
    "Attila Takacs (IJ/ETH)" <[email-masked]><BR>To: =
"Pandian,=20
    Vijay" <[email-masked]>; "Don Fedyk"=20
    <BR><[email-masked]><BR>Cc: <[email-masked]><BR>Sent: =
Tuesday, March=20
    06, 2007 10:34 AM<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi Vijay,<BR><BR>let me =
answer=20
    this.<BR><BR>If you need different protection for each direction =
then you=20
    likely will<BR>need differently routed LSPs. In this case one better =
uses=20
    separate<BR>sessions for the two directions since all the benefits =
of having=20
    a<BR>single session (like fate sharing) is gone if the LSPs take=20
    different<BR>routes. The ID only proposes to relax the symmetrical =
bandwidth=20
    property<BR>of the bidirectional LSP establishment given in=20
    =
RFC3471.<BR><BR>Regards,<BR>Attila<BR><BR>_______________________________=
_<BR><BR>From:=20
    [email-masked] [mailto:[email-masked]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [email-masked]<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR><BR>Don,<BR><BR>The =
question I=20
    had regarding P&amp;R was trying to figure out if one<BR>direction =
required=20
    a better P&amp;R (say 1+1) and the reverse direction<BR>probably =
required=20
    some basic P&amp;R (say Re-routing).<BR><BR>So the requirement is to =
use the=20
    same "physical link" for the<BR>forward and reverse direction. Am I=20
    right?<BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR><BR>-----Original=20
    Message-----<BR>From: Don Fedyk [mailto:[email-masked]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[email-masked]<BR>Subject:=20
    RE: Questions on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi=20
    Vijay<BR><BR><BR>________________________________<BR><BR>From:=20
    [email-masked]<BR>[mailto:[email-masked]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [email-masked]<BR>Subject: Questions=20
    on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi,<BR><BR>I have =
some=20
    basic questions, primarily trying to<BR>understand the scope of this =
ID as=20
    well as the application behind such a<BR>requirement.<BR><BR>1. Does =
this ID=20
    address just an asymmetric<BR>Bandwidth requirement?<BR><BR>The =
postulation=20
    was that GMPLS today supports<BR>bi-directional service with a =
single=20
    RSVP-TE session creating a<BR>bidirectional LSP. The most common=20
    implementation of this is Optical<BR>TDM networks. Since this was =
the=20
    starting point, the ID postulates<BR>setting up an asymmetric =
service with a=20
    single asymmetric LSP. (Like<BR>many new drafts it sets a =
requirement and=20
    postulates a an<BR>implementation.)<BR><BR>So to your question =
besides=20
    bandwidth there is also<BR>underlying requirement to align with =
GMPLS single=20
    session procedures and<BR>support a bi-directional packet data plane =
as=20
    Ethernet does today. A<BR>single bidirectional (in this case =
asymmetric BW=20
    capable) LSP. In other<BR>words a single RSVP-TE session. Several =
people=20
    have pointed out this is<BR>also achievable with two unidirectional =
RSVP-TE=20
    sessions (one at each<BR>end). Rather than reopen that debate on =
this thread=20
    I will acknowledge<BR>the authors had a single session in mind more =
as a=20
    requirement of the<BR>technology. Ethernet data forwarding is =
bi-directional=20
    symmetric and<BR>there are efficiencies in a single session of a=20
    bi-directional LSP. On<BR>the other hand the issue is there is =
currently no=20
    way to specify the<BR>asymmetric BW. If you want to discuss the pros =
and=20
    cons of multiple<BR>sessions versus single there is already a thread =
on this=20
    (RE: I-D<BR>ACTION:draft-takacs-asym-bw-lsp-00.txt)<BR><BR>| 2. How =
about=20
    other attributes? in particular LSP<BR>Protection &amp; Recovery =
(P&amp;R)=20
    related attributes?<BR><BR>With respect to GMPLS, the plan was to=20
    allow<BR>bi-directional Protection or Recovery LSPs controlled by=20
    separate<BR>RSVP-TE sessions in separate from the single RSVP-TE =
session=20
    associated<BR>with the primary bidirectional LSP.<BR><BR>3. If =
P&amp;R are=20
    indeed different, doesn't it make<BR>sense to route them separately=20
    (separate CSPF calculation at each end)<BR>and eventually signal =
them=20
    independently as well?<BR><BR><BR>Hopefully I addressed part of this =

    already. Recovery of<BR>the bi-directional LSP could be handled by =
another=20
    RSVP-TE session &amp;<BR>LSP. The data plane in our case must have a =

    bi-directional symmetric<BR>path so you can only do a CSPF at one =
end and/or=20
    force the paths to<BR>align.<BR><BR>4. Is there a need for the =
forward and=20
    reverse<BR>flows to be on the same path?<BR><BR><BR>That is the way =
an=20
    Ethernet data plane works, and in my<BR>case this is where the =
requirement=20
    comes from. There is Ethernet data<BR>plane OAM and in some cases =
Ethernet=20
    forwarding rules that both require<BR>bi-directional symmetric =
paths. The=20
    requirement is to be able to<BR>support native Ethernet loopback and =
data=20
    plane trace functions and<BR>bi-directional symmetry in the data =
plane is=20
    required.<BR><BR>5. What is "fate sharing"? I couldn't find =
this<BR>in other=20
    RFCs or IDs. Is it same as link/node/SRLG disjoint =
paths?<BR><BR><BR>Yes it=20
    is related. A shared resource link group<BR>identifies shared =
resources at=20
    some granularity. Fate shared paths have<BR>shared resources at a =
very high=20
    level of granularity. Disjoint paths<BR>have none or very few shared =

    resources. For a bidirectional path the<BR>shared fate comes from =
the fact=20
    that both direction have common<BR>resources and if one fails the =
other is=20
    likely to=20
    =
fail.<BR><BR>Regards,<BR>Don<BR><BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR>=
<BR><BR></[email-masked]></[email-masked]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[email-masked]></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  Don't get soaked. Take a<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">=20
  quick peak at the forecast </A><BR>with the<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">Yahoo!=20
  Search weather shortcut.</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C76028.60F99471--

Delivery-date: Tue, 06 Mar 2007 17:39:01 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 12:37:14 -0500
From: "Don Fedyk" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76016.148731CC
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Igor
=20
Good points.  Comments in line.

________________________________

	From: Igor Bryskin [mailto:[email-masked]]=20
	Sent: Tuesday, March 06, 2007 10:52 AM
=09
=09
	Adrian,
=09
	I would define "fate sharing" very simply: it is the situation
when both directions go through the same links at any time: after setup,
protection switchover, recovery, reroute, etc. In control plane the
bidirectional service where opposite directions fate-share we have some
nice by-products:=20
	=20
	=20

In Ethernet Bridging the "fate sharing" object is the to the level of
ports on the bridge relay.  Both direction of the path must pass through
the Bridge relay. There may be link aggregation functions below this. So
I would adjust your definition slightly to include same "link objects".

	=20
	=20
	a) CP states for both directions could be always combined
together with the summary state reduced in size;
	b) the management of both directions can be accomplished using a
single exchange of signaling messages, This holds for initial setup,
protection switchover, recovery, re-route
	c) number of RSVP refreshes also is half as much
=09
	My understanding is that we do like the notion of a symmetrical
bidirectional LSP in a packet switched network layer.  This is a (I'd
say big) reason why we want to migrate from MPLS to GMPLS, and you.
Adrian, I believe is still a big advocate of such migration. So, we
don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM
ACCEPTABLE LABEL SET).
=09
	I have just one question to the authors of the draft: do we have
a strong use case for a bidirectional service requiring the fate sharing
(as I defined it above) of both directions and fully symmetrical
(recovery requirements, colors, etc) apart from the bandwidth
requirements? If the answer is yes, than I say I don't mind a copule of
extra signaling objects.=20
	=20

We have a draft for GMPLS control of Ethernet PBB-TE which is an
emerging L2 data plane.  The Ethernet bridge relay function assumes
bi-directionality. Ethernet data plane OAM is built on the
bi-directional relay.   IMHO in that context the answer to your question
is yes.   =20
=20
In fact I think the requirement for asymmetrical BW is just related to
the fact we have a packet technology. (MPLS is no different).=20
The need for bi-directional fate sharing is from the requirements of the
Ethernet Bridging Relay and our desire to leverage the Relay
capabilities (this packet layer is different). =20
The use case cited for this requirement is the distribution of packet
Video which may well be high BW in one direction and relatively small in
the other but even my Internet connection is asymmetric today and I
don't use it for video. So the use case applies to all kinds of of
packet transport.=20
=20
Regards,
Don=20

=09
	Igor
=09
=09
	Adrian Farrel <[email-masked]> wrote:

		Hi,
	=09
		There has been a lot of discussion about "fate-sharing"
and I am not sure=20
		what problem we are trying to solve.
	=09
		- Is this a data plane feature where a data plane fault
in one
		direction must cause data plane interruption in both
directions?
	=09
		- Is this a protection feature where the switch-over of
one
		direction to its backup path must be accompanied by a
		switch-over of the other direction, too?
	=09
		- Is this a control plane feature where the removal of
control
		plane state in one direction must cause the removal of
control
		plane state in the other direction?
	=09
		The use of a single control plane state (bidirectional
signaling) obviously=20
		makes control plane fate-sharing automatic, but the use
of associated=20
		signaling does not preclude control plane fate sharing -
it just needs=20
		additional message exchanges.
	=09
		The use of an identical path for both directions can
provide some elements=20
		of data plane fate sharing, but it is important to note
that it does not=20
		guarantee it. For example, a unidirectional fiber could
fail. This issue is=20
		not impacted by bidirectional or associated signaling as
the directions can=20
		be installed on the path by associated signaling, and as
a failure might=20
		only impact one direction in bidirectional signaling.
	=09
		End-to-end protection features are implemented at a
different level and seem=20
		to be beyond this debate.
	=09
	=09
		So I am wondering what relevance fate-sharing has to the
discussion of=20
		asymmetrical bandwidth. Maybe the discussion has reduced
to:
		- We need asymmetrical bidirectional services
		- Does the value of a single signaling exchange outweigh
the
		cost of new signaling objects and procedures?
	=09
		Adrian
	=09
		----- Original Message -----=20
		From: "Attila Takacs (IJ/ETH)"=20
		To: "Pandian, Vijay" ; "Don Fedyk"=20
	=09
		Cc:=20
		Sent: Tuesday, March 06, 2007 10:34 AM
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay,
	=09
		let me answer this.
	=09
		If you need different protection for each direction then
you likely will
		need differently routed LSPs. In this case one better
uses separate
		sessions for the two directions since all the benefits
of having a
		single session (like fate sharing) is gone if the LSPs
take different
		routes. The ID only proposes to relax the symmetrical
bandwidth property
		of the bidirectional LSP establishment given in RFC3471.
	=09
		Regards,
		Attila
	=09
		________________________________
	=09
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Pandian, Vijay
		Sent: Tuesday, March 06, 2007 1:36 AM
		To: Don Fedyk
		Cc: [email-masked]
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
	=09
		Don,
	=09
		The question I had regarding P&R was trying to figure
out if one
		direction required a better P&R (say 1+1) and the
reverse direction
		probably required some basic P&R (say Re-routing).
	=09
		So the requirement is to use the same "physical link"
for the
		forward and reverse direction. Am I right?
	=09
		Regards,
	=09
		Vijay
	=09
	=09
	=09
		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay
	=09
	=09
		________________________________
	=09
		From: [email-masked]
		[mailto:[email-masked]] On Behalf Of Pandian,
Vijay
		Sent: Monday, March 05, 2007 2:07 PM
		To: [email-masked]
		Subject: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi,
	=09
		I have some basic questions, primarily trying to
		understand the scope of this ID as well as the
application behind such a
		requirement.
	=09
		1. Does this ID address just an asymmetric
		Bandwidth requirement?
	=09
		The postulation was that GMPLS today supports
		bi-directional service with a single RSVP-TE session
creating a
		bidirectional LSP. The most common implementation of
this is Optical
		TDM networks. Since this was the starting point, the ID
postulates
		setting up an asymmetric service with a single
asymmetric LSP. (Like
		many new drafts it sets a requirement and postulates a
an
		implementation.)
	=09
		So to your question besides bandwidth there is also
		underlying requirement to align with GMPLS single
session procedures and
		support a bi-directional packet data plane as Ethernet
does today. A
		single bidirectional (in this case asymmetric BW
capable) LSP. In other
		words a single RSVP-TE session. Several people have
pointed out this is
		also achievable with two unidirectional RSVP-TE sessions
(one at each
		end). Rather than reopen that debate on this thread I
will acknowledge
		the authors had a single session in mind more as a
requirement of the
		technology. Ethernet data forwarding is bi-directional
symmetric and
		there are efficiencies in a single session of a
bi-directional LSP. On
		the other hand the issue is there is currently no way to
specify the
		asymmetric BW. If you want to discuss the pros and cons
of multiple
		sessions versus single there is already a thread on this
(RE: I-D
		ACTION:draft-takacs-asym-bw-lsp-00.txt)
	=09
		| 2. How about other attributes? in particular LSP
		Protection & Recovery (P&R) related attributes?
	=09
		With respect to GMPLS, the plan was to allow
		bi-directional Protection or Recovery LSPs controlled by
separate
		RSVP-TE sessions in separate from the single RSVP-TE
session associated
		with the primary bidirectional LSP.
	=09
		3. If P&R are indeed different, doesn't it make
		sense to route them separately (separate CSPF
calculation at each end)
		and eventually signal them independently as well?
	=09
	=09
		Hopefully I addressed part of this already. Recovery of
		the bi-directional LSP could be handled by another
RSVP-TE session &
		LSP. The data plane in our case must have a
bi-directional symmetric
		path so you can only do a CSPF at one end and/or force
the paths to
		align.
	=09
		4. Is there a need for the forward and reverse
		flows to be on the same path?
	=09
	=09
		That is the way an Ethernet data plane works, and in my
		case this is where the requirement comes from. There is
Ethernet data
		plane OAM and in some cases Ethernet forwarding rules
that both require
		bi-directional symmetric paths. The requirement is to be
able to
		support native Ethernet loopback and data plane trace
functions and
		bi-directional symmetry in the data plane is required.
	=09
		5. What is "fate sharing"? I couldn't find this
		in other RFCs or IDs. Is it same as link/node/SRLG
disjoint paths?
	=09
	=09
		Yes it is related. A shared resource link group
		identifies shared resources at some granularity. Fate
shared paths have
		shared resources at a very high level of granularity.
Disjoint paths
		have none or very few shared resources. For a
bidirectional path the
		shared fate comes from the fact that both direction have
common
		resources and if one fails the other is likely to fail.
	=09
		Regards,
		Don
	=09
	=09
		Regards,
	=09
		Vijay
	=09
	=09
	=09
	=09
	=09

=09
________________________________

	Don't get soaked. Take a quick peak at the forecast
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news>=20
	with theYahoo! Search weather shortcut.
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news>=20

------_=_NextPart_001_01C76016.148731CC
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><SPAN class=3D103315515-06032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Igor</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D103315515-06032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D103315515-06032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Good points.&nbsp; Comments in=20
line.</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> Igor Bryskin=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, March 06, 2007 =
10:52=20
  AM<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Adrian,<BR><BR>I would define "fate sharing" very simply: it is =
the=20
  situation when both directions go through the same links at any time: =
after=20
  setup, protection switchover, recovery, reroute, etc. In control plane =
the=20
  bidirectional service where opposite directions fate-share we have =
some nice=20
  by-products:<SPAN class=3D103315515-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D103315515-06032007></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D103315515-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
Ethernet Bridging the "fate sharing" object is the to the level of ports =

on&nbsp;the bridge relay.&nbsp;&nbsp;Both direction of the path must =
pass=20
through the Bridge relay.&nbsp;There may be link aggregation functions =
below=20
this. So I would adjust your definition slightly to include same "link=20
objects".&nbsp; </FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D103315515-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D103315515-06032007>&nbsp;</SPAN><BR>a) CP states =
for both=20
  directions could be always combined together with the summary state =
reduced in=20
  size;<BR>b) the management of both directions can be accomplished =
using a=20
  single exchange of signaling messages, This holds for initial setup,=20
  protection switchover, recovery, re-route<BR>c) number of RSVP =
refreshes also=20
  is half as much<BR><BR>My understanding is that we do like the notion =
of a=20
  symmetrical bidirectional LSP in a packet switched network =
layer.&nbsp; This=20
  is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, =
and you.=20
  Adrian, I believe is still a big advocate of such migration. So, we =
don't mind=20
  an extra complexity (such as UPSTREAM LABEL, UPSTREAM ACCEPTABLE LABEL =

  SET).<BR><BR>I have just one question to the authors of the draft: do =
we have=20
  a strong use case for a bidirectional service requiring the fate =
sharing (as I=20
  defined it above) of both directions and fully symmetrical (recovery=20
  requirements, colors, etc) apart from the bandwidth requirements? If =
the=20
  answer is yes, than I say I don't mind a copule of extra signaling=20
  objects.<SPAN class=3D103315515-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D103315515-06032007></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>We=20
have a draft for GMPLS control of Ethernet PBB-TE which is an emerging =
L2 data=20
plane.&nbsp; The Ethernet bridge relay function assumes =
bi-directionality.=20
Ethernet data plane OAM is built on the bi-directional =
relay.&nbsp;&nbsp; IMHO=20
in that context the answer to your question is yes.&nbsp;&nbsp;&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
fact I think the requirement for asymmetrical BW is just related to the =
fact we=20
have a packet technology.&nbsp;(MPLS is no different). =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
need for bi-directional fate sharing is from the requirements of the =
Ethernet=20
Bridging Relay and our desire to leverage the Relay capabilities (this =
packet=20
layer is different).&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
use case cited for this requirement is the distribution of packet Video =
which=20
may well be high BW in one direction and relatively small in the =
other&nbsp;but=20
even my Internet connection is asymmetric today and I don't use it for =
video. So=20
the use case&nbsp;applies to all kinds of&nbsp;of packet transport.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D103315515-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>Don=20
</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT><BR>Igor<BR><BR><BR><B><I>Adrian Farrel=20
  &lt;[email-masked]&gt;</I></B> wrote:</DIV>
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(16,16,255) 2px solid">Hi,<BR><BR>There=20
    has been a lot of discussion about "fate-sharing" and I am not sure =
<BR>what=20
    problem we are trying to solve.<BR><BR>- Is this a data plane =
feature where=20
    a data plane fault in one<BR>direction must cause data plane =
interruption in=20
    both directions?<BR><BR>- Is this a protection feature where the =
switch-over=20
    of one<BR>direction to its backup path must be accompanied by=20
    a<BR>switch-over of the other direction, too?<BR><BR>- Is this a =
control=20
    plane feature where the removal of control<BR>plane state in one =
direction=20
    must cause the removal of control<BR>plane state in the other=20
    direction?<BR><BR>The use of a single control plane state =
(bidirectional=20
    signaling) obviously <BR>makes control plane fate-sharing automatic, =
but the=20
    use of associated <BR>signaling does not preclude control plane fate =
sharing=20
    - it just needs <BR>additional message exchanges.<BR><BR>The use of =
an=20
    identical path for both directions can provide some elements <BR>of =
data=20
    plane fate sharing, but it is important to note that it does not=20
    <BR>guarantee it. For example, a unidirectional fiber could fail. =
This issue=20
    is <BR>not impacted by bidirectional or associated signaling as the=20
    directions can <BR>be installed on the path by associated signaling, =
and as=20
    a failure might <BR>only impact one direction in bidirectional=20
    signaling.<BR><BR>End-to-end protection features are implemented at =
a=20
    different level and seem <BR>to be beyond this debate.<BR><BR><BR>So =
I am=20
    wondering what relevance fate-sharing has to the discussion of=20
    <BR>asymmetrical bandwidth. Maybe the discussion has reduced =
to:<BR>- We=20
    need asymmetrical bidirectional services<BR>- Does the value of a =
single=20
    signaling exchange outweigh the<BR>cost of new signaling objects and =

    procedures?<BR><BR>Adrian<BR><BR>----- Original Message ----- =
<BR>From:=20
    "Attila Takacs (IJ/ETH)" <[email-masked]><BR>To: =
"Pandian,=20
    Vijay" <[email-masked]>; "Don Fedyk"=20
    <BR><[email-masked]><BR>Cc: <[email-masked]><BR>Sent: =
Tuesday, March=20
    06, 2007 10:34 AM<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi Vijay,<BR><BR>let me =
answer=20
    this.<BR><BR>If you need different protection for each direction =
then you=20
    likely will<BR>need differently routed LSPs. In this case one better =
uses=20
    separate<BR>sessions for the two directions since all the benefits =
of having=20
    a<BR>single session (like fate sharing) is gone if the LSPs take=20
    different<BR>routes. The ID only proposes to relax the symmetrical =
bandwidth=20
    property<BR>of the bidirectional LSP establishment given in=20
    =
RFC3471.<BR><BR>Regards,<BR>Attila<BR><BR>_______________________________=
_<BR><BR>From:=20
    [email-masked] [mailto:[email-masked]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [email-masked]<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR><BR>Don,<BR><BR>The =
question I=20
    had regarding P&amp;R was trying to figure out if one<BR>direction =
required=20
    a better P&amp;R (say 1+1) and the reverse direction<BR>probably =
required=20
    some basic P&amp;R (say Re-routing).<BR><BR>So the requirement is to =
use the=20
    same "physical link" for the<BR>forward and reverse direction. Am I=20
    right?<BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR><BR>-----Original=20
    Message-----<BR>From: Don Fedyk [mailto:[email-masked]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[email-masked]<BR>Subject:=20
    RE: Questions on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi=20
    Vijay<BR><BR><BR>________________________________<BR><BR>From:=20
    [email-masked]<BR>[mailto:[email-masked]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [email-masked]<BR>Subject: Questions=20
    on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi,<BR><BR>I have =
some=20
    basic questions, primarily trying to<BR>understand the scope of this =
ID as=20
    well as the application behind such a<BR>requirement.<BR><BR>1. Does =
this ID=20
    address just an asymmetric<BR>Bandwidth requirement?<BR><BR>The =
postulation=20
    was that GMPLS today supports<BR>bi-directional service with a =
single=20
    RSVP-TE session creating a<BR>bidirectional LSP. The most common=20
    implementation of this is Optical<BR>TDM networks. Since this was =
the=20
    starting point, the ID postulates<BR>setting up an asymmetric =
service with a=20
    single asymmetric LSP. (Like<BR>many new drafts it sets a =
requirement and=20
    postulates a an<BR>implementation.)<BR><BR>So to your question =
besides=20
    bandwidth there is also<BR>underlying requirement to align with =
GMPLS single=20
    session procedures and<BR>support a bi-directional packet data plane =
as=20
    Ethernet does today. A<BR>single bidirectional (in this case =
asymmetric BW=20
    capable) LSP. In other<BR>words a single RSVP-TE session. Several =
people=20
    have pointed out this is<BR>also achievable with two unidirectional =
RSVP-TE=20
    sessions (one at each<BR>end). Rather than reopen that debate on =
this thread=20
    I will acknowledge<BR>the authors had a single session in mind more =
as a=20
    requirement of the<BR>technology. Ethernet data forwarding is =
bi-directional=20
    symmetric and<BR>there are efficiencies in a single session of a=20
    bi-directional LSP. On<BR>the other hand the issue is there is =
currently no=20
    way to specify the<BR>asymmetric BW. If you want to discuss the pros =
and=20
    cons of multiple<BR>sessions versus single there is already a thread =
on this=20
    (RE: I-D<BR>ACTION:draft-takacs-asym-bw-lsp-00.txt)<BR><BR>| 2. How =
about=20
    other attributes? in particular LSP<BR>Protection &amp; Recovery =
(P&amp;R)=20
    related attributes?<BR><BR>With respect to GMPLS, the plan was to=20
    allow<BR>bi-directional Protection or Recovery LSPs controlled by=20
    separate<BR>RSVP-TE sessions in separate from the single RSVP-TE =
session=20
    associated<BR>with the primary bidirectional LSP.<BR><BR>3. If =
P&amp;R are=20
    indeed different, doesn't it make<BR>sense to route them separately=20
    (separate CSPF calculation at each end)<BR>and eventually signal =
them=20
    independently as well?<BR><BR><BR>Hopefully I addressed part of this =

    already. Recovery of<BR>the bi-directional LSP could be handled by =
another=20
    RSVP-TE session &amp;<BR>LSP. The data plane in our case must have a =

    bi-directional symmetric<BR>path so you can only do a CSPF at one =
end and/or=20
    force the paths to<BR>align.<BR><BR>4. Is there a need for the =
forward and=20
    reverse<BR>flows to be on the same path?<BR><BR><BR>That is the way =
an=20
    Ethernet data plane works, and in my<BR>case this is where the =
requirement=20
    comes from. There is Ethernet data<BR>plane OAM and in some cases =
Ethernet=20
    forwarding rules that both require<BR>bi-directional symmetric =
paths. The=20
    requirement is to be able to<BR>support native Ethernet loopback and =
data=20
    plane trace functions and<BR>bi-directional symmetry in the data =
plane is=20
    required.<BR><BR>5. What is "fate sharing"? I couldn't find =
this<BR>in other=20
    RFCs or IDs. Is it same as link/node/SRLG disjoint =
paths?<BR><BR><BR>Yes it=20
    is related. A shared resource link group<BR>identifies shared =
resources at=20
    some granularity. Fate shared paths have<BR>shared resources at a =
very high=20
    level of granularity. Disjoint paths<BR>have none or very few shared =

    resources. For a bidirectional path the<BR>shared fate comes from =
the fact=20
    that both direction have common<BR>resources and if one fails the =
other is=20
    likely to=20
    =
fail.<BR><BR>Regards,<BR>Don<BR><BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR>=
<BR><BR></[email-masked]></[email-masked]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[email-masked]></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  Don't get soaked. Take a<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">=20
  quick peak at the forecast </A><BR>with the<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">Yahoo!=20
  Search weather shortcut.</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C76016.148731CC--

Delivery-date: Tue, 06 Mar 2007 17:14:34 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 17:13:04 -0000
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_01C76012.B3D0B7AD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Igor,
=20
I can think of one good case.  In CO mode layer networks the 2 key OAM
messages are CV (Connectivity Verification) and BDI (Backward Defect
Indication).  These OAM messages should be present on the trails in each
direction.  The key purpose of BDI is to allow a single end to see the
failure state of its outgoing direction, eg case of unidirectional
connection failure.  For this be of use in a link in a layer N network
for a unidirectional failure of a trail in a layer N-1 network serving
that link, one needs congruent bidirectional trail routings in both
those layer networks.....and clearly this is a recursive requirement
between any layers.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin
Sent: 06 March 2007 15:52
To: Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: Re: What is this fate sharing thing? [Was: Questions on
draft-takacs-asym-bw-lsp-00.txt]

Adrian,

I would define "fate sharing" very simply: it is the situation when both
directions go through the same links at any time: after setup,
protection switchover, recovery, reroute, etc. In control plane the
bidirectional service where opposite directions fate-share we have some
nice by-products:
a) CP states for both directions could be always combined together with
the summary state reduced in size;
b) the management of both directions can be accomplished using a single
exchange of signaling messages, This holds for initial setup, protection
switchover, recovery, re-route
c) number of RSVP refreshes also is half as much

My understanding is that we do like the notion of a symmetrical
bidirectional LSP in a packet switched network layer.  This is a (I'd
say big) reason why we want to migrate from MPLS to GMPLS, and you.
Adrian, I believe is still a big advocate of such migration. So, we
don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM
ACCEPTABLE LABEL SET).

I have just one question to the authors of the draft: do we have a
strong use case for a bidirectional service requiring the fate sharing
(as I defined it above) of both directions and fully symmetrical
(recovery requirements, colors, etc) apart from the bandwidth
requirements? If the answer is yes, than I say I don't mind a copule of
extra signaling objects.

Igor

Adrian Farrel <[email-masked]> wrote:=20

Hi,

There has been a lot of discussion about "fate-sharing" and I am not
sure=20
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
direction to its backup path must be accompanied by a
switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
plane state in one direction must cause the removal of control
plane state in the other direction?

The use of a single control plane state (bidirectional signaling)
obviously=20
makes control plane fate-sharing automatic, but the use of associated=20
signaling does not preclude control plane fate sharing - it just needs=20
additional message exchanges.

The use of an identical path for both directions can provide some
elements=20
of data plane fate sharing, but it is important to note that it does not

guarantee it. For example, a unidirectional fiber could fail. This issue
is=20
not impacted by bidirectional or associated signaling as the directions
can=20
be installed on the path by associated signaling, and as a failure might

only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and
seem=20
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of=20
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
cost of new signaling objects and procedures?

Adrian

----- Original Message -----=20
From: "Attila Takacs (IJ/ETH)"=20
To: "Pandian, Vijay" ; "Don Fedyk"=20

Cc:=20
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP. The most common implementation of this is Optical
TDM networks. Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP. (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today. A
single bidirectional (in this case asymmetric BW capable) LSP. In other
words a single RSVP-TE session. Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end). Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology. Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP. On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

| 2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP. The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths. The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related. A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity. Disjoint paths
have none or very few shared resources. For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

  _____ =20

Don't get soaked. Take a
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news> quick
peak at the forecast=20
with theYahoo!
<http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&#news> Search
weather shortcut.

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

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

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D532015616-06032007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Igor,</FONT></SPAN></DIV>
<DIV><SPAN class=3D532015616-06032007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D532015616-06032007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>I can think of one good case.&nbsp; In CO mode layer networks =
the 2 key=20
OAM messages are CV (Connectivity Verification) and BDI (Backward Defect =

Indication).&nbsp; These OAM messages&nbsp;should be present on the =
trails in=20
each direction.&nbsp; The key purpose of BDI is to allow a single end to =
see the=20
failure state of its outgoing direction,&nbsp;eg case of unidirectional=20
connection failure.&nbsp; For this be of use in a link in a layer N =
network for=20
a unidirectional failure of a trail in a layer N-1 network serving that =
link,=20
one needs congruent bidirectional trail routings in both those layer=20
networks.....and clearly this is a recursive requirement between any=20
layers.</FONT></SPAN></DIV>
<DIV><SPAN class=3D532015616-06032007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D532015616-06032007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></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>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Igor Bryskin<BR><B>Sent:</B> 06 March 2007 15:52<BR><B>To:</B> =
Adrian=20
  Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don =
Fedyk<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: What is this fate sharing =
thing?=20
  [Was: Questions on=20
  draft-takacs-asym-bw-lsp-00.txt]<BR><BR></FONT></DIV>Adrian,<BR><BR>I =
would=20
  define "fate sharing" very simply: it is the situation when both =
directions go=20
  through the same links at any time: after setup, protection =
switchover,=20
  recovery, reroute, etc. In control plane the bidirectional service =
where=20
  opposite directions fate-share we have some nice by-products:<BR>a) CP =
states=20
  for both directions could be always combined together with the summary =
state=20
  reduced in size;<BR>b) the management of both directions can be =
accomplished=20
  using a single exchange of signaling messages, This holds for initial =
setup,=20
  protection switchover, recovery, re-route<BR>c) number of RSVP =
refreshes also=20
  is half as much<BR><BR>My understanding is that we do like the notion =
of a=20
  symmetrical bidirectional LSP in a packet switched network =
layer.&nbsp; This=20
  is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, =
and you.=20
  Adrian, I believe is still a big advocate of such migration. So, we =
don't mind=20
  an extra complexity (such as UPSTREAM LABEL, UPSTREAM ACCEPTABLE LABEL =

  SET).<BR><BR>I have just one question to the authors of the draft: do =
we have=20
  a strong use case for a bidirectional service requiring the fate =
sharing (as I=20
  defined it above) of both directions and fully symmetrical (recovery=20
  requirements, colors, etc) apart from the bandwidth requirements? If =
the=20
  answer is yes, than I say I don't mind a copule of extra signaling=20
  objects.<BR><BR>Igor<BR><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">Hi,<BR><BR>There=20
    has been a lot of discussion about "fate-sharing" and I am not sure =
<BR>what=20
    problem we are trying to solve.<BR><BR>- Is this a data plane =
feature where=20
    a data plane fault in one<BR>direction must cause data plane =
interruption in=20
    both directions?<BR><BR>- Is this a protection feature where the =
switch-over=20
    of one<BR>direction to its backup path must be accompanied by=20
    a<BR>switch-over of the other direction, too?<BR><BR>- Is this a =
control=20
    plane feature where the removal of control<BR>plane state in one =
direction=20
    must cause the removal of control<BR>plane state in the other=20
    direction?<BR><BR>The use of a single control plane state =
(bidirectional=20
    signaling) obviously <BR>makes control plane fate-sharing automatic, =
but the=20
    use of associated <BR>signaling does not preclude control plane fate =
sharing=20
    - it just needs <BR>additional message exchanges.<BR><BR>The use of =
an=20
    identical path for both directions can provide some elements <BR>of =
data=20
    plane fate sharing, but it is important to note that it does not=20
    <BR>guarantee it. For example, a unidirectional fiber could fail. =
This issue=20
    is <BR>not impacted by bidirectional or associated signaling as the=20
    directions can <BR>be installed on the path by associated signaling, =
and as=20
    a failure might <BR>only impact one direction in bidirectional=20
    signaling.<BR><BR>End-to-end protection features are implemented at =
a=20
    different level and seem <BR>to be beyond this debate.<BR><BR><BR>So =
I am=20
    wondering what relevance fate-sharing has to the discussion of=20
    <BR>asymmetrical bandwidth. Maybe the discussion has reduced =
to:<BR>- We=20
    need asymmetrical bidirectional services<BR>- Does the value of a =
single=20
    signaling exchange outweigh the<BR>cost of new signaling objects and =

    procedures?<BR><BR>Adrian<BR><BR>----- Original Message ----- =
<BR>From:=20
    "Attila Takacs (IJ/ETH)" <[email-masked]><BR>To: =
"Pandian,=20
    Vijay" <[email-masked]>; "Don Fedyk"=20
    <BR><[email-masked]><BR>Cc: <[email-masked]><BR>Sent: =
Tuesday, March=20
    06, 2007 10:34 AM<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi Vijay,<BR><BR>let me =
answer=20
    this.<BR><BR>If you need different protection for each direction =
then you=20
    likely will<BR>need differently routed LSPs. In this case one better =
uses=20
    separate<BR>sessions for the two directions since all the benefits =
of having=20
    a<BR>single session (like fate sharing) is gone if the LSPs take=20
    different<BR>routes. The ID only proposes to relax the symmetrical =
bandwidth=20
    property<BR>of the bidirectional LSP establishment given in=20
    =
RFC3471.<BR><BR>Regards,<BR>Attila<BR><BR>_______________________________=
_<BR><BR>From:=20
    [email-masked] [mailto:[email-masked]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [email-masked]<BR>Subject: RE: Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR><BR>Don,<BR><BR>The =
question I=20
    had regarding P&amp;R was trying to figure out if one<BR>direction =
required=20
    a better P&amp;R (say 1+1) and the reverse direction<BR>probably =
required=20
    some basic P&amp;R (say Re-routing).<BR><BR>So the requirement is to =
use the=20
    same "physical link" for the<BR>forward and reverse direction. Am I=20
    right?<BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR><BR>-----Original=20
    Message-----<BR>From: Don Fedyk [mailto:[email-masked]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[email-masked]<BR>Subject:=20
    RE: Questions on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi=20
    Vijay<BR><BR><BR>________________________________<BR><BR>From:=20
    [email-masked]<BR>[mailto:[email-masked]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [email-masked]<BR>Subject: Questions=20
    on<BR>draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>Hi,<BR><BR>I have =
some=20
    basic questions, primarily trying to<BR>understand the scope of this =
ID as=20
    well as the application behind such a<BR>requirement.<BR><BR>1. Does =
this ID=20
    address just an asymmetric<BR>Bandwidth requirement?<BR><BR>The =
postulation=20
    was that GMPLS today supports<BR>bi-directional service with a =
single=20
    RSVP-TE session creating a<BR>bidirectional LSP. The most common=20
    implementation of this is Optical<BR>TDM networks. Since this was =
the=20
    starting point, the ID postulates<BR>setting up an asymmetric =
service with a=20
    single asymmetric LSP. (Like<BR>many new drafts it sets a =
requirement and=20
    postulates a an<BR>implementation.)<BR><BR>So to your question =
besides=20
    bandwidth there is also<BR>underlying requirement to align with =
GMPLS single=20
    session procedures and<BR>support a bi-directional packet data plane =
as=20
    Ethernet does today. A<BR>single bidirectional (in this case =
asymmetric BW=20
    capable) LSP. In other<BR>words a single RSVP-TE session. Several =
people=20
    have pointed out this is<BR>also achievable with two unidirectional =
RSVP-TE=20
    sessions (one at each<BR>end). Rather than reopen that debate on =
this thread=20
    I will acknowledge<BR>the authors had a single session in mind more =
as a=20
    requirement of the<BR>technology. Ethernet data forwarding is =
bi-directional=20
    symmetric and<BR>there are efficiencies in a single session of a=20
    bi-directional LSP. On<BR>the other hand the issue is there is =
currently no=20
    way to specify the<BR>asymmetric BW. If you want to discuss the pros =
and=20
    cons of multiple<BR>sessions versus single there is already a thread =
on this=20
    (RE: I-D<BR>ACTION:draft-takacs-asym-bw-lsp-00.txt)<BR><BR>| 2. How =
about=20
    other attributes? in particular LSP<BR>Protection &amp; Recovery =
(P&amp;R)=20
    related attributes?<BR><BR>With respect to GMPLS, the plan was to=20
    allow<BR>bi-directional Protection or Recovery LSPs controlled by=20
    separate<BR>RSVP-TE sessions in separate from the single RSVP-TE =
session=20
    associated<BR>with the primary bidirectional LSP.<BR><BR>3. If =
P&amp;R are=20
    indeed different, doesn't it make<BR>sense to route them separately=20
    (separate CSPF calculation at each end)<BR>and eventually signal =
them=20
    independently as well?<BR><BR><BR>Hopefully I addressed part of this =

    already. Recovery of<BR>the bi-directional LSP could be handled by =
another=20
    RSVP-TE session &amp;<BR>LSP. The data plane in our case must have a =

    bi-directional symmetric<BR>path so you can only do a CSPF at one =
end and/or=20
    force the paths to<BR>align.<BR><BR>4. Is there a need for the =
forward and=20
    reverse<BR>flows to be on the same path?<BR><BR><BR>That is the way =
an=20
    Ethernet data plane works, and in my<BR>case this is where the =
requirement=20
    comes from. There is Ethernet data<BR>plane OAM and in some cases =
Ethernet=20
    forwarding rules that both require<BR>bi-directional symmetric =
paths. The=20
    requirement is to be able to<BR>support native Ethernet loopback and =
data=20
    plane trace functions and<BR>bi-directional symmetry in the data =
plane is=20
    required.<BR><BR>5. What is "fate sharing"? I couldn't find =
this<BR>in other=20
    RFCs or IDs. Is it same as link/node/SRLG disjoint =
paths?<BR><BR><BR>Yes it=20
    is related. A shared resource link group<BR>identifies shared =
resources at=20
    some granularity. Fate shared paths have<BR>shared resources at a =
very high=20
    level of granularity. Disjoint paths<BR>have none or very few shared =

    resources. For a bidirectional path the<BR>shared fate comes from =
the fact=20
    that both direction have common<BR>resources and if one fails the =
other is=20
    likely to=20
    =
fail.<BR><BR>Regards,<BR>Don<BR><BR><BR>Regards,<BR><BR>Vijay<BR><BR><BR>=
<BR><BR></[email-masked]></[email-masked]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[email-masked]></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  Don't get soaked. Take a<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">=20
  quick peak at the forecast </A><BR>with the<A=20
  =
href=3D"http://tools.search.yahoo.com/shortcuts/?fr=3Doni_on_mail&amp;#ne=
ws">Yahoo!=20
  Search weather shortcut.</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C76012.B3D0B7AD--

Delivery-date: Tue, 06 Mar 2007 15:56:20 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 10:55:28 -0500
From: "Don Fedyk" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>
Cc: <[email-masked]>

Hi Adrian

In an Ethernet bridging context I'll try to add what I know.=20

> -----Original Message----- From: Adrian Farrel
> [mailto:[email-masked]] Sent: Tuesday, March 06, 2007
> 6:05 AM To: Attila Takacs (IJ/ETH); Pandian, Vijay; Fedyk,
> Don (BL60:1A00) Cc: [email-masked] Subject: What is
> this fate sharing thing? [Was: Questions on
> draft-takacs-asym-bw-lsp-00.txt]
>=20
> Hi,
>=20
> There has been a lot of discussion about "fate-sharing"
> and I am not sure what problem we are trying to solve.
>=20
> - Is this a data plane feature where a data plane fault in
> one direction must cause data plane interruption in both
> directions?
[DF]When we say data plane I suppose it depends on the Physical
layer as well. I'm not much of an expert on physical layers
but I believe we went over much of this in the GMPLS control
of optical.=20

For Ethernet bridging, if there is a fault detected in one direction
the OAM signals the fault and at a minimum an alarm is
raised. I don't believe there is an immediate attempt to
interupt data but one result may be to use the indication or
activate protection or restoration mechanisms.=20
In Ethernet bridging the Bridge Relay is a bi-drectional functions=20
that is attached to two ports. (below the ports there may be=20
unidirectional links).=20
=20
>=20
> - Is this a protection feature where the switch-over of
> one direction to its backup path must be accompanied by a
> switch-over of the other direction, too?
[DF]In Ethernet this is the case. Unidirectional Ethernet would
not support many Ethernet features.=20

>=20
> - Is this a control plane feature where the removal of
> control plane state in one direction must cause the
> removal of control plane state in the other direction?
[DF]I don't know if I can parse this. "removal of control plane
state in one direction in a bidirectional LSP?" I think you
may be refering to the case where two RSVP-TE sessions
control a single bi-directional path.  The point is the data
plane should not be unidirectionally active since this would
create issues with OAM functions that assume a bidirectional
data plane. =20
>=20
> The use of a single control plane state (bidirectional
> signaling) obviously makes control plane fate-sharing
> automatic, but the use of associated signaling does not
> preclude control plane fate sharing - it just needs
> additional message exchanges.
[DF]True but in the case of associated case there is also a
concept of a master and slave relationship between the
associated signaling paths for any given action. This
requires new capability as well.
>=20
> The use of an identical path for both directions can
> provide some elements of data plane fate sharing, but it
> is important to note that it does not guarantee it. For
> example, a unidirectional fiber could fail.  This issue is
> not impacted by bidirectional or associated signaling as
> the directions can be installed on the path by associated
> signaling, and as a failure might only impact one
> direction in bidirectional signaling.
[DF]The bi-directional aspects are at the L2 Ethernet bridge level.
Unidirectional faults are detected as loss of Connectivity
check messages or the like and declared the ethernet LSP in
fault. What action is taken depends on the choice of
configuration and control plane.

>=20
> End-to-end protection features are implemented at a different=20
> level and seem to be beyond this debate.

[DF]There could be an association object to implement some
aspects of co-ordination between a primary and a backup LSP.
>=20
>=20
> So I am wondering what relevance fate-sharing has to the
> discussion of asymmetrical bandwidth. Maybe the discussion
> has reduced to:
> - We need asymmetrical bidirectional services=20
> - Does the value of a single signaling exchange
> outweigh the cost of new signaling objects and procedures?
[DF]The fate sharing aspect is related to the Ethernet
bi-directionality.  We need bi-directional Ethernet LSPs=20
with (symmetric or asymmetric BW). This requirement is stronger=20
than your first point.

Perhaps Fate sharing is not the right or the best term.  My
understanding of Ethernet is a typically a Spanning tree
creates the bi-directional Ethernet paths that have these
properties. You can also configure static Ethernet paths
that have the same properties.=20

Regards,
Don=20

>=20
>=20
<snip>

Delivery-date: Tue, 06 Mar 2007 15:53:01 +0000
Date: Tue, 6 Mar 2007 07:51:53 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
To: Adrian Farrel <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, Don Fedyk <[email-masked]>
Cc: [email-masked]

--0-509371772-1173196313=:8128
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian,

I would define "fate sharing" very simply: it is the situation when both directions go through the same links at any time: after setup, protection switchover, recovery, reroute, etc. In control plane the bidirectional service where opposite directions fate-share we have some nice by-products:
a) CP states for both directions could be always combined together with the summary state reduced in size;
b) the management of both directions can be accomplished using a single exchange of signaling messages, This holds for initial setup, protection switchover, recovery, re-route
c) number of RSVP refreshes also is half as much

My understanding is that we do like the notion of a symmetrical bidirectional LSP in a packet switched network layer.  This is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, and you. Adrian, I believe is still a big advocate of such migration. So, we don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM ACCEPTABLE LABEL SET).

I have just one question to the authors of the draft: do we have a strong use case for a bidirectional service requiring the fate sharing (as I defined it above) of both directions and fully symmetrical (recovery requirements, colors, etc) apart from the bandwidth requirements? If the answer is yes, than I say I don't mind a copule of extra signaling objects.

Igor

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

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 
of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue is 
not impacted by bidirectional or associated signaling as the directions can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" 
To: "Pandian, Vijay" ; "Don Fedyk" 

Cc: 
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

---------------------------------
Don't get soaked.  Take a quick peak at the forecast 
 with theYahoo! Search weather shortcut.
--0-509371772-1173196313=:8128
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian,<br><br>I would define "fate sharing" very simply: it is the situation when both directions go through the same links at any time: after setup, protection switchover, recovery, reroute, etc. In control plane the bidirectional service where opposite directions fate-share we have some nice by-products:<br>a) CP states for both directions could be always combined together with the summary state reduced in size;<br>b) the management of both directions can be accomplished using a single exchange of signaling messages, This holds for initial setup, protection switchover, recovery, re-route<br>c) number of RSVP refreshes also is half as much<br><br>My understanding is that we do like the notion of a symmetrical bidirectional LSP in a packet switched network layer.&nbsp; This is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, and you. Adrian, I believe is still a big advocate of such migration. So, we don't mind an extra complexity (such as UPSTREAM LABEL,
 UPSTREAM ACCEPTABLE LABEL SET).<br><br>I have just one question to the authors of the draft: do we have a strong use case for a bidirectional service requiring the fate sharing (as I defined it above) of both directions and fully symmetrical (recovery requirements, colors, etc) apart from the bandwidth requirements? If the answer is yes, than I say I don't mind a copule of extra signaling objects.<br><br>Igor<br><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>There has been a lot of discussion about "fate-sharing" and I am not sure <br>what problem we are trying to solve.<br><br>- Is this a data plane feature where a data plane fault in one<br>  direction must cause data plane interruption in both directions?<br><br>- Is this a protection feature where the switch-over of one<br>  direction to its backup path must be accompanied
 by a<br>  switch-over of the other direction, too?<br><br>- Is this a control plane feature where the removal of control<br>  plane state in one direction must cause the removal of control<br>  plane state in the other direction?<br><br>The use of a single control plane state (bidirectional signaling) obviously <br>makes control plane fate-sharing automatic, but the use of associated <br>signaling does not preclude control plane fate sharing - it just needs <br>additional message exchanges.<br><br>The use of an identical path for both directions can provide some elements <br>of data plane fate sharing, but it is important to note that it does not <br>guarantee it. For example, a unidirectional fiber could fail. This issue is <br>not impacted by bidirectional or associated signaling as the directions can <br>be installed on the path by associated signaling, and as a failure might <br>only impact one direction in bidirectional signaling.<br><br>End-to-end protection features
 are implemented at a different level and seem <br>to be beyond this debate.<br><br><br>So I am wondering what relevance fate-sharing has to the discussion of <br>asymmetrical bandwidth. Maybe the discussion has reduced to:<br>- We need asymmetrical bidirectional services<br>- Does the value of a single signaling exchange outweigh the<br>   cost of new signaling objects and procedures?<br><br>Adrian<br><br>----- Original Message ----- <br>From: "Attila Takacs (IJ/ETH)" <[email-masked]><br>To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" <br><[email-masked]><br>Cc: <[email-masked]><br>Sent: Tuesday, March 06, 2007 10:34 AM<br>Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay,<br><br>let me answer this.<br><br>If you need different protection for each direction then you likely will<br>need differently routed LSPs. In this case one better uses separate<br>sessions for the two directions since all the benefits of
 having a<br>single session (like fate sharing) is gone if the LSPs take different<br>routes. The ID only proposes to relax the symmetrical bandwidth property<br>of the bidirectional LSP establishment given in RFC3471.<br><br>Regards,<br>Attila<br><br>________________________________<br><br>From: [email-masked] [mailto:[email-masked]] On<br>Behalf Of Pandian, Vijay<br>Sent: Tuesday, March 06, 2007 1:36 AM<br>To: Don Fedyk<br>Cc: [email-masked]<br>Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt<br><br><br><br>Don,<br><br>The question I had regarding P&amp;R was trying to figure out if one<br>direction required a better P&amp;R (say 1+1) and the reverse direction<br>probably required some basic P&amp;R (say Re-routing).<br><br>So the requirement is to use the same "physical link" for the<br>forward and reverse direction. Am I right?<br><br>Regards,<br><br>Vijay<br><br><br><br>-----Original Message-----<br>From: Don Fedyk
 [mailto:[email-masked]]<br>Sent: Monday, March 05, 2007 6:41 PM<br>To: Pandian, Vijay; [email-masked]<br>Subject: RE: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay<br><br><br>________________________________<br><br>From: [email-masked]<br>[mailto:[email-masked]] On Behalf Of Pandian, Vijay<br>Sent: Monday, March 05, 2007 2:07 PM<br>To: [email-masked]<br>Subject: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi,<br><br>I have some basic questions, primarily trying to<br>understand the scope of this ID as well as the application behind such a<br>requirement.<br><br>1. Does this ID address just an asymmetric<br>Bandwidth requirement?<br><br>The postulation was that GMPLS today supports<br>bi-directional service with a single RSVP-TE session creating a<br>bidirectional LSP.  The most common implementation of this is Optical<br>TDM networks.  Since this was the starting point, the ID postulates<br>setting up an
 asymmetric service with a single asymmetric LSP.  (Like<br>many new drafts it sets a requirement and postulates a an<br>implementation.)<br><br>So to your question besides bandwidth there is also<br>underlying requirement to align with GMPLS single session procedures and<br>support a bi-directional packet data plane as Ethernet does today.  A<br>single bidirectional (in this case asymmetric BW capable) LSP.  In other<br>words a single RSVP-TE session.  Several people have pointed out this is<br>also achievable with two unidirectional RSVP-TE sessions (one at each<br>end).  Rather than reopen that debate on this thread I will acknowledge<br>the authors had a single session in mind more as a requirement of the<br>technology.  Ethernet data forwarding is bi-directional symmetric and<br>there are efficiencies in a single session of a bi-directional LSP.  On<br>the other hand the issue is there is currently no way to specify the<br>asymmetric BW. If you want to discuss the pros
 and cons of multiple<br>sessions versus single there is already a thread on this (RE: I-D<br>ACTION:draft-takacs-asym-bw-lsp-00.txt)<br><br>|  2. How about other attributes? in particular LSP<br>Protection &amp; Recovery (P&amp;R) related attributes?<br><br>With respect to GMPLS, the plan was to allow<br>bi-directional Protection or Recovery LSPs controlled by separate<br>RSVP-TE sessions in separate from the single RSVP-TE session associated<br>with the primary bidirectional LSP.<br><br>3. If P&amp;R are indeed different, doesn't it make<br>sense to route them separately (separate CSPF calculation at each end)<br>and eventually signal them independently as well?<br><br><br>Hopefully I addressed part of this already. Recovery of<br>the bi-directional LSP could be handled by another RSVP-TE session &amp;<br>LSP.  The data plane in our case must have a bi-directional symmetric<br>path so you can only do a CSPF at one end and/or force the paths to<br>align.<br><br>4. Is there
 a need for the forward and reverse<br>flows to be on the same path?<br><br><br>That is the way an Ethernet data plane works, and in my<br>case this is where the requirement comes from. There is Ethernet data<br>plane OAM and in some cases Ethernet forwarding rules that both require<br>bi-directional symmetric paths.  The requirement is to be able to<br>support native Ethernet loopback and data plane trace functions and<br>bi-directional symmetry in the data plane is required.<br><br>5. What is "fate sharing"? I couldn't find this<br>in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?<br><br><br>Yes it is related.  A shared resource link group<br>identifies shared resources at some granularity. Fate shared paths have<br>shared resources at a very high level of granularity.  Disjoint paths<br>have none or very few shared resources.  For a bidirectional path the<br>shared fate comes from the fact that both direction have common<br>resources and if one fails the
 other is likely to fail.<br><br>Regards,<br>Don<br><br><br>Regards,<br><br>Vijay<br><br><br><br><br></[email-masked]></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>
Don't get soaked.  Take a<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> quick peak at the forecast </a><br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search weather shortcut.</a>
--0-509371772-1173196313=:8128--

Delivery-date: Tue, 06 Mar 2007 14:41:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 15:41:00 +0100
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Vijay,

               Please see in line.

=20

Best regards

=20

Diego

=20

________________________________

From: Pandian, Vijay [mailto:[email-masked]]=20
Sent: marted=EC 6 marzo 2007 15.36
To: Diego Caviglia (GA/ERI); Attila Takacs (IJ/ETH); Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

=20

Hi Diego,

=20

Even for point 1.3, it is not clear why the two directions of this LSP =
needs to be on the same (physical?) path.

[dc] I not saying that they must be on or need to be on the same path in =
order to work.  I'm saying if there is a requirement to have upstream =
and downstream on the same path then....

=20

 I may not understand the IpTv application, but isn't it true that the =
direction where you need a small bandwidth probably is used to send =
control messages such as "channel change" etc... In that case, doesn't =
it make sense to use a completely different path with a different QoS =
for a efficient network resource utilization?

=20

Assuming that we end up treating each direction as independent sessions, =
can we use the  GMPLS-CALL ID to correlate the two connections? I assume =
the intermediate nodes don't care about such an "ASSOCIATEION".

[dc] Yes=20

=20

Regards,

=20

Vijay

	-----Original Message-----
	From: Diego Caviglia (GA/ERI) [mailto:[email-masked]]
	Sent: Tuesday, March 06, 2007 6:30 AM
	To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
	Cc: [email-masked]
	Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	Guys,

	         let me try to summarize what we have said so far:

	1.       1         The basic idea behind the ID is based on some facts =
(I hope we all agree that are facts :-));

	2.      1.1      Ethernet services are (likely) bidirectional with =
asymmetric bandwidth;

	3.      1.2      GMPLS now allows to set-up bi-directional LSP with =
symmetrical bandwidth;

	4.      1.3      If, with the existing protocols, there is the need to =
set-up a bi-directional service with asymmetric bandwidth requirement =
(e.g. IpTv) and with upstream and downstream path that follow the same =
route we have to signal two different LSPs using the RRO of the first =
one as strict ERO for the second one.  If we also want to bind the two =
LSPs in order to identify them as part of the same service we can use =
the ASSOCIATON obj (modified I suppose)

	5.      1.4      Likely (I would say very likely) the NMS that requests =
the LSP(s) set-up knows in advance the bandwidth needed in the two =
directions.  So we are in a different situation w.r.t. the original RSVP =
situation.  We have all the information we need to set-up the LSP at the =
Path processing

	6.                  Now if all of we are happy with point 1.3 then we =
have finished.  If someone think that is better to have the possibility =
to set-up and identify a bidirectional service with a single LSP then =
the ID have reason to exists at least for discussion :-).

	7.                  IMHO having the possibility to set-up the LSP at =
the path processing speed up the service establishment and this is =
particularly useful in case of LSP rerouting in case of failure.  In =
fact if the service is made of the two LSP what could happens is the =
first one can be set-up and the second one fails during signaling this =
means that first one have to be deleted and two LSP path recomputed and =
re-signaled. =20

	8.                  Best Regards

	9.                   =20

	10.              Diego =20

	11.               =20

	=20

=09
________________________________

	From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs (IJ/ETH)
	Sent: marted=EC 6 marzo 2007 11.35
	To: Pandian, Vijay; Don Fedyk
	Cc: [email-masked]
	Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	=20

	Hi Vijay,

	=20

	let me answer this.=20

	=20

	If you need different protection for each direction then you likely =
will need differently routed LSPs. In this case one better uses separate =
sessions for the two directions since all the benefits of having a =
single session (like fate sharing) is gone if the LSPs take different =
routes. The ID only proposes to relax the symmetrical bandwidth property =
of the bidirectional LSP establishment given in RFC3471.

	=20

	Regards,

	Attila

	=20

=09
________________________________

	From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
	Sent: Tuesday, March 06, 2007 1:36 AM
	To: Don Fedyk
	Cc: [email-masked]
	Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

		Don,

		=20

		The question I had regarding P&R was trying to figure out if one =
direction required a better P&R (say 1+1) and the reverse direction =
probably required some basic P&R (say Re-routing).

		=20

		So the requirement is to use the same "physical link" for the forward =
and reverse direction. Am I right?

		=20

		Regards,

		=20

		Vijay

		=20

		=20

			-----Original Message-----
			From: Don Fedyk [mailto:[email-masked]]
			Sent: Monday, March 05, 2007 6:41 PM
			To: Pandian, Vijay; [email-masked]
			Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

			Hi Vijay

				=20

			=09
________________________________

				From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
				Sent: Monday, March 05, 2007 2:07 PM
				To: [email-masked]
				Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

				Hi,

				=20

				I have some basic questions, primarily trying to understand the =
scope of this ID as well as the application behind such a requirement.

				=20

				1. Does this ID address just an asymmetric Bandwidth requirement?=20

			The postulation was that GMPLS today supports bi-directional service =
with a single RSVP-TE session creating a bidirectional LSP.  The most =
common implementation of this is Optical TDM networks.  Since this was =
the starting point, the ID postulates setting up an asymmetric service =
with a single asymmetric LSP.  (Like many new drafts it sets a =
requirement and postulates a an implementation.) =20

			=20

			So to your question besides bandwidth there is also underlying =
requirement to align with GMPLS single session procedures and support a =
bi-directional packet data plane as Ethernet does today.  A single =
bidirectional (in this case asymmetric BW capable) LSP.  In other words =
a single RSVP-TE session.  Several people have pointed out this is also =
achievable with two unidirectional RSVP-TE sessions (one at each end).  =
Rather than reopen that debate on this thread I will acknowledge the =
authors had a single session in mind more as a requirement of the =
technology.  Ethernet data forwarding is bi-directional symmetric and =
there are efficiencies in a single session of a bi-directional LSP.  On =
the other hand the issue is there is currently no way to specify the =
asymmetric BW. If you want to discuss the pros and cons of multiple =
sessions versus single there is already a thread on this (RE: I-D =
ACTION:draft-takacs-asym-bw-lsp-00.txt)

			=20

			|  2. How about other attributes? in particular LSP Protection & =
Recovery (P&R) related attributes?=20

			=20

			With respect to GMPLS, the plan was to allow bi-directional =
Protection or Recovery LSPs controlled by separate RSVP-TE sessions in =
separate from the single RSVP-TE session associated with the primary =
bidirectional LSP.  =20

				3. If P&R are indeed different, doesn't it make sense to route them =
separately (separate CSPF calculation at each end) and eventually signal =
them independently as well?=20

				=20

			Hopefully I addressed part of this already. Recovery of the =
bi-directional LSP could be handled by another RSVP-TE session & LSP.  =
The data plane in our case must have a bi-directional symmetric path so =
you can only do a CSPF at one end and/or force the paths to align.=20

				4. Is there a need for the forward and reverse flows to be on the =
same path?=20

				=20

			That is the way an Ethernet data plane works, and in my case this is =
where the requirement comes from. There is Ethernet data plane OAM and =
in some cases Ethernet forwarding rules that both require bi-directional =
symmetric paths.  The requirement is to be able to support native =
Ethernet loopback and data plane trace functions and bi-directional =
symmetry in the data plane is required.=20

				5. What is "fate sharing"? I couldn't find this in other RFCs or =
IDs. Is it same as link/node/SRLG disjoint paths?=20

				=20

			Yes it is related.  A shared resource link group identifies shared =
resources at some granularity. Fate shared paths have shared resources =
at a very high level of granularity.  Disjoint paths have none or very =
few shared resources.  For a bidirectional path the shared fate comes =
from the fact that both direction have common resources and if one fails =
the other is likely to fail.   =20

			=20

			Regards,

			Don=20

				=20

				Regards,

				=20

				Vijay

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
h1
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	mso-list:l6 level1 lfo1;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:normal;}
h2
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	mso-list:l6 level2 lfo1;
	font-size:16.0pt;
	font-family:Arial;
	font-weight:normal;}
h3
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	mso-list:l6 level3 lfo1;
	font-size:12.0pt;
	font-family:Arial;}
h4
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	mso-list:l6 level4 lfo1;
	font-size:11.0pt;
	font-family:Arial;}
h5
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:-34.65pt;
	margin-bottom:.0001pt;
	text-indent:-21.6pt;
	mso-list:l9 level5 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
h6
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:-27.45pt;
	margin-bottom:.0001pt;
	text-indent:-21.6pt;
	mso-list:l9 level6 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-20.25pt;
	text-indent:-14.4pt;
	mso-list:l9 level7 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-13.05pt;
	text-indent:-21.6pt;
	mso-list:l9 level8 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-style:italic;}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-5.85pt;
	text-indent:-7.2pt;
	mso-list:l9 level9 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc1, li.MsoToc1, div.MsoToc1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoToc2, li.MsoToc2, div.MsoToc2
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc3, li.MsoToc3, div.MsoToc3
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc6, li.MsoToc6, div.MsoToc6
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:60.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc7, li.MsoToc7, div.MsoToc7
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:72.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc8, li.MsoToc8, div.MsoToc8
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:84.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc9, li.MsoToc9, div.MsoToc9
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:96.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoFootnoteText, li.MsoFootnoteText, div.MsoFootnoteText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:6.0pt;
	font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoCaption, li.MsoCaption, div.MsoCaption
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.MsoTof, li.MsoTof, div.MsoTof
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoMacroText, li.MsoMacroText, div.MsoMacroText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l5 level1 lfo3;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListBullet, li.MsoListBullet, div.MsoListBullet
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l4 level1 lfo4;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListNumber, li.MsoListNumber, div.MsoListNumber
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:18.4pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l9 level1 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoList2, li.MsoList2, div.MsoList2
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:102.05pt;
	margin-bottom:.0001pt;
	text-indent:-36.85pt;
	mso-list:l1 level1 lfo5;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListBullet2, li.MsoListBullet2, div.MsoListBullet2
	{margin-top:11.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l0 level1 lfo6;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListNumber4, li.MsoListNumber4, div.MsoListNumber4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:60.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.0pt;
	mso-list:l7 level1 lfo7;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:0cm;
	font-size:24.0pt;
	font-family:Arial;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.contents, li.contents, div.contents
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:3.0cm;
	font-size:18.0pt;
	font-family:Arial;}
p.heading, li.heading, div.heading
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:14.0pt;
	margin-left:3.0cm;
	font-size:18.0pt;
	font-family:Arial;}
p.text, li.text, div.text
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.listnumbersingleline, li.listnumbersingleline, =
div.listnumbersingleline
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l2 level1 lfo8;
	font-size:11.0pt;
	font-family:Arial;}
p.listnumberdoubleline, li.listnumberdoubleline, =
div.listnumberdoubleline
	{margin-top:11.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l8 level1 lfo9;
	font-size:11.0pt;
	font-family:Arial;}
p.listabcsingleline, li.listabcsingleline, div.listabcsingleline
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l3 level1 lfo10;
	font-size:11.0pt;
	font-family:Arial;}
p.listabcdoubleline, li.listabcdoubleline, div.listabcdoubleline
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l5 level1 lfo3;
	font-size:11.0pt;
	font-family:Arial;}
p.programstyle, li.programstyle, div.programstyle
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Courier New";}
p.captionfigureexternal, li.captionfigureexternal, =
div.captionfigureexternal
	{margin-top:3.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.captionwide, li.captionwide, div.captionwide
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:2.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.columncaption, li.columncaption, div.columncaption
	{margin-top:3.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.footertext, li.footertext, div.footertext
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:Arial;}
p.note, li.note, div.note
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:124.75pt;
	margin-bottom:.0001pt;
	text-indent:-39.7pt;
	font-size:11.0pt;
	font-family:Arial;}
p.tablecaption, li.tablecaption, div.tablecaption
	{margin-top:16.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:2.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.tablecaptioncolumn, li.tablecaptioncolumn, div.tablecaptioncolumn
	{margin-top:16.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.tableheading, li.tableheading, div.tableheading
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.tabletext, li.tabletext, div.tabletext
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	font-size:10.0pt;
	font-family:Arial;}
p.indentedbodytext, li.indentedbodytext, div.indentedbodytext
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.blueindentedboldbodytext, li.blueindentedboldbodytext, =
div.blueindentedboldbodytext
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:blue;
	font-weight:bold;}
p.blueindentedtext, li.blueindentedtext, div.blueindentedtext
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:blue;}
p.term-list, li.term-list, div.term-list
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:7.0cm;
	margin-bottom:.0001pt;
	text-indent:-4.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.docname, li.docname, div.docname
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:18.0pt;
	font-family:Arial;}
p.pageno, li.pageno, div.pageno
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:9.0pt;
	font-family:Arial;}
p.subtitle, li.subtitle, div.subtitle
	{margin-top:10.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:12.0pt;
	font-family:Arial;}
p.docno, li.docno, div.docno
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:6.0pt;
	font-family:Arial;}
span.EmailStyle65
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle67
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:393165350;
	mso-list-template-ids:602855774;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:455372104;
	mso-list-template-ids:1483272396;}
@list l1:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:546721565;
	mso-list-template-ids:-1999329132;}
@list l2:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3
	{mso-list-id:627400466;
	mso-list-template-ids:609102906;}
@list l3:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l3:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4
	{mso-list-id:661390305;
	mso-list-template-ids:-616278678;}
@list l4:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l4:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5
	{mso-list-id:746610702;
	mso-list-template-ids:-1889231984;}
@list l5:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l5:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6
	{mso-list-id:1052387049;
	mso-list-template-ids:-192912764;}
@list l6:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l6:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7
	{mso-list-id:1367094927;
	mso-list-template-ids:-2065007732;}
@list l7:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l7:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8
	{mso-list-id:1532299202;
	mso-list-template-ids:-1327874638;}
@list l8:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l8:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9
	{mso-list-id:2010016537;
	mso-list-template-ids:-197371290;}
@list l9:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l9:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

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

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;color:navy'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Please see =
in line.<o:p></o:p></span></font></p>

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

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

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Pandian, Vijay
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 6 marzo =
2007 15.36<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Diego Caviglia =
(GA/ERI);
Attila Takacs (IJ/ETH); Don Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hi Diego,</span></font><font size=3D3 face=3D"Times =
New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Even for point 1.3, it is not clear why the two =
directions
of this LSP needs to be on the same (physical?) path.</span></font><font
size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;color:navy'>[dc] I not saying that they must be on or need to be =
on the
same path in order to work. =A0I&#8217;m saying if there is a =
requirement to have
upstream and downstream on the same path =
then&#8230;.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>=A0I may not understand the IpTv application, but =
isn't it
true that the direction where you need a small bandwidth probably is =
used to
send control messages such as &quot;channel change&quot; etc... In that
case,&nbsp;doesn't it make sense to&nbsp;use a completely different path =
with a
different QoS for a efficient network resource =
utilization?</span></font><font
size=3D2><span style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Assuming that we end up&nbsp;treating each direction =
as
independent sessions,&nbsp;can we use the&nbsp; GMPLS-CALL ID to =
correlate the
two connections? I assume the intermediate nodes don't care about such =
an
&quot;ASSOCIATEION&quot;.</span></font><font size=3D2><span =
style=3D'font-size:
10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;color:navy'>[dc] Yes <o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><font size=3D3 face=3D"Times =
New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Vijay</span></font><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Diego Caviglia =
(GA/ERI)
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, March 06, =
2007 6:30
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Attila Takacs =
(IJ/ETH);
Pandian, Vijay; Don Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Guys,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; let =
me try
to summarize what we have said so far:<o:p></o:p></span></font></p>

<p class=3DMsoListNumber><![if !supportLists]><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:11.0pt;color:blue'><span =
style=3D'mso-list:Ignore'>1.<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>1</span></font><font size=3D1 color=3Dblue =
face=3D"Times New Roman"><span
style=3D'font-size:7.0pt;font-family:"Times New =
Roman";color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblue><span style=3D'color:blue'>The basic =
idea behind
the ID is based on some facts (I hope we all agree that are facts =
</span></font><font
color=3Dblue face=3DWingdings><span =
style=3D'font-family:Wingdings;color:blue'>J</span></font><font
color=3Dblue><span style=3D'color:blue'>);<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>1.1</span></font><font size=3D1 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:7.0pt;font-family:"Times New Roman";
color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font =
color=3Dblue><span
style=3D'color:blue'>Ethernet services are (likely) bidirectional with =
asymmetric
bandwidth;<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>3.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>1.2</span></font><font size=3D1 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:7.0pt;font-family:"Times New Roman";
color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font =
color=3Dblue><span
style=3D'color:blue'>GMPLS now allows to set-up bi-directional LSP with
symmetrical bandwidth;<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>4.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>1.3</span></font><font size=3D1 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:7.0pt;font-family:"Times New Roman";
color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font =
color=3Dblue><span
style=3D'color:blue'>If, with the existing protocols, there is the need =
to set-up
a bi-directional service with asymmetric bandwidth requirement (e.g. =
IpTv) and
with upstream and downstream path that follow the same route we have to =
signal
two different LSPs using the RRO of the first one as strict ERO for the =
second
one. &nbsp;If we also want to bind the two LSPs in order to identify =
them as
part of the same service we can use the ASSOCIATON obj (modified I =
suppose)<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>5.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>1.4</span></font><font size=3D1 =
color=3Dblue
face=3D"Times New Roman"><span =
style=3D'font-size:7.0pt;font-family:"Times New Roman";
color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font =
color=3Dblue><span
style=3D'color:blue'>Likely (I would say very likely) the NMS that =
requests the
LSP(s) set-up knows in advance the bandwidth needed in the two =
directions.
&nbsp;So we are in a different situation w.r.t. the original RSVP
situation.&nbsp; We have all the information we need to set-up the LSP =
at the
Path processing<o:p></o:p></span></font></p>

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>6.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>Now if all of we are happy with point 1.3 then we =
have
finished. &nbsp;If someone think that is better to have the possibility =
to
set-up and identify a bidirectional service with a single LSP then the =
ID have
reason to exists at least for discussion </span></font><font =
color=3Dblue
face=3DWingdings><span =
style=3D'font-family:Wingdings;color:blue'>J</span></font><font
color=3Dblue><span style=3D'color:blue'>.<o:p></o:p></span></font></p>

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>7.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>IMHO having the possibility to set-up the LSP at =
the path
processing speed up the service establishment and this is particularly =
useful
in case of LSP rerouting in case of failure.&nbsp; In fact if the =
service is
made of the two LSP what could happens is the first one can be set-up =
and the
second one fails during signaling this means that first one have to be =
deleted
and two LSP path recomputed and re-signaled.&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>8.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>Best Regards<o:p></o:p></span></font></p>

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;color:blue'><span
style=3D'mso-list:Ignore'>9.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3Dblue><span
style=3D'font-size:10.0pt;color:blue'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>10.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>Diego &nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoListNumber style=3D'margin-left:0cm;text-indent:0cm'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;color:blue'><span
style=3D'mso-list:Ignore'>11.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3Dblue><span
style=3D'font-size:10.0pt;color:blue'><o:p>&nbsp;</o:p></span></font></p>=

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Attila Takacs (IJ/ETH)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 6 marzo =
2007 11.35<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Pandian, Vijay; Don =
Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hi Vijay,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>let me answer this. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>If you need different protection for each direction =
then you
likely will need differently routed LSPs. In this case one better uses =
separate
sessions for the two directions since all the benefits of having a =
single
session (like fate sharing) is gone if the LSPs take different =
routes.&nbsp;The
ID only&nbsp;proposes to relax the symmetrical bandwidth property of the
bidirectional LSP establishment given in =
RFC3471.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Attila</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Pandian, Vijay<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, March 06, =
2007 1:36
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Don Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Don,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>The question I had regarding P&amp;R was trying to =
figure
out if one direction required a better P&amp;R (say 1+1) and the reverse
direction&nbsp;probably&nbsp;required&nbsp;some basic P&amp;R
(say&nbsp;Re-routing).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>So the requirement is to use the same &quot;physical
link&quot; for the forward and reverse direction. Am I =
right?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Vijay</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Don Fedyk
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 6:41
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Pandian, Vijay;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hi Vijay</span></font><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> [email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Pandian, Vijay<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 2:07
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Hi,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>I
have some basic questions, primarily trying to understand the scope of =
this ID
as well as the application behind such a =
requirement.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>1.
Does this ID address just an asymmetric Bandwidth requirement?<font =
color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>The postulation was that GMPLS today supports =
bi-directional
service with a single RSVP-TE session creating a bidirectional =
LSP.&nbsp; The
most common implementation of this is Optical TDM =
networks.</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>&nbsp;<font color=3Dblue><span
style=3D'color:blue'> Since this was the starting point, the ID =
postulates
setting up an asymmetric service with a single&nbsp;asymmetric =
LSP.&nbsp; (Like
many new drafts it sets a requirement and postulates a an
implementation.)&nbsp;&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>So to your question besides =
bandwidth&nbsp;there&nbsp;is
also underlying requirement to align with GMPLS single session =
procedures and
support a bi-directional packet data plane as Ethernet does today.&nbsp; =
A
single bidirectional (in this case asymmetric BW capable) LSP.&nbsp; In =
other
words a single RSVP-TE session.&nbsp; Several people have pointed out =
this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).&nbsp; Rather than reopen that debate on this thread I will =
acknowledge
the authors&nbsp;had a single session in mind more as a requirement of =
the
technology. &nbsp;Ethernet data forwarding is bi-directional symmetric =
and
there are efficiencies in a single session of a bi-directional =
LSP.&nbsp; On
the other hand the issue is there is currently no way to specify the =
asymmetric
BW. If you want to discuss the pros and cons of multiple sessions versus =
single
there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>|</span></font><strong><b><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'> =
</span></font></b></strong><font
size=3D2 color=3Dblue><span =
style=3D'font-size:10.0pt;color:blue'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>2. How about other attributes? =
in
particular LSP Protection &amp; Recovery (P&amp;R) related =
attributes?<font
color=3Dblue><span =
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>With respect to GMPLS, the plan was to
allow&nbsp;bi-directional Protection or Recovery LSPs controlled by =
separate
RSVP-TE sessions in separate from&nbsp;the single RSVP-TE session =
associated
with the primary bidirectional LSP. &nbsp;</span></font><font =
size=3D2><span
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>3. If
P&amp;R are indeed different,&nbsp;doesn't&nbsp;it make sense =
to&nbsp;route
them separately (separate CSPF calculation at each end) and
eventually&nbsp;signal them independently as well?<font =
color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hopefully I addressed part of this already. Recovery =
of the
bi-directional LSP could be handled by another RSVP-TE session &amp; =
LSP.&nbsp;
The data plane in our case must have a bi-directional symmetric path so =
you can
only do a CSPF at one end and/or force the paths to =
align.&nbsp;</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>4. Is
there a need for the forward and reverse flows to be on the same =
path?<font
color=3Dblue><span =
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>That is the way an Ethernet data plane works, and in =
my case
this is where the requirement comes from. There is Ethernet data plane =
OAM and
in some cases Ethernet forwarding rules that both require bi-directional
symmetric paths.&nbsp; The requirement is to be able to support native =
Ethernet
loopback and data plane trace functions and bi-directional symmetry in =
the data
plane is required. </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>5.
What is &quot;fate sharing&quot;? I couldn't find this in other RFCs or =
IDs. Is
it same as link/node/SRLG disjoint paths?<font color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Yes it is related.&nbsp; A shared resource link group
identifies shared resources at some granularity. Fate shared paths have =
shared
resources at a very high level of granularity.&nbsp;&nbsp;Disjoint paths =
have
none or very few shared resources.&nbsp;&nbsp;For a bidirectional path =
the
shared fate comes from the fact that both direction have common =
resources and
if one fails the other is likely to =
fail.&nbsp;&nbsp;&nbsp;</span></font><font
size=3D2><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Don </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Vijay</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C75FFD.6668A822--

Delivery-date: Tue, 06 Mar 2007 14:36:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 09:35:38 -0500
From: "Pandian, Vijay" <[email-masked]>
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Diego,
=20
Even for point 1.3, it is not clear why the two directions of this LSP =
needs to be on the same (physical?) path. I may not understand the IpTv =
application, but isn't it true that the direction where you need a small =
bandwidth probably is used to send control messages such as "channel =
change" etc... In that case, doesn't it make sense to use a completely =
different path with a different QoS for a efficient network resource =
utilization?
=20
Assuming that we end up treating each direction as independent sessions, =
can we use the  GMPLS-CALL ID to correlate the two connections? I assume =
the intermediate nodes don't care about such an "ASSOCIATEION".
=20
Regards,
=20
Vijay

-----Original Message-----
From: Diego Caviglia (GA/ERI) [mailto:[email-masked]]
Sent: Tuesday, March 06, 2007 6:30 AM
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Guys,

         let me try to summarize what we have said so far:

1         The basic idea behind the ID is based on some facts (I hope we =
all agree that are facts :-));

1.1      Ethernet services are (likely) bidirectional with asymmetric =
bandwidth;

1.2      GMPLS now allows to set-up bi-directional LSP with symmetrical =
bandwidth;

1.3      If, with the existing protocols, there is the need to set-up a =
bi-directional service with asymmetric bandwidth requirement (e.g. IpTv) =
and with upstream and downstream path that follow the same route we have =
to signal two different LSPs using the RRO of the first one as strict =
ERO for the second one.  If we also want to bind the two LSPs in order =
to identify them as part of the same service we can use the ASSOCIATON =
obj (modified I suppose)

1.4      Likely (I would say very likely) the NMS that requests the =
LSP(s) set-up knows in advance the bandwidth needed in the two =
directions.  So we are in a different situation w.r.t. the original RSVP =
situation.  We have all the information we need to set-up the LSP at the =
Path processing

Now if all of we are happy with point 1.3 then we have finished.  If =
someone think that is better to have the possibility to set-up and =
identify a bidirectional service with a single LSP then the ID have =
reason to exists at least for discussion :-).

IMHO having the possibility to set-up the LSP at the path processing =
speed up the service establishment and this is particularly useful in =
case of LSP rerouting in case of failure.  In fact if the service is =
made of the two LSP what could happens is the first one can be set-up =
and the second one fails during signaling this means that first one have =
to be deleted and two LSP path recomputed and re-signaled. =20

Best Regards

=20

Diego =20

=20

=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs (IJ/ETH)
Sent: marted=EC 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

=20

Hi Vijay,

=20

let me answer this.=20

=20

If you need different protection for each direction then you likely will =
need differently routed LSPs. In this case one better uses separate =
sessions for the two directions since all the benefits of having a =
single session (like fate sharing) is gone if the LSPs take different =
routes. The ID only proposes to relax the symmetrical bandwidth property =
of the bidirectional LSP establishment given in RFC3471.

=20

Regards,

Attila

=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

=20

The question I had regarding P&R was trying to figure out if one =
direction required a better P&R (say 1+1) and the reverse direction =
probably required some basic P&R (say Re-routing).

=20

So the requirement is to use the same "physical link" for the forward =
and reverse direction. Am I right?

=20

Regards,

=20

Vijay

=20

=20

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi,

=20

I have some basic questions, primarily trying to understand the scope of =
this ID as well as the application behind such a requirement.

=20

1. Does this ID address just an asymmetric Bandwidth requirement?=20

The postulation was that GMPLS today supports bi-directional service =
with a single RSVP-TE session creating a bidirectional LSP.  The most =
common implementation of this is Optical TDM networks.  Since this was =
the starting point, the ID postulates setting up an asymmetric service =
with a single asymmetric LSP.  (Like many new drafts it sets a =
requirement and postulates a an implementation.) =20

=20

So to your question besides bandwidth there is also underlying =
requirement to align with GMPLS single session procedures and support a =
bi-directional packet data plane as Ethernet does today.  A single =
bidirectional (in this case asymmetric BW capable) LSP.  In other words =
a single RSVP-TE session.  Several people have pointed out this is also =
achievable with two unidirectional RSVP-TE sessions (one at each end).  =
Rather than reopen that debate on this thread I will acknowledge the =
authors had a single session in mind more as a requirement of the =
technology.  Ethernet data forwarding is bi-directional symmetric and =
there are efficiencies in a single session of a bi-directional LSP.  On =
the other hand the issue is there is currently no way to specify the =
asymmetric BW. If you want to discuss the pros and cons of multiple =
sessions versus single there is already a thread on this (RE: I-D =
ACTION:draft-takacs-asym-bw-lsp-00.txt)

=20

|  2. How about other attributes? in particular LSP Protection & =
Recovery (P&R) related attributes?=20

=20

With respect to GMPLS, the plan was to allow bi-directional Protection =
or Recovery LSPs controlled by separate RSVP-TE sessions in separate =
from the single RSVP-TE session associated with the primary =
bidirectional LSP.  =20

3. If P&R are indeed different, doesn't it make sense to route them =
separately (separate CSPF calculation at each end) and eventually signal =
them independently as well?=20

=20

Hopefully I addressed part of this already. Recovery of the =
bi-directional LSP could be handled by another RSVP-TE session & LSP.  =
The data plane in our case must have a bi-directional symmetric path so =
you can only do a CSPF at one end and/or force the paths to align.=20

4. Is there a need for the forward and reverse flows to be on the same =
path?=20

=20

That is the way an Ethernet data plane works, and in my case this is =
where the requirement comes from. There is Ethernet data plane OAM and =
in some cases Ethernet forwarding rules that both require bi-directional =
symmetric paths.  The requirement is to be able to support native =
Ethernet loopback and data plane trace functions and bi-directional =
symmetry in the data plane is required.=20

5. What is "fate sharing"? I couldn't find this in other RFCs or IDs. Is =
it same as link/node/SRLG disjoint paths?=20

=20

Yes it is related.  A shared resource link group identifies shared =
resources at some granularity. Fate shared paths have shared resources =
at a very high level of granularity.  Disjoint paths have none or very =
few shared resources.  For a bidirectional path the shared fate comes =
from the fact that both direction have common resources and if one fails =
the other is likely to fail.   =20

=20

Regards,

Don=20

=20

Regards,

=20

Vijay

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: PMingLiU;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Times;
}
@font-face {
	font-family: @PMingLiU;
}
@font-face {
	font-family: MS PGothic;
}
@font-face {
	font-family: ar;
}
@font-face {
	font-family: @MS PGothic;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; }
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
H1 {
	FONT-WEIGHT: normal; FONT-SIZE: 20pt; MARGIN: 24pt 0cm 0pt 3cm; =
TEXT-INDENT: -3cm; FONT-FAMILY: Arial; mso-list: l7 level1 lfo14
}
H2 {
	FONT-WEIGHT: normal; FONT-SIZE: 16pt; MARGIN: 24pt 0cm 0pt 3cm; =
TEXT-INDENT: -3cm; FONT-FAMILY: Arial; mso-list: l7 level2 lfo14
}
H3 {
	FONT-SIZE: 12pt; MARGIN: 24pt 0cm 0pt 3cm; TEXT-INDENT: -3cm; =
FONT-FAMILY: Arial; mso-list: l7 level3 lfo14
}
H4 {
	FONT-SIZE: 11pt; MARGIN: 24pt 0cm 0pt 3cm; TEXT-INDENT: -3cm; =
FONT-FAMILY: Arial; mso-list: l7 level4 lfo14
}
H5 {
	FONT-SIZE: 11pt; MARGIN: 24pt 0cm 0pt -34.65pt; TEXT-INDENT: -21.6pt; =
FONT-FAMILY: Arial; mso-list: l20 level5 lfo7
}
H6 {
	FONT-SIZE: 11pt; MARGIN: 24pt 0cm 0pt -27.45pt; TEXT-INDENT: -21.6pt; =
FONT-FAMILY: Arial; mso-list: l20 level6 lfo7
}
P.MsoHeading7 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 24pt 0cm 3pt -20.25pt; =
TEXT-INDENT: -14.4pt; FONT-FAMILY: Arial; mso-list: l20 level7 lfo7
}
LI.MsoHeading7 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 24pt 0cm 3pt -20.25pt; =
TEXT-INDENT: -14.4pt; FONT-FAMILY: Arial; mso-list: l20 level7 lfo7
}
DIV.MsoHeading7 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 24pt 0cm 3pt -20.25pt; =
TEXT-INDENT: -14.4pt; FONT-FAMILY: Arial; mso-list: l20 level7 lfo7
}
P.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0cm 3pt -13.05pt; TEXT-INDENT: -21.6pt; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-list: l20 level8 =
lfo7
}
LI.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0cm 3pt -13.05pt; TEXT-INDENT: -21.6pt; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-list: l20 level8 =
lfo7
}
DIV.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0cm 3pt -13.05pt; TEXT-INDENT: -21.6pt; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-list: l20 level8 =
lfo7
}
P.MsoHeading9 {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 3pt -5.85pt; TEXT-INDENT: -7.2pt; =
FONT-FAMILY: Arial; mso-list: l20 level9 lfo7
}
LI.MsoHeading9 {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 3pt -5.85pt; TEXT-INDENT: -7.2pt; =
FONT-FAMILY: Arial; mso-list: l20 level9 lfo7
}
DIV.MsoHeading9 {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 3pt -5.85pt; TEXT-INDENT: -7.2pt; =
FONT-FAMILY: Arial; mso-list: l20 level9 lfo7
}
P.MsoToc1 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 5cm; =
TEXT-INDENT: -2cm; FONT-FAMILY: Arial
}
LI.MsoToc1 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 5cm; =
TEXT-INDENT: -2cm; FONT-FAMILY: Arial
}
DIV.MsoToc1 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 5cm; =
TEXT-INDENT: -2cm; FONT-FAMILY: Arial
}
P.MsoToc2 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
LI.MsoToc2 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
DIV.MsoToc2 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
P.MsoToc3 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
LI.MsoToc3 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
DIV.MsoToc3 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
P.MsoToc4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
LI.MsoToc4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
DIV.MsoToc4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 5cm; TEXT-INDENT: -2cm; =
FONT-FAMILY: Arial
}
P.MsoToc5 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: Arial
}
LI.MsoToc5 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: Arial
}
DIV.MsoToc5 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: Arial
}
P.MsoToc6 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60pt; FONT-FAMILY: Arial
}
LI.MsoToc6 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60pt; FONT-FAMILY: Arial
}
DIV.MsoToc6 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60pt; FONT-FAMILY: Arial
}
P.MsoToc7 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 72pt; FONT-FAMILY: Arial
}
LI.MsoToc7 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 72pt; FONT-FAMILY: Arial
}
DIV.MsoToc7 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 72pt; FONT-FAMILY: Arial
}
P.MsoToc8 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 84pt; FONT-FAMILY: Arial
}
LI.MsoToc8 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 84pt; FONT-FAMILY: Arial
}
DIV.MsoToc8 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 84pt; FONT-FAMILY: Arial
}
P.MsoToc9 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 96pt; FONT-FAMILY: Arial
}
LI.MsoToc9 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 96pt; FONT-FAMILY: Arial
}
DIV.MsoToc9 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 96pt; FONT-FAMILY: Arial
}
P.MsoFootnoteText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
LI.MsoFootnoteText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
DIV.MsoFootnoteText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
P.MsoHeader {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
LI.MsoHeader {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
DIV.MsoHeader {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
P.MsoFooter {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
LI.MsoFooter {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
DIV.MsoFooter {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
P.MsoCaption {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
LI.MsoCaption {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
DIV.MsoCaption {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
P.MsoTof {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 12pt; FONT-FAMILY: Arial
}
LI.MsoTof {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 12pt; FONT-FAMILY: Arial
}
DIV.MsoTof {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 12pt; FONT-FAMILY: Arial
}
P.MsoMacroText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoMacroText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoMacroText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
P.MsoList {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
LI.MsoList {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
DIV.MsoList {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
P.MsoListBullet {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l13 level1 lfo3
}
LI.MsoListBullet {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l13 level1 lfo3
}
DIV.MsoListBullet {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l13 level1 lfo3
}
P.MsoListNumber {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 18.4pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l20 level1 lfo7
}
LI.MsoListNumber {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 18.4pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l20 level1 lfo7
}
DIV.MsoListNumber {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 18.4pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l20 level1 lfo7
}
P.MsoList2 {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 102.05pt; TEXT-INDENT: -36.85pt; =
FONT-FAMILY: Arial; mso-list: l18 level1 lfo8
}
LI.MsoList2 {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 102.05pt; TEXT-INDENT: -36.85pt; =
FONT-FAMILY: Arial; mso-list: l18 level1 lfo8
}
DIV.MsoList2 {
	FONT-SIZE: 11pt; MARGIN: 9pt 0cm 0pt 102.05pt; TEXT-INDENT: -36.85pt; =
FONT-FAMILY: Arial; mso-list: l18 level1 lfo8
}
P.MsoListBullet2 {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l23 level1 lfo5
}
LI.MsoListBullet2 {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l23 level1 lfo5
}
DIV.MsoListBullet2 {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l23 level1 lfo5
}
P.MsoListNumber4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60.45pt; TEXT-INDENT: -18pt; =
FONT-FAMILY: Arial; mso-list: l1 level1 lfo45
}
LI.MsoListNumber4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60.45pt; TEXT-INDENT: -18pt; =
FONT-FAMILY: Arial; mso-list: l1 level1 lfo45
}
DIV.MsoListNumber4 {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 60.45pt; TEXT-INDENT: -18pt; =
FONT-FAMILY: Arial; mso-list: l1 level1 lfo45
}
P.MsoTitle {
	FONT-SIZE: 24pt; MARGIN: 12pt 0cm; TEXT-INDENT: 0cm; FONT-FAMILY: Arial
}
LI.MsoTitle {
	FONT-SIZE: 24pt; MARGIN: 12pt 0cm; TEXT-INDENT: 0cm; FONT-FAMILY: Arial
}
DIV.MsoTitle {
	FONT-SIZE: 24pt; MARGIN: 12pt 0cm; TEXT-INDENT: 0cm; FONT-FAMILY: Arial
}
P.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 3cm; FONT-FAMILY: Arial
}
LI.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 3cm; FONT-FAMILY: Arial
}
DIV.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 3cm; FONT-FAMILY: Arial
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
P.Contents {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 12pt 3cm; FONT-FAMILY: Arial
}
LI.Contents {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 12pt 3cm; FONT-FAMILY: Arial
}
DIV.Contents {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 12pt 3cm; FONT-FAMILY: Arial
}
P.Heading {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 14pt 3cm; FONT-FAMILY: Arial
}
LI.Heading {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 14pt 3cm; FONT-FAMILY: Arial
}
DIV.Heading {
	FONT-SIZE: 18pt; MARGIN: 24pt 0cm 14pt 3cm; FONT-FAMILY: Arial
}
P.Text {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: Arial
}
LI.Text {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: Arial
}
DIV.Text {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: Arial
}
P.Listnumbersingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l28 level1 lfo36
}
LI.Listnumbersingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l28 level1 lfo36
}
DIV.Listnumbersingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.5pt; TEXT-INDENT: -18.45pt; =
FONT-FAMILY: Arial; mso-list: l28 level1 lfo36
}
P.Listnumberdoubleline {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l29 level1 lfo11
}
LI.Listnumberdoubleline {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l29 level1 lfo11
}
DIV.Listnumberdoubleline {
	FONT-SIZE: 11pt; MARGIN: 11pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l29 level1 lfo11
}
P.Listabcsingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l27 level1 lfo12
}
LI.Listabcsingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l27 level1 lfo12
}
DIV.Listabcsingleline {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l27 level1 lfo12
}
P.Listabcdoubleline {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
LI.Listabcdoubleline {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
DIV.Listabcdoubleline {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 103.45pt; TEXT-INDENT: -18.4pt; =
FONT-FAMILY: Arial; mso-list: l9 level1 lfo13
}
P.ProgramStyle {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: "Courier New"
}
LI.ProgramStyle {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: "Courier New"
}
DIV.ProgramStyle {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt 3cm; FONT-FAMILY: "Courier New"
}
P.CaptionFigureExternal {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt; FONT-STYLE: italic; FONT-FAMILY: =
Arial
}
LI.CaptionFigureExternal {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt; FONT-STYLE: italic; FONT-FAMILY: =
Arial
}
DIV.CaptionFigureExternal {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt; FONT-STYLE: italic; FONT-FAMILY: =
Arial
}
P.Captionwide {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
LI.Captionwide {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
DIV.Captionwide {
	FONT-SIZE: 11pt; MARGIN: 6pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
P.ColumnCaption {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
LI.ColumnCaption {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
DIV.ColumnCaption {
	FONT-SIZE: 11pt; MARGIN: 3pt 0cm 6pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
P.FooterText {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
LI.FooterText {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
DIV.FooterText {
	FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial
}
P.Note {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 124.75pt; TEXT-INDENT: -39.7pt; =
FONT-FAMILY: Arial
}
LI.Note {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 124.75pt; TEXT-INDENT: -39.7pt; =
FONT-FAMILY: Arial
}
DIV.Note {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 124.75pt; TEXT-INDENT: -39.7pt; =
FONT-FAMILY: Arial
}
P.TableCaption {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
LI.TableCaption {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
DIV.TableCaption {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 2cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
P.TableCaptionColumn {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
LI.TableCaptionColumn {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
DIV.TableCaptionColumn {
	FONT-SIZE: 11pt; MARGIN: 16pt 0cm 3pt 5cm; TEXT-INDENT: -2cm; =
FONT-STYLE: italic; FONT-FAMILY: Arial
}
P.TableHeading {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
LI.TableHeading {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
DIV.TableHeading {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
P.TableText {
	FONT-SIZE: 10pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
LI.TableText {
	FONT-SIZE: 10pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
DIV.TableText {
	FONT-SIZE: 10pt; MARGIN: 4pt 0cm; FONT-FAMILY: Arial
}
P.IndentedBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; FONT-FAMILY: Arial
}
LI.IndentedBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; FONT-FAMILY: Arial
}
DIV.IndentedBodyText {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; FONT-FAMILY: Arial
}
P.BlueIndentedBoldBodyText {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; COLOR: =
blue; FONT-FAMILY: Arial
}
LI.BlueIndentedBoldBodyText {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; COLOR: =
blue; FONT-FAMILY: Arial
}
DIV.BlueIndentedBoldBodyText {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 4cm; COLOR: =
blue; FONT-FAMILY: Arial
}
P.BlueIndentedText {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 4cm; COLOR: blue; FONT-FAMILY: =
Arial
}
LI.BlueIndentedText {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 4cm; COLOR: blue; FONT-FAMILY: =
Arial
}
DIV.BlueIndentedText {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt 4cm; COLOR: blue; FONT-FAMILY: =
Arial
}
P.Term-list {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 7cm; TEXT-INDENT: -4cm; =
FONT-FAMILY: Arial
}
LI.Term-list {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 7cm; TEXT-INDENT: -4cm; =
FONT-FAMILY: Arial
}
DIV.Term-list {
	FONT-SIZE: 11pt; MARGIN: 12pt 0cm 0pt 7cm; TEXT-INDENT: -4cm; =
FONT-FAMILY: Arial
}
P.DocName {
	FONT-SIZE: 18pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
LI.DocName {
	FONT-SIZE: 18pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
DIV.DocName {
	FONT-SIZE: 18pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
P.PageNo {
	FONT-SIZE: 9pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
LI.PageNo {
	FONT-SIZE: 9pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
DIV.PageNo {
	FONT-SIZE: 9pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
P.SubTitle {
	FONT-SIZE: 12pt; MARGIN: 10pt 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
LI.SubTitle {
	FONT-SIZE: 12pt; MARGIN: 10pt 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
DIV.SubTitle {
	FONT-SIZE: 12pt; MARGIN: 10pt 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
P.DocNo {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
LI.DocNo {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
DIV.DocNo {
	FONT-SIZE: 6pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: Arial; TEXT-ALIGN: =
right
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D463351814-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Diego,</FONT></SPAN></DIV>
<DIV><SPAN class=3D463351814-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D463351814-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>Even=20
for point 1.3, it is not clear why the two directions of this LSP needs =
to be on=20
the same (physical?) path. I may not understand the IpTv application, =
but isn't=20
it true that the direction where you need a small bandwidth probably is =
used to=20
send control messages such as "channel change" etc... In that =
case,&nbsp;doesn't=20
it make sense to&nbsp;use a completely different path with a different =
QoS for a=20
efficient network resource utilization?</FONT></SPAN></DIV>
<DIV><SPAN class=3D463351814-06032007><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Assuming that we end up&nbsp;treating each direction as =
independent=20
sessions,&nbsp;can we use the&nbsp; GMPLS-CALL ID to correlate the two=20
connections? I assume the intermediate nodes don't care about such an=20
"ASSOCIATEION".</FONT></SPAN></DIV>
<DIV><SPAN class=3D463351814-06032007><FONT face=3DArial color=3D#0000ff =

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

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

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

size=3D2>Vijay</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Diego Caviglia =
(GA/ERI)=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, March =
06, 2007=20
  6:30 AM<BR><B>To:</B> Attila Takacs (IJ/ETH); Pandian, Vijay; Don=20
  Fedyk<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Questions on=20
  draft-takacs-asym-bw-lsp-00.txt<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Guys,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
blue">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  let me try to summarize what we have said so =
far:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber><![if !supportLists]><FONT face=3DArial =
color=3Dblue=20
  size=3D2><SPAN style=3D"FONT-SIZE: 11pt; COLOR: blue"><SPAN=20
  style=3D"mso-list: Ignore">1<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dblue><SPAN=20
  style=3D"COLOR: blue">The basic idea behind the ID is based on some =
facts (I=20
  hope we all agree that are facts </SPAN></FONT><FONT face=3DWingdings=20
  color=3Dblue><SPAN=20
  style=3D"COLOR: blue; FONT-FAMILY: Wingdings">J</SPAN></FONT><FONT=20
  color=3Dblue><SPAN style=3D"COLOR: =
blue">);<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber style=3D"MARGIN-LEFT: 42.5pt; TEXT-INDENT: =
-24.1pt"><![if !supportLists]><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; =
COLOR: blue"><SPAN=20
  style=3D"mso-list: Ignore">1.1<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dblue><SPAN=20
  style=3D"COLOR: blue">Ethernet services are (likely) bidirectional =
with=20
  asymmetric bandwidth;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber style=3D"MARGIN-LEFT: 42.5pt; TEXT-INDENT: =
-24.1pt"><![if !supportLists]><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; =
COLOR: blue"><SPAN=20
  style=3D"mso-list: Ignore">1.2<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dblue><SPAN=20
  style=3D"COLOR: blue">GMPLS now allows to set-up bi-directional LSP =
with=20
  symmetrical bandwidth;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber style=3D"MARGIN-LEFT: 42.5pt; TEXT-INDENT: =
-24.1pt"><![if !supportLists]><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; =
COLOR: blue"><SPAN=20
  style=3D"mso-list: Ignore">1.3<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dblue><SPAN=20
  style=3D"COLOR: blue">If, with the existing protocols, there is the =
need to=20
  set-up a bi-directional service with asymmetric bandwidth requirement =
(e.g.=20
  IpTv) and with upstream and downstream path that follow the same route =
we have=20
  to signal two different LSPs using the RRO of the first one as strict =
ERO for=20
  the second one. &nbsp;If we also want to bind the two LSPs in order to =

  identify them as part of the same service we can use the ASSOCIATON =
obj=20
  (modified I suppose)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber style=3D"MARGIN-LEFT: 42.5pt; TEXT-INDENT: =
-24.1pt"><![if !supportLists]><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; =
COLOR: blue"><SPAN=20
  style=3D"mso-list: Ignore">1.4<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dblue><SPAN=20
  style=3D"COLOR: blue">Likely (I would say very likely) the NMS that =
requests the=20
  LSP(s) set-up knows in advance the bandwidth needed in the two =
directions.=20
  &nbsp;So we are in a different situation w.r.t. the original RSVP=20
  situation.&nbsp; We have all the information we need to set-up the LSP =
at the=20
  Path processing<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; COLOR: blue">Now =
if all of we=20
  are happy with point 1.3 then we have finished. &nbsp;If someone think =
that is=20
  better to have the possibility to set-up and identify a bidirectional =
service=20
  with a single LSP then the ID have reason to exists at least for =
discussion=20
  </SPAN></FONT><FONT face=3DWingdings color=3Dblue><SPAN=20
  style=3D"COLOR: blue; FONT-FAMILY: Wingdings">J</SPAN></FONT><FONT=20
  color=3Dblue><SPAN style=3D"COLOR: =
blue">.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; COLOR: =
blue">IMHO having the=20
  possibility to set-up the LSP at the path processing speed up the =
service=20
  establishment and this is particularly useful in case of LSP rerouting =
in case=20
  of failure.&nbsp; In fact if the service is made of the two LSP what =
could=20
  happens is the first one can be set-up and the second one fails during =

  signaling this means that first one have to be deleted and two LSP =
path=20
  recomputed and re-signaled.&nbsp; <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; COLOR: =
blue">Best=20
  Regards<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><o:p>&nbsp;</o:p></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN style=3D"FONT-SIZE: 11pt; COLOR: =
blue">Diego=20
  &nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoListNumber=20
  style=3D"MARGIN-LEFT: 0cm; TEXT-INDENT: 0cm; mso-list: none"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><o:p>&nbsp;</o:p></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
blue"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT face=3DArial=20
  size=3D2><SPAN style=3D"FONT-SIZE: 11pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Attila Takacs=20
  (IJ/ETH)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
marted=EC 6=20
  marzo 2007 11.35<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B> Pandian,=20
  Vijay; Don Fedyk<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: Questions on=20
  draft-takacs-asym-bw-lsp-00.txt</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial =
size=3D2><o:p>&nbsp;</o:p></FONT></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue">Hi=20
  Vijay,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue">let me answer this.=20
  </SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue">If you need different =
protection for each=20
  direction then you likely will need differently routed LSPs. In this =
case one=20
  better uses separate sessions for the two directions since all the =
benefits of=20
  having a single session (like fate sharing) is gone if the LSPs take =
different=20
  routes.&nbsp;The ID only&nbsp;proposes to relax the symmetrical =
bandwidth=20
  property of the bidirectional LSP establishment given in=20
  RFC3471.</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Attila</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT face=3DArial=20
  size=3D2><SPAN style=3D"FONT-SIZE: 11pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
  size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Pandian, =
Vijay<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, March 06, 2007 =
1:36=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Don =
Fedyk<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> =
[email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Questions on=20
  draft-takacs-asym-bw-lsp-00.txt</SPAN></FONT><o:p></o:p></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none">
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Don,</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue">The question I had regarding =
P&amp;R=20
    was trying to figure out if one direction required a better P&amp;R =
(say=20
    1+1) and the reverse direction&nbsp;probably&nbsp;required&nbsp;some =
basic=20
    P&amp;R (say&nbsp;Re-routing).</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue">So the requirement is to use =
the same=20
    "physical link" for the forward and reverse direction. Am I=20
    right?</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Vijay</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0cm"><P=20
      class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3DTahoma size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
      Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B> Don=20
      Fedyk [mailto:[email-masked]]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, March 05, =
2007 6:41=20
      PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Pandian, =
Vijay;=20
      [email-masked]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Questions on=20
      draft-takacs-asym-bw-lsp-00.txt</SPAN></FONT><o:p></o:p></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">Hi =
Vijay</SPAN></FONT><o:p></o:p></P>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <P class=3DMsoNormal><FONT face=3DArial =
size=3D2><o:p>&nbsp;</o:p></FONT></P>
        <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
        face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 11pt">
        <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
        </SPAN></FONT></DIV>
        <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
        size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
        face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Tahoma">=20
        [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
        style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Pandian,=20
        Vijay<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Monday,=20
        March 05, 2007 2:07 PM<BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
[email-masked]<BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Questions on=20
        draft-takacs-asym-bw-lsp-00.txt</SPAN></FONT><o:p></o:p></P>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">Hi,</SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">I have some basic questions, primarily =
trying to=20
        understand the scope of this ID as well as the application =
behind such a=20
        requirement.</SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">1. Does this ID address just an =
asymmetric=20
        Bandwidth requirement?<FONT color=3Dblue><SPAN=20
        style=3D"COLOR: =
blue">&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOC=
KQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">The postulation was that =
GMPLS today=20
      supports bi-directional service with a single RSVP-TE session =
creating a=20
      bidirectional LSP.&nbsp; The most common implementation of this is =
Optical=20
      TDM networks.</SPAN></FONT><FONT size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt">&nbsp;<FONT color=3Dblue><SPAN =
style=3D"COLOR: blue">=20
      Since this was the starting point, the ID postulates setting up an =

      asymmetric service with a single&nbsp;asymmetric LSP.&nbsp; (Like =
many new=20
      drafts it sets a requirement and postulates a an=20
      =
implementation.)&nbsp;&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></=
DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">So to your question besides =

      bandwidth&nbsp;there&nbsp;is also underlying requirement to align =
with=20
      GMPLS single session procedures and support a bi-directional =
packet data=20
      plane as Ethernet does today.&nbsp; A single bidirectional (in =
this case=20
      asymmetric BW capable) LSP.&nbsp; In other words a single RSVP-TE=20
      session.&nbsp; Several people have pointed out this is also =
achievable=20
      with two unidirectional RSVP-TE sessions (one at each end).&nbsp; =
Rather=20
      than reopen that debate on this thread I will acknowledge the=20
      authors&nbsp;had a single session in mind more as a requirement of =
the=20
      technology. &nbsp;Ethernet data forwarding is bi-directional =
symmetric and=20
      there are efficiencies in a single session of a bi-directional =
LSP.&nbsp;=20
      On the other hand the issue is there is currently no way to =
specify the=20
      asymmetric BW. If you want to discuss the pros and cons of =
multiple=20
      sessions versus single there is already a thread on this (RE: I-D=20
      =
ACTION:draft-takacs-asym-bw-lsp-00.txt)</SPAN></FONT><o:p></o:p></P></DIV=
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: =
blue">|</SPAN></FONT><STRONG><B><FONT=20
      face=3DArial color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">=20
      </SPAN></FONT></B></STRONG><FONT color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">&nbsp;</SPAN></FONT><FONT=20
      size=3D2><SPAN style=3D"FONT-SIZE: 10pt">2. How about other =
attributes? in=20
      particular LSP Protection &amp; Recovery (P&amp;R) related=20
      attributes?<FONT color=3Dblue><SPAN=20
      style=3D"COLOR: =
blue">&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">With respect to GMPLS, the =
plan was=20
      to allow&nbsp;bi-directional Protection or Recovery LSPs =
controlled by=20
      separate RSVP-TE sessions in separate from&nbsp;the single RSVP-TE =
session=20
      associated with the primary bidirectional LSP. =
&nbsp;</SPAN></FONT><FONT=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">3. If P&amp;R are indeed=20
        different,&nbsp;doesn't&nbsp;it make sense to&nbsp;route them =
separately=20
        (separate CSPF calculation at each end) and =
eventually&nbsp;signal them=20
        independently as well?<FONT color=3Dblue><SPAN=20
        style=3D"COLOR: =
blue">&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">Hopefully I addressed part =
of this=20
      already. Recovery of the bi-directional LSP could be handled by =
another=20
      RSVP-TE session &amp; LSP.&nbsp; The data plane in our case must =
have a=20
      bi-directional symmetric path so you can only do a CSPF at one end =
and/or=20
      force the paths to align.&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">4. Is there a need for the forward and =
reverse=20
        flows to be on the same path?<FONT color=3Dblue><SPAN=20
        style=3D"COLOR: =
blue">&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">That is the way an Ethernet =
data=20
      plane works, and in my case this is where the requirement comes =
from.=20
      There is Ethernet data plane OAM and in some cases Ethernet =
forwarding=20
      rules that both require bi-directional symmetric paths.&nbsp; The=20
      requirement is to be able to support native Ethernet loopback and =
data=20
      plane trace functions and bi-directional symmetry in the data =
plane is=20
      required. </SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt">5. What is "fate sharing"? I couldn't =
find this=20
        in other RFCs or IDs. Is it same as link/node/SRLG disjoint =
paths?<FONT=20
        color=3Dblue><SPAN=20
        style=3D"COLOR: =
blue">&nbsp;</SPAN></FONT></SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">Yes it is related.&nbsp; A =
shared=20
      resource link group identifies shared resources at some =
granularity. Fate=20
      shared paths have shared resources at a very high level of=20
      granularity.&nbsp;&nbsp;Disjoint paths have none or very few =
shared=20
      resources.&nbsp;&nbsp;For a bidirectional path the shared fate =
comes from=20
      the fact that both direction have common resources and if one =
fails the=20
      other is likely to fail.&nbsp;&nbsp;&nbsp;</SPAN></FONT><FONT =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: =
blue">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue">Don=20
      </SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
10pt">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
        style=3D"FONT-SIZE: =
10pt">Vijay</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C75FFC.B542D7E0--

Delivery-date: Tue, 06 Mar 2007 11:45:14 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 12:45:04 +0100
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Adrian,
          Some comments in line

Best Regards

Diego

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
Sent: marted=EC 6 marzo 2007 12.05
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: What is this fate sharing thing? [Was: Questions on =
draft-takacs-asym-bw-lsp-00.txt]

Hi,

There has been a lot of discussion about "fate-sharing" and I am not =
sure=20
what problem we are trying to solve.
[dc] As usual you and Vijay, make a point :-) I also think we need to =
clarify what is fate sharing.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?
[dc] I think here you are talking about the so called ALS (Automatic =
Laser Shutdown) there should b some ITU-T recc about this.  I sorry I =
forgot the number.

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) =
obviously=20
makes control plane fate-sharing automatic, but the use of associated=20
signaling does not preclude control plane fate sharing - it just needs=20
additional message exchanges.

The use of an identical path for both directions can provide some =
elements=20
of data plane fate sharing, but it is important to note that it does not =

guarantee it.=20
[dc] Yes my understanding of the fate sharing is that upstream and =
downstream LSP must follow the same path.=20

For example, a unidirectional fiber could fail. This issue is=20
not impacted by bidirectional or associated signaling as the directions =
can=20
be installed on the path by associated signaling, and as a failure might =

only impact one direction in bidirectional signaling.
[dc] Here is where ALS should come in the field.  If the fibre is broken =
in one direction the ALS should shutdown the laser associated to the =
other direction. =20
=20
 -------X----->
A              B =20
 <------------S
That is X is a failure (LOL), as soon B detects the loss of light due to =
the ALS is shutdown the laser (S in the picture) towards A

End-to-end protection features are implemented at a different level and =
seem=20
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of=20
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?
[dc] I've tried to make a summary of the point discussed so far in an =
another mail

Adrian

----- Original Message -----=20
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk"=20
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>RE: What is this fate sharing thing? [Was: Questions on =
draft-takacs-asym-bw-lsp-00.txt]</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Adrian,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Some =
comments in line</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Best Regards</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Diego</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>] On Behalf Of Adrian Farrel<BR>
Sent: marted=EC 6 marzo 2007 12.05<BR>
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk<BR>
Cc: [email-masked]<BR>
Subject: What is this fate sharing thing? [Was: Questions on =
draft-takacs-asym-bw-lsp-00.txt]</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">There has been a lot of discussion about &quot;fate-sharing&quot; =
and I am not sure </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">what problem we are trying to solve.</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[dc] As usual you</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">and Vijay,</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">make a =
point</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT FACE=3D"Wingdings" =
SIZE=3D2>J</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">I</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"> =
also think we need to clarify what is fate sharing.</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">- Is this a data plane feature where a data plane fault in =
one</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp; direction must cause data plane interruption in both =
directions?</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[dc]</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">I think here you are =
talking about the so called ALS (Automatic Laser =
Shutdown)</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New">there should b some ITU-T recc about =
this.</FONT></SPAN><SPAN LANG=3D"en-gb">&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New"> I sorry I forgot the =
number.</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">- Is this a protection feature where the switch-over of =
one</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp; direction to its backup path must be accompanied by =
a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp; switch-over of the other direction, too?</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">- Is this a control plane feature where the removal of =
control</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp; plane state in one direction must cause the removal of =
control</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp; plane state in the other direction?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">The use of a single control plane state (bidirectional signaling) =
obviously </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">makes control plane fate-sharing automatic, but the use of =
associated </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">signaling does not preclude control plane fate sharing - it just =
needs </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">additional message exchanges.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">The use of an identical path for both directions can provide some =
elements </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">of data plane fate sharing, but it is important to note that it =
does not </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">guarantee it.</FONT></SPAN><SPAN LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[dc] Yes my</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">understanding</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"> of the fate sharing is =
that upstream and downstream LSP must follow the same =
path.</FONT></SPAN><SPAN LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">For example, a unidirectional fiber could fail. This issue is =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">not impacted by bidirectional or associated signaling as the =
directions can </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">be installed on the path by associated signaling, and as a failure =
might </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">only impact one direction in bidirectional =
signaling.</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[dc]</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">Here is where ALS should =
come in the field.&nbsp; If the fibre is broken</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">in =
one</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">direction</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"> the ALS should shutdown =
the laser associated to the other direction.&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">&nbsp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">&nbsp;-------X-----&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">A</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; B&nbsp; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">&nbsp;&lt;------------S</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">That is X is a failure (LOL), as soon B detects the =
loss of light due to the ALS is</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">shutdown</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New"> the laser (S in the =
picture)</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Courier New">towards A</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">End-to-end protection features are implemented at a different level =
and seem </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">to be beyond this debate.</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">So I am wondering what relevance fate-sharing has to the discussion =
of </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">asymmetrical bandwidth. Maybe the discussion has reduced =
to:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">- We need asymmetrical bidirectional services</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">- Does the value of a single signaling exchange outweigh =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp; cost of new signaling objects and =
procedures?</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[dc] I've</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">tried</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"> to =
make a summary of the point discussed so far in an another =
mail</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Adrian</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">----- Original Message ----- </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: &quot;Attila Takacs (IJ/ETH)&quot; =
&lt;[email-masked]&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">To: &quot;Pandian, Vijay&quot; =
&lt;[email-masked]&gt;; &quot;Don Fedyk&quot; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&lt;[email-masked]&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Cc: &lt;[email-masked]&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Sent: Tuesday, March 06, 2007 10:34 AM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Subject: RE: Questions on =
draft-takacs-asym-bw-lsp-00.txt</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Vijay,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">let me answer this.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">If you need different protection for each direction then you likely =
will</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">need differently routed LSPs. In this case one better uses =
separate</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">sessions for the two directions since all the benefits of having =
a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">single session (like fate sharing) is gone if the LSPs take =
different</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">routes. The ID only proposes to relax the symmetrical bandwidth =
property</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">of the bidirectional LSP establishment given in =
RFC3471.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Regards,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Attila</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">________________________________</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>] On</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Behalf Of Pandian, Vijay</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Sent: Tuesday, March 06, 2007 1:36 AM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">To: Don Fedyk</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Cc: [email-masked]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Subject: RE: Questions on =
draft-takacs-asym-bw-lsp-00.txt</FONT></SPAN></P>
<BR>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Don,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">The question I had regarding P&amp;R was trying to figure out if =
one</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">direction required a better P&amp;R (say 1+1) and the reverse =
direction</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">probably required some basic P&amp;R (say =
Re-routing).</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">So the requirement is to use the same &quot;physical link&quot; for =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">forward and reverse direction. Am I right?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Regards,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Vijay</FONT></SPAN></P>
<BR>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: Don Fedyk [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT><=
/SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Sent: Monday, March 05, 2007 6:41 PM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">To: Pandian, Vijay; [email-masked]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Subject: RE: Questions on</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">draft-takacs-asym-bw-lsp-00.txt</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi Vijay</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">________________________________</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">From: [email-masked]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">[<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>] On Behalf Of Pandian, Vijay</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Sent: Monday, March 05, 2007 2:07 PM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">To: [email-masked]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Subject: Questions on</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">draft-takacs-asym-bw-lsp-00.txt</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hi,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">I have some basic questions, primarily trying to</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">understand the scope of this ID as well as the application behind =
such a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">requirement.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">1. Does this ID address just an asymmetric</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Bandwidth requirement?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">The postulation was that GMPLS today supports</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bi-directional service with a single RSVP-TE session creating =
a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bidirectional LSP.&nbsp; The most common implementation of this is =
Optical</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">TDM networks.&nbsp; Since this was the starting point, the ID =
postulates</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">setting up an asymmetric service with a single asymmetric =
LSP.&nbsp; (Like</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">many new drafts it sets a requirement and postulates a =
an</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">implementation.)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">So to your question besides bandwidth there is =
also</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">underlying requirement to align with GMPLS single session =
procedures and</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">support a bi-directional packet data plane as Ethernet does =
today.&nbsp; A</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">single bidirectional (in this case asymmetric BW capable) =
LSP.&nbsp; In other</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">words a single RSVP-TE session.&nbsp; Several people have pointed =
out this is</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">also achievable with two unidirectional RSVP-TE sessions (one at =
each</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">end).&nbsp; Rather than reopen that debate on this thread I will =
acknowledge</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">the authors had a single session in mind more as a requirement of =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">technology.&nbsp; Ethernet data forwarding is bi-directional =
symmetric and</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">there are efficiencies in a single session of a bi-directional =
LSP.&nbsp; On</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">the other hand the issue is there is currently no way to specify =
the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">asymmetric BW. If you want to discuss the pros and cons of =
multiple</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">sessions versus single there is already a thread on this (RE: =
I-D</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">ACTION:draft-takacs-asym-bw-lsp-00.txt)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">|&nbsp; 2. How about other attributes? in particular =
LSP</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Protection &amp; Recovery (P&amp;R) related =
attributes?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">With respect to GMPLS, the plan was to allow</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bi-directional Protection or Recovery LSPs controlled by =
separate</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">RSVP-TE sessions in separate from the single RSVP-TE session =
associated</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">with the primary bidirectional LSP.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">3. If P&amp;R are indeed different, doesn't it =
make</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">sense to route them separately (separate CSPF calculation at each =
end)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">and eventually signal them independently as well?</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Hopefully I addressed part of this already. Recovery =
of</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">the bi-directional LSP could be handled by another RSVP-TE session =
&amp;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">LSP.&nbsp; The data plane in our case must have a bi-directional =
symmetric</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">path so you can only do a CSPF at one end and/or force the paths =
to</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">align.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">4. Is there a need for the forward and reverse</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">flows to be on the same path?</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">That is the way an Ethernet data plane works, and in =
my</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">case this is where the requirement comes from. There is Ethernet =
data</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">plane OAM and in some cases Ethernet forwarding rules that both =
require</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bi-directional symmetric paths.&nbsp; The requirement is to be able =
to</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">support native Ethernet loopback and data plane trace functions =
and</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bi-directional symmetry in the data plane is =
required.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">5. What is &quot;fate sharing&quot;? I couldn't find =
this</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">in other RFCs or IDs. Is it same as link/node/SRLG disjoint =
paths?</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Yes it is related.&nbsp; A shared resource link =
group</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">identifies shared resources at some granularity. Fate shared paths =
have</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">shared resources at a very high level of granularity.&nbsp; =
Disjoint paths</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">have none or very few shared resources.&nbsp; For a bidirectional =
path the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">shared fate comes from the fact that both direction have =
common</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">resources and if one fails the other is likely to =
fail.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Regards,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Don</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Regards,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Vijay</FONT></SPAN></P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C75FE4.D1CD0D9C--

Delivery-date: Tue, 06 Mar 2007 11:35:15 +0000
Content-class: urn:content-classes:message
Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 12:35:00 +0100
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

Hi Adrian,

Please see inline.
Regards,
Attila=20

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]=20
> Sent: Tuesday, March 06, 2007 12:05 PM
> To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
> Cc: [email-masked]
> Subject: What is this fate sharing thing? [Was: Questions on=20
> draft-takacs-asym-bw-lsp-00.txt]
>=20
> Hi,
>=20
> There has been a lot of discussion about "fate-sharing" and I=20
> am not sure what problem we are trying to solve.
>=20
> - Is this a data plane feature where a data plane fault in one
>   direction must cause data plane interruption in both directions?
>=20
> - Is this a protection feature where the switch-over of one
>   direction to its backup path must be accompanied by a
>   switch-over of the other direction, too?
>=20
> - Is this a control plane feature where the removal of control
>   plane state in one direction must cause the removal of control
>   plane state in the other direction?
>=20
> The use of a single control plane state (bidirectional=20
> signaling) obviously makes control plane fate-sharing=20
> automatic, but the use of associated signaling does not=20
> preclude control plane fate sharing - it just needs=20
> additional message exchanges.

Control plane fate sharing was mentioned as one benefit when having a
single session. In this case additional message exchanges are not needed
and there are no additional delays which otherwise would be an issue
with restoration.

>=20
> The use of an identical path for both directions can provide=20
> some elements of data plane fate sharing, but it is important=20
> to note that it does not guarantee it. For example, a=20
> unidirectional fiber could fail. This issue is not impacted=20
> by bidirectional or associated signaling as the directions=20
> can be installed on the path by associated signaling, and as=20
> a failure might only impact one direction in bidirectional signaling.
>=20
Agreed, the data plane aspects are technology specific.

> End-to-end protection features are implemented at a different=20
> level and seem to be beyond this debate.
>=20
>=20
> So I am wondering what relevance fate-sharing has to the=20
> discussion of=20
> asymmetrical bandwidth. Maybe the discussion has reduced to:
> - We need asymmetrical bidirectional services
> - Does the value of a single signaling exchange outweigh the
>    cost of new signaling objects and procedures?

Another point is on application scenarios. As Dimitri pointed out in his
early mails, if a general extension to support asymmetric bandwidth is
going to be specified its complexity might outweigh its benefits.
However, given a focused scenario with single sided control and full
bandwidth knowledge at the ingress, the simple extensions given in the
ID might be appropriate. The question on this would be whether the
proposed extension with this scope is worth the effort.

>=20
> Adrian
>=20
> ----- Original Message -----=20
> From: "Attila Takacs (IJ/ETH)" <[email-masked]>
> To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk"=20
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, March 06, 2007 10:34 AM
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay,
>=20
> let me answer this.
>=20
> If you need different protection for each direction then you=20
> likely will
> need differently routed LSPs. In this case one better uses separate
> sessions for the two directions since all the benefits of having a
> single session (like fate sharing) is gone if the LSPs take different
> routes. The ID only proposes to relax the symmetrical=20
> bandwidth property
> of the bidirectional LSP establishment given in RFC3471.
>=20
> Regards,
> Attila
>=20
> ________________________________
>=20
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [email-masked]
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
>=20
> Don,
>=20
> The question I had regarding P&R was trying to figure out if one
> direction required a better P&R (say 1+1) and the reverse direction
> probably required some basic P&R (say Re-routing).
>=20
> So the requirement is to use the same "physical link" for the
> forward and reverse direction. Am I right?
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [email-masked]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [email-masked]
> Subject: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi,
>=20
> I have some basic questions, primarily trying to
> understand the scope of this ID as well as the application=20
> behind such a
> requirement.
>=20
> 1. Does this ID address just an asymmetric
> Bandwidth requirement?
>=20
> The postulation was that GMPLS today supports
> bi-directional service with a single RSVP-TE session creating a
> bidirectional LSP.  The most common implementation of this is Optical
> TDM networks.  Since this was the starting point, the ID postulates
> setting up an asymmetric service with a single asymmetric LSP.  (Like
> many new drafts it sets a requirement and postulates a an
> implementation.)
>=20
> So to your question besides bandwidth there is also
> underlying requirement to align with GMPLS single session=20
> procedures and
> support a bi-directional packet data plane as Ethernet does today.  A
> single bidirectional (in this case asymmetric BW capable)=20
> LSP.  In other
> words a single RSVP-TE session.  Several people have pointed=20
> out this is
> also achievable with two unidirectional RSVP-TE sessions (one at each
> end).  Rather than reopen that debate on this thread I will=20
> acknowledge
> the authors had a single session in mind more as a requirement of the
> technology.  Ethernet data forwarding is bi-directional symmetric and
> there are efficiencies in a single session of a=20
> bi-directional LSP.  On
> the other hand the issue is there is currently no way to specify the
> asymmetric BW. If you want to discuss the pros and cons of multiple
> sessions versus single there is already a thread on this (RE: I-D
> ACTION:draft-takacs-asym-bw-lsp-00.txt)
>=20
> |  2. How about other attributes? in particular LSP
> Protection & Recovery (P&R) related attributes?
>=20
> With respect to GMPLS, the plan was to allow
> bi-directional Protection or Recovery LSPs controlled by separate
> RSVP-TE sessions in separate from the single RSVP-TE session=20
> associated
> with the primary bidirectional LSP.
>=20
> 3. If P&R are indeed different, doesn't it make
> sense to route them separately (separate CSPF calculation at each end)
> and eventually signal them independently as well?
>=20
>=20
> Hopefully I addressed part of this already. Recovery of
> the bi-directional LSP could be handled by another RSVP-TE session &
> LSP.  The data plane in our case must have a bi-directional symmetric
> path so you can only do a CSPF at one end and/or force the paths to
> align.
>=20
> 4. Is there a need for the forward and reverse
> flows to be on the same path?
>=20
>=20
> That is the way an Ethernet data plane works, and in my
> case this is where the requirement comes from. There is Ethernet data
> plane OAM and in some cases Ethernet forwarding rules that=20
> both require
> bi-directional symmetric paths.  The requirement is to be able to
> support native Ethernet loopback and data plane trace functions and
> bi-directional symmetry in the data plane is required.
>=20
> 5. What is "fate sharing"? I couldn't find this
> in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
>=20
>=20
> Yes it is related.  A shared resource link group
> identifies shared resources at some granularity. Fate shared=20
> paths have
> shared resources at a very high level of granularity.  Disjoint paths
> have none or very few shared resources.  For a bidirectional path the
> shared fate comes from the fact that both direction have common
> resources and if one fails the other is likely to fail.
>=20
> Regards,
> Don
>=20
>=20
> Regards,
>=20
> Vijay
>=20
>=20
>=20
>=20

Delivery-date: Tue, 06 Mar 2007 11:29:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 12:29:39 +0100
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Guys,

         let me try to summarize what we have said so far:

1         The basic idea behind the ID is based on some facts (I hope we =
all agree that are facts :-));

1.1      Ethernet services are (likely) bidirectional with asymmetric =
bandwidth;

1.2      GMPLS now allows to set-up bi-directional LSP with symmetrical =
bandwidth;

1.3      If, with the existing protocols, there is the need to set-up a =
bi-directional service with asymmetric bandwidth requirement (e.g. IpTv) =
and with upstream and downstream path that follow the same route we have =
to signal two different LSPs using the RRO of the first one as strict =
ERO for the second one.  If we also want to bind the two LSPs in order =
to identify them as part of the same service we can use the ASSOCIATON =
obj (modified I suppose)

1.4      Likely (I would say very likely) the NMS that requests the =
LSP(s) set-up knows in advance the bandwidth needed in the two =
directions.  So we are in a different situation w.r.t. the original RSVP =
situation.  We have all the information we need to set-up the LSP at the =
Path processing

Now if all of we are happy with point 1.3 then we have finished.  If =
someone think that is better to have the possibility to set-up and =
identify a bidirectional service with a single LSP then the ID have =
reason to exists at least for discussion :-).

IMHO having the possibility to set-up the LSP at the path processing =
speed up the service establishment and this is particularly useful in =
case of LSP rerouting in case of failure.  In fact if the service is =
made of the two LSP what could happens is the first one can be set-up =
and the second one fails during signaling this means that first one have =
to be deleted and two LSP path recomputed and re-signaled. =20

Best Regards

=20

Diego =20

=20

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs (IJ/ETH)
Sent: marted=EC 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

=20

Hi Vijay,

=20

let me answer this.=20

=20

If you need different protection for each direction then you likely will =
need differently routed LSPs. In this case one better uses separate =
sessions for the two directions since all the benefits of having a =
single session (like fate sharing) is gone if the LSPs take different =
routes. The ID only proposes to relax the symmetrical bandwidth property =
of the bidirectional LSP establishment given in RFC3471.

=20

Regards,

Attila

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	Don,

	=20

	The question I had regarding P&R was trying to figure out if one =
direction required a better P&R (say 1+1) and the reverse direction =
probably required some basic P&R (say Re-routing).

	=20

	So the requirement is to use the same "physical link" for the forward =
and reverse direction. Am I right?

	=20

	Regards,

	=20

	Vijay

	=20

	=20

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

			=20

		=09
________________________________

			From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
			Sent: Monday, March 05, 2007 2:07 PM
			To: [email-masked]
			Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

			Hi,

			=20

			I have some basic questions, primarily trying to understand the scope =
of this ID as well as the application behind such a requirement.

			=20

			1. Does this ID address just an asymmetric Bandwidth requirement?=20

		The postulation was that GMPLS today supports bi-directional service =
with a single RSVP-TE session creating a bidirectional LSP.  The most =
common implementation of this is Optical TDM networks.  Since this was =
the starting point, the ID postulates setting up an asymmetric service =
with a single asymmetric LSP.  (Like many new drafts it sets a =
requirement and postulates a an implementation.) =20

		=20

		So to your question besides bandwidth there is also underlying =
requirement to align with GMPLS single session procedures and support a =
bi-directional packet data plane as Ethernet does today.  A single =
bidirectional (in this case asymmetric BW capable) LSP.  In other words =
a single RSVP-TE session.  Several people have pointed out this is also =
achievable with two unidirectional RSVP-TE sessions (one at each end).  =
Rather than reopen that debate on this thread I will acknowledge the =
authors had a single session in mind more as a requirement of the =
technology.  Ethernet data forwarding is bi-directional symmetric and =
there are efficiencies in a single session of a bi-directional LSP.  On =
the other hand the issue is there is currently no way to specify the =
asymmetric BW. If you want to discuss the pros and cons of multiple =
sessions versus single there is already a thread on this (RE: I-D =
ACTION:draft-takacs-asym-bw-lsp-00.txt)

		=20

		|  2. How about other attributes? in particular LSP Protection & =
Recovery (P&R) related attributes?=20

		=20

		With respect to GMPLS, the plan was to allow bi-directional Protection =
or Recovery LSPs controlled by separate RSVP-TE sessions in separate =
from the single RSVP-TE session associated with the primary =
bidirectional LSP.  =20

			3. If P&R are indeed different, doesn't it make sense to route them =
separately (separate CSPF calculation at each end) and eventually signal =
them independently as well?=20

			=20

		Hopefully I addressed part of this already. Recovery of the =
bi-directional LSP could be handled by another RSVP-TE session & LSP.  =
The data plane in our case must have a bi-directional symmetric path so =
you can only do a CSPF at one end and/or force the paths to align.=20

			4. Is there a need for the forward and reverse flows to be on the =
same path?=20

			=20

		That is the way an Ethernet data plane works, and in my case this is =
where the requirement comes from. There is Ethernet data plane OAM and =
in some cases Ethernet forwarding rules that both require bi-directional =
symmetric paths.  The requirement is to be able to support native =
Ethernet loopback and data plane trace functions and bi-directional =
symmetry in the data plane is required.=20

			5. What is "fate sharing"? I couldn't find this in other RFCs or IDs. =
Is it same as link/node/SRLG disjoint paths?=20

			=20

		Yes it is related.  A shared resource link group identifies shared =
resources at some granularity. Fate shared paths have shared resources =
at a very high level of granularity.  Disjoint paths have none or very =
few shared resources.  For a bidirectional path the shared fate comes =
from the fact that both direction have common resources and if one fails =
the other is likely to fail.   =20

		=20

		Regards,

		Don=20

			=20

			Regards,

			=20

			Vijay

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:PMingLiU;
	panose-1:2 2 3 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 3 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS PGothic";}
@font-face
	{font-family:ar;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"\@MS PGothic";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
h1
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	page-break-after:avoid;
	mso-list:l7 level1 lfo14;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:normal;}
h2
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	page-break-after:avoid;
	mso-list:l7 level2 lfo14;
	font-size:16.0pt;
	font-family:Arial;
	font-weight:normal;}
h3
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	page-break-after:avoid;
	mso-list:l7 level3 lfo14;
	font-size:12.0pt;
	font-family:Arial;}
h4
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	text-indent:-3.0cm;
	page-break-after:avoid;
	mso-list:l7 level4 lfo14;
	font-size:11.0pt;
	font-family:Arial;}
h5
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:-34.65pt;
	margin-bottom:.0001pt;
	text-indent:-21.6pt;
	page-break-after:avoid;
	mso-list:l20 level5 lfo7;
	font-size:11.0pt;
	font-family:Arial;}
h6
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:-27.45pt;
	margin-bottom:.0001pt;
	text-indent:-21.6pt;
	page-break-after:avoid;
	mso-list:l20 level6 lfo7;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-20.25pt;
	text-indent:-14.4pt;
	page-break-after:avoid;
	mso-list:l20 level7 lfo7;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-13.05pt;
	text-indent:-21.6pt;
	mso-list:l20 level8 lfo7;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-style:italic;}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:-5.85pt;
	text-indent:-7.2pt;
	mso-list:l20 level9 lfo7;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc1, li.MsoToc1, div.MsoToc1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoToc2, li.MsoToc2, div.MsoToc2
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc3, li.MsoToc3, div.MsoToc3
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:5.0cm;
	margin-bottom:.0001pt;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc6, li.MsoToc6, div.MsoToc6
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:60.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc7, li.MsoToc7, div.MsoToc7
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:72.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc8, li.MsoToc8, div.MsoToc8
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:84.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoToc9, li.MsoToc9, div.MsoToc9
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:96.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoFootnoteText, li.MsoFootnoteText, div.MsoFootnoteText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:6.0pt;
	font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoCaption, li.MsoCaption, div.MsoCaption
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.MsoTof, li.MsoTof, div.MsoTof
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoMacroText, li.MsoMacroText, div.MsoMacroText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l9 level1 lfo13;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListBullet, li.MsoListBullet, div.MsoListBullet
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l13 level1 lfo3;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListNumber, li.MsoListNumber, div.MsoListNumber
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:18.4pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l20 level1 lfo7;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoList2, li.MsoList2, div.MsoList2
	{margin-top:9.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:102.05pt;
	margin-bottom:.0001pt;
	text-indent:-36.85pt;
	mso-list:l18 level1 lfo8;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListBullet2, li.MsoListBullet2, div.MsoListBullet2
	{margin-top:11.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l23 level1 lfo5;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoListNumber4, li.MsoListNumber4, div.MsoListNumber4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:60.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.0pt;
	mso-list:l1 level1 lfo45;
	font-size:11.0pt;
	font-family:Arial;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:0cm;
	text-indent:0cm;
	font-size:24.0pt;
	font-family:Arial;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
p.Contents, li.Contents, div.Contents
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:3.0cm;
	font-size:18.0pt;
	font-family:Arial;}
p.Heading, li.Heading, div.Heading
	{margin-top:24.0pt;
	margin-right:0cm;
	margin-bottom:14.0pt;
	margin-left:3.0cm;
	page-break-after:avoid;
	font-size:18.0pt;
	font-family:Arial;}
p.Text, li.Text, div.Text
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.Listnumbersingleline, li.Listnumbersingleline, =
div.Listnumbersingleline
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.5pt;
	margin-bottom:.0001pt;
	text-indent:-18.45pt;
	mso-list:l28 level1 lfo36;
	font-size:11.0pt;
	font-family:Arial;}
p.Listnumberdoubleline, li.Listnumberdoubleline, =
div.Listnumberdoubleline
	{margin-top:11.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l29 level1 lfo11;
	font-size:11.0pt;
	font-family:Arial;}
p.Listabcsingleline, li.Listabcsingleline, div.Listabcsingleline
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l27 level1 lfo12;
	font-size:11.0pt;
	font-family:Arial;}
p.Listabcdoubleline, li.Listabcdoubleline, div.Listabcdoubleline
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:103.45pt;
	margin-bottom:.0001pt;
	text-indent:-18.4pt;
	mso-list:l9 level1 lfo13;
	font-size:11.0pt;
	font-family:Arial;}
p.ProgramStyle, li.ProgramStyle, div.ProgramStyle
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:3.0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Courier New";}
p.CaptionFigureExternal, li.CaptionFigureExternal, =
div.CaptionFigureExternal
	{margin-top:3.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.Captionwide, li.Captionwide, div.Captionwide
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:2.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.ColumnCaption, li.ColumnCaption, div.ColumnCaption
	{margin-top:3.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.FooterText, li.FooterText, div.FooterText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:Arial;}
p.Note, li.Note, div.Note
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:124.75pt;
	margin-bottom:.0001pt;
	text-indent:-39.7pt;
	font-size:11.0pt;
	font-family:Arial;}
p.TableCaption, li.TableCaption, div.TableCaption
	{margin-top:16.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:2.0cm;
	text-indent:-2.0cm;
	page-break-after:avoid;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.TableCaptionColumn, li.TableCaptionColumn, div.TableCaptionColumn
	{margin-top:16.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:5.0cm;
	text-indent:-2.0cm;
	page-break-after:avoid;
	font-size:11.0pt;
	font-family:Arial;
	font-style:italic;}
p.TableHeading, li.TableHeading, div.TableHeading
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
p.TableText, li.TableText, div.TableText
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	font-size:10.0pt;
	font-family:Arial;}
p.IndentedBodyText, li.IndentedBodyText, div.IndentedBodyText
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.BlueIndentedBoldBodyText, li.BlueIndentedBoldBodyText, =
div.BlueIndentedBoldBodyText
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:blue;
	font-weight:bold;}
p.BlueIndentedText, li.BlueIndentedText, div.BlueIndentedText
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:4.0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:blue;}
p.Term-list, li.Term-list, div.Term-list
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:7.0cm;
	margin-bottom:.0001pt;
	text-indent:-4.0cm;
	font-size:11.0pt;
	font-family:Arial;}
p.DocName, li.DocName, div.DocName
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:18.0pt;
	font-family:Arial;}
p.PageNo, li.PageNo, div.PageNo
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:9.0pt;
	font-family:Arial;}
p.SubTitle, li.SubTitle, div.SubTitle
	{margin-top:10.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;}
p.DocNo, li.DocNo, div.DocNo
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:right;
	font-size:6.0pt;
	font-family:Arial;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:-132;
	mso-list-type:simple;
	mso-list-template-ids:-1716873870;}
@list l0:level1
	{mso-level-tab-stop:74.6pt;
	mso-level-number-position:left;
	margin-left:74.6pt;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:-131;
	mso-list-type:simple;
	mso-list-template-ids:-1026097760;}
@list l1:level1
	{mso-level-style-link:"List Number 4";
	mso-level-tab-stop:60.45pt;
	mso-level-number-position:left;
	margin-left:60.45pt;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:-130;
	mso-list-type:simple;
	mso-list-template-ids:-1056920686;}
@list l2:level1
	{mso-level-tab-stop:46.3pt;
	mso-level-number-position:left;
	margin-left:46.3pt;
	text-indent:-18.0pt;}
@list l3
	{mso-list-id:-129;
	mso-list-type:simple;
	mso-list-template-ids:-862428020;}
@list l3:level1
	{mso-level-tab-stop:32.15pt;
	mso-level-number-position:left;
	margin-left:32.15pt;
	text-indent:-18.0pt;}
@list l4
	{mso-list-id:-125;
	mso-list-type:simple;
	mso-list-template-ids:1807904128;}
@list l4:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:32.15pt;
	mso-level-number-position:left;
	margin-left:32.15pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l5
	{mso-list-id:-120;
	mso-list-type:simple;
	mso-list-template-ids:117202946;}
@list l5:level1
	{mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l6
	{mso-list-id:-119;
	mso-list-type:simple;
	mso-list-template-ids:-1106724220;}
@list l6:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l7
	{mso-list-id:-5;
	mso-list-template-ids:1237909336;}
@list l7:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;
	text-decoration:none;
	text-underline:none;}
@list l7:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;
	text-decoration:none;
	text-underline:none;}
@list l7:level3
	{mso-level-style-link:"Heading 3";
	mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;
	text-decoration:none;
	text-underline:none;}
@list l7:level4
	{mso-level-style-link:"Heading 4";
	mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;
	text-decoration:none;
	text-underline:none;}
@list l7:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;}
@list l7:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;}
@list l7:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-3.0cm;}
@list l7:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:62.35pt;
	mso-level-number-position:left;
	margin-left:62.35pt;
	text-indent:0cm;}
@list l7:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:62.35pt;
	mso-level-number-position:left;
	margin-left:62.35pt;
	text-indent:0cm;}
@list l8
	{mso-list-id:36249161;
	mso-list-type:hybrid;
	mso-list-template-ids:948440106 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l8:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:%1;
	mso-level-tab-stop:83.6pt;
	mso-level-number-position:left;
	margin-left:83.6pt;
	text-indent:-18.4pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";}
@list l9
	{mso-list-id:48069649;
	mso-list-type:hybrid;
	mso-list-template-ids:737296600 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l9:level1
	{mso-level-number-format:alpha-lower;
	mso-level-reset-level:level1;
	mso-level-style-link:"List abc double line";
	mso-level-text:%1;
	mso-level-tab-stop:103.45pt;
	mso-level-number-position:left;
	margin-left:103.45pt;
	text-indent:-18.4pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;}
@list l10
	{mso-list-id:206647829;
	mso-list-type:hybrid;
	mso-list-template-ids:146571096 200441330 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l10:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:%1;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";}
@list l11
	{mso-list-id:222715544;
	mso-list-type:hybrid;
	mso-list-template-ids:572943984 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l11:level1
	{mso-level-text:%1;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;}
@list l12
	{mso-list-id:303779168;
	mso-list-type:simple;
	mso-list-template-ids:117109292;}
@list l12:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:17.85pt;
	mso-level-number-position:left;
	margin-left:17.85pt;
	text-indent:-17.85pt;
	font-family:Symbol;}
@list l13
	{mso-list-id:390812414;
	mso-list-template-ids:-2089905590;}
@list l13:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"List Bullet";
	mso-level-text:\F0B7;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:11.0pt;
	font-family:Symbol;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;}
@list l13:level2
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:121.9pt;
	mso-level-number-position:left;
	margin-left:121.9pt;
	text-indent:-18.4pt;
	text-decoration:none;
	text-underline:none;}
@list l13:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:140.35pt;
	mso-level-number-position:left;
	margin-left:140.35pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:8.0pt;
	font-family:Symbol;
	text-decoration:none;
	text-underline:none;}
@list l13:level4
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:160.2pt;
	mso-level-number-position:left;
	margin-left:160.2pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:8.0pt;
	font-family:PMingLiU;
	mso-hansi-font-family:"Times New Roman";
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	text-decoration:none;
	text-underline:none;}
@list l13:level5
	{mso-level-number-format:bullet;
	mso-level-text:=BB;
	mso-level-tab-stop:178.6pt;
	mso-level-number-position:left;
	margin-left:178.6pt;
	text-indent:-18.4pt;
	font-family:"MS PGothic";
	mso-hansi-font-family:"Times New Roman";}
@list l13:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l13:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l13:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l13:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l14
	{mso-list-id:398331490;
	mso-list-type:hybrid;
	mso-list-template-ids:-1255120004 -724277456 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l14:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;
	font-family:Symbol;}
@list l15
	{mso-list-id:430468571;
	mso-list-type:hybrid;
	mso-list-template-ids:-766062200 1574631544 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l15:level1
	{mso-level-text:%1;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;}
@list l16
	{mso-list-id:592007867;
	mso-list-template-ids:67698717;}
@list l16:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l16:level2
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%2\)";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:36.0pt;
	text-indent:-18.0pt;}
@list l16:level3
	{mso-level-number-format:roman-lower;
	mso-level-text:"%3\)";
	mso-level-tab-stop:54.0pt;
	mso-level-number-position:left;
	margin-left:54.0pt;
	text-indent:-18.0pt;}
@list l16:level4
	{mso-level-text:"\(%4\)";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:72.0pt;
	text-indent:-18.0pt;}
@list l16:level5
	{mso-level-number-format:alpha-lower;
	mso-level-text:"\(%5\)";
	mso-level-tab-stop:90.0pt;
	mso-level-number-position:left;
	margin-left:90.0pt;
	text-indent:-18.0pt;}
@list l16:level6
	{mso-level-number-format:roman-lower;
	mso-level-text:"\(%6\)";
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	margin-left:108.0pt;
	text-indent:-18.0pt;}
@list l16:level7
	{mso-level-tab-stop:126.0pt;
	mso-level-number-position:left;
	margin-left:126.0pt;
	text-indent:-18.0pt;}
@list l16:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	margin-left:144.0pt;
	text-indent:-18.0pt;}
@list l16:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:162.0pt;
	mso-level-number-position:left;
	margin-left:162.0pt;
	text-indent:-18.0pt;}
@list l17
	{mso-list-id:638464377;
	mso-list-template-ids:-1315251934;}
@list l17:level1
	{mso-level-text:%1;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;}
@list l17:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:112.0pt;
	mso-level-number-position:left;
	margin-left:112.0pt;
	text-indent:-1.0cm;}
@list l17:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:146.0pt;
	mso-level-number-position:left;
	margin-left:146.0pt;
	text-indent:-34.0pt;}
@list l17:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:189.95pt;
	mso-level-number-position:left;
	margin-left:189.95pt;
	text-indent:-43.95pt;}
@list l17:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.";
	mso-level-tab-stop:-421.15pt;
	mso-level-number-position:left;
	margin-left:-435.65pt;
	text-indent:-39.4pt;}
@list l17:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:-385.15pt;
	mso-level-number-position:left;
	margin-left:-410.4pt;
	text-indent:-46.75pt;}
@list l17:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:-367.05pt;
	mso-level-number-position:left;
	margin-left:-385.15pt;
	text-indent:-53.9pt;}
@list l17:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.";
	mso-level-tab-stop:-331.05pt;
	mso-level-number-position:left;
	margin-left:-359.95pt;
	text-indent:-61.2pt;}
@list l17:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:-313.15pt;
	mso-level-number-position:left;
	margin-left:-331.05pt;
	text-indent:-72.0pt;}
@list l18
	{mso-list-id:641886644;
	mso-list-type:hybrid;
	mso-list-template-ids:1568309458 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l18:level1
	{mso-level-style-link:"List 2";
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:121.9pt;
	mso-level-number-position:left;
	margin-left:121.9pt;
	text-indent:-36.85pt;}
@list l19
	{mso-list-id:724640005;
	mso-list-type:hybrid;
	mso-list-template-ids:1389774374 -234070452 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l19:level1
	{mso-level-text:%1;
	mso-level-tab-stop:102.75pt;
	mso-level-number-position:left;
	margin-left:102.75pt;
	text-indent:-84.75pt;}
@list l20
	{mso-list-id:972560170;
	mso-list-template-ids:1354533614;}
@list l20:level1
	{mso-level-reset-level:level1;
	mso-level-style-link:"List Number";
	mso-level-text:%1;
	mso-level-tab-stop:18.4pt;
	mso-level-number-position:left;
	margin-left:18.4pt;
	text-indent:-18.4pt;
	mso-ansi-font-size:11.0pt;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;}
@list l20:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:42.5pt;
	mso-level-number-position:left;
	margin-left:42.5pt;
	text-indent:-24.1pt;
	text-decoration:none;
	text-underline:none;}
@list l20:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:3.0cm;
	mso-level-number-position:left;
	margin-left:3.0cm;
	text-indent:-42.55pt;
	text-decoration:none;
	text-underline:none;}
@list l20:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:141.7pt;
	mso-level-number-position:left;
	margin-left:141.7pt;
	text-indent:-56.65pt;
	text-decoration:none;
	text-underline:none;}
@list l20:level5
	{mso-level-style-link:"Heading 5";
	mso-level-text:"%5\)";
	mso-level-tab-stop:-34.65pt;
	mso-level-number-position:left;
	margin-left:-34.65pt;
	text-indent:-21.6pt;}
@list l20:level6
	{mso-level-number-format:alpha-lower;
	mso-level-style-link:"Heading 6";
	mso-level-text:"%6\)";
	mso-level-tab-stop:-27.45pt;
	mso-level-number-position:left;
	margin-left:-27.45pt;
	text-indent:-21.6pt;}
@list l20:level7
	{mso-level-number-format:roman-lower;
	mso-level-style-link:"Heading 7";
	mso-level-text:"%7\)";
	mso-level-tab-stop:-20.25pt;
	mso-level-number-position:right;
	margin-left:-20.25pt;
	text-indent:-14.4pt;}
@list l20:level8
	{mso-level-number-format:alpha-lower;
	mso-level-style-link:"Heading 8";
	mso-level-tab-stop:-13.05pt;
	mso-level-number-position:left;
	margin-left:-13.05pt;
	text-indent:-21.6pt;}
@list l20:level9
	{mso-level-number-format:roman-lower;
	mso-level-style-link:"Heading 9";
	mso-level-tab-stop:-5.85pt;
	mso-level-number-position:right;
	margin-left:-5.85pt;
	text-indent:-7.2pt;}
@list l21
	{mso-list-id:1079406860;
	mso-list-type:hybrid;
	mso-list-template-ids:1279151814 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l21:level1
	{mso-level-start-at:6;
	mso-level-text:%1;
	mso-level-tab-stop:102.75pt;
	mso-level-number-position:left;
	margin-left:102.75pt;
	text-indent:-84.75pt;}
@list l22
	{mso-list-id:1141800763;
	mso-list-template-ids:1263729996;}
@list l22:level1
	{mso-level-reset-level:level1;
	mso-level-text:%1;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;}
@list l22:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:127.6pt;
	mso-level-number-position:left;
	margin-left:127.6pt;
	text-indent:-24.1pt;}
@list l22:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:163.6pt;
	mso-level-number-position:left;
	margin-left:140.9pt;
	text-indent:-13.3pt;}
@list l22:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:218.3pt;
	mso-level-number-position:left;
	margin-left:218.3pt;
	text-indent:-2.0cm;}
@list l22:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.";
	mso-level-tab-stop:-256.8pt;
	mso-level-number-position:left;
	margin-left:-271.3pt;
	text-indent:-39.4pt;}
@list l22:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:-220.8pt;
	mso-level-number-position:left;
	margin-left:-246.05pt;
	text-indent:-46.75pt;}
@list l22:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:-202.7pt;
	mso-level-number-position:left;
	margin-left:-220.8pt;
	text-indent:-53.9pt;}
@list l22:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.";
	mso-level-tab-stop:-166.7pt;
	mso-level-number-position:left;
	margin-left:-195.6pt;
	text-indent:-61.2pt;}
@list l22:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:-148.8pt;
	mso-level-number-position:left;
	margin-left:-166.7pt;
	text-indent:-72.0pt;}
@list l23
	{mso-list-id:1160853806;
	mso-list-template-ids:-1000804512;}
@list l23:level1
	{mso-level-number-format:bullet;
	mso-level-style-link:"List Bullet 2";
	mso-level-text:\F0B7;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:11.0pt;
	font-family:Symbol;
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;}
@list l23:level2
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:121.9pt;
	mso-level-number-position:left;
	margin-left:121.9pt;
	text-indent:-18.4pt;
	text-decoration:none;
	text-underline:none;}
@list l23:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:140.35pt;
	mso-level-number-position:left;
	margin-left:140.35pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:8.0pt;
	font-family:Symbol;
	text-decoration:none;
	text-underline:none;}
@list l23:level4
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:160.2pt;
	mso-level-number-position:left;
	margin-left:160.2pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:8.0pt;
	font-family:PMingLiU;
	mso-hansi-font-family:"Times New Roman";
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;
	text-decoration:none;
	text-underline:none;}
@list l23:level5
	{mso-level-number-format:bullet;
	mso-level-text:=BB;
	mso-level-tab-stop:178.6pt;
	mso-level-number-position:left;
	margin-left:178.6pt;
	text-indent:-18.4pt;
	font-family:"MS PGothic";
	mso-hansi-font-family:"Times New Roman";}
@list l23:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l23:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l23:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l23:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:150.25pt;
	mso-level-number-position:left;
	margin-left:150.25pt;
	text-indent:0cm;}
@list l24
	{mso-list-id:1182208801;
	mso-list-type:hybrid;
	mso-list-template-ids:842971714 -746174012 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l24:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:102.9pt;
	mso-level-number-position:left;
	margin-left:102.9pt;
	text-indent:-17.85pt;
	font-family:Symbol;}
@list l25
	{mso-list-id:1188592950;
	mso-list-type:hybrid;
	mso-list-template-ids:-585201972 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l25:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;
	font-family:Symbol;}
@list l26
	{mso-list-id:1250429154;
	mso-list-type:hybrid;
	mso-list-template-ids:1353763354 2050801698 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l26:level1
	{mso-level-text:%1;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l27
	{mso-list-id:1283463062;
	mso-list-type:hybrid;
	mso-list-template-ids:1157510324 -911605588 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l27:level1
	{mso-level-number-format:alpha-lower;
	mso-level-reset-level:level1;
	mso-level-style-link:"List abc single line";
	mso-level-text:%1;
	mso-level-tab-stop:103.45pt;
	mso-level-number-position:left;
	margin-left:103.45pt;
	text-indent:-18.4pt;}
@list l28
	{mso-list-id:1371110036;
	mso-list-type:hybrid;
	mso-list-template-ids:-195282962 316937498 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l28:level1
	{mso-level-reset-level:level1;
	mso-level-style-link:"List number single line";
	mso-level-text:%1;
	mso-level-tab-stop:103.45pt;
	mso-level-number-position:left;
	margin-left:103.45pt;
	text-indent:-18.4pt;}
@list l29
	{mso-list-id:1405420464;
	mso-list-type:hybrid;
	mso-list-template-ids:1530924372 -1846766362 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l29:level1
	{mso-level-reset-level:level1;
	mso-level-style-link:"List number double line";
	mso-level-text:%1;
	mso-level-tab-stop:103.45pt;
	mso-level-number-position:left;
	margin-left:103.45pt;
	text-indent:-18.4pt;}
@list l30
	{mso-list-id:1453208656;
	mso-list-type:hybrid;
	mso-list-template-ids:-223438672 -622446482 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l30:level1
	{mso-level-reset-level:level1;
	mso-level-text:%1;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;}
@list l31
	{mso-list-id:1530873626;
	mso-list-type:hybrid;
	mso-list-template-ids:-668016690 -264446362 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l31:level1
	{mso-level-start-at:3;
	mso-level-text:%1;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l32
	{mso-list-id:1531603457;
	mso-list-template-ids:93612620;}
@list l32:level1
	{mso-level-reset-level:level1;
	mso-level-text:%1;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";}
@list l32:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:127.6pt;
	mso-level-number-position:left;
	margin-left:127.6pt;
	text-indent:-24.1pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";}
@list l32:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:163.6pt;
	mso-level-number-position:left;
	margin-left:140.9pt;
	text-indent:-13.3pt;
	mso-ansi-font-size:11.0pt;
	font-family:ar;}
@list l32:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:206.95pt;
	mso-level-number-position:left;
	margin-left:206.95pt;
	text-indent:-45.35pt;
	mso-ansi-font-size:11.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-weight:normal;
	mso-ansi-font-style:normal;}
@list l32:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.";
	mso-level-tab-stop:-256.8pt;
	mso-level-number-position:left;
	margin-left:-271.2pt;
	text-indent:-39.6pt;}
@list l32:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:-220.8pt;
	mso-level-number-position:left;
	margin-left:-246.0pt;
	text-indent:-46.8pt;}
@list l32:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:-202.8pt;
	mso-level-number-position:left;
	margin-left:-220.8pt;
	text-indent:-54.0pt;}
@list l32:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.";
	mso-level-tab-stop:-166.8pt;
	mso-level-number-position:left;
	margin-left:-195.6pt;
	text-indent:-61.2pt;}
@list l32:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:-148.8pt;
	mso-level-number-position:left;
	margin-left:-166.8pt;
	text-indent:-72.0pt;}
@list l33
	{mso-list-id:1610427805;
	mso-list-template-ids:1973577278;}
@list l33:level1
	{mso-level-reset-level:level1;
	mso-level-text:%1;
	mso-level-tab-stop:83.65pt;
	mso-level-number-position:left;
	margin-left:83.65pt;
	text-indent:-18.45pt;}
@list l33:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:107.75pt;
	mso-level-number-position:left;
	margin-left:107.75pt;
	text-indent:-24.1pt;}
@list l33:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:138.9pt;
	mso-level-number-position:left;
	margin-left:138.9pt;
	text-indent:-31.15pt;}
@list l33:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:184.3pt;
	mso-level-number-position:left;
	margin-left:184.3pt;
	text-indent:-45.4pt;}
@list l33:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.";
	mso-level-tab-stop:-256.8pt;
	mso-level-number-position:left;
	margin-left:-271.2pt;
	text-indent:-39.6pt;}
@list l33:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:-220.8pt;
	mso-level-number-position:left;
	margin-left:-246.0pt;
	text-indent:-46.8pt;}
@list l33:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:-202.8pt;
	mso-level-number-position:left;
	margin-left:-220.8pt;
	text-indent:-54.0pt;}
@list l33:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.";
	mso-level-tab-stop:-166.8pt;
	mso-level-number-position:left;
	margin-left:-195.6pt;
	text-indent:-61.2pt;}
@list l33:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:-148.8pt;
	mso-level-number-position:left;
	margin-left:-166.8pt;
	text-indent:-72.0pt;}
@list l34
	{mso-list-id:1936551466;
	mso-list-type:hybrid;
	mso-list-template-ids:2128512750 -1061625664 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l34:level1
	{mso-level-style-link:"List number single line";
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:102.05pt;
	mso-level-number-position:left;
	margin-left:102.05pt;
	text-indent:-36.85pt;}
@list l35
	{mso-list-id:2043625445;
	mso-list-type:hybrid;
	mso-list-template-ids:-258825404 1068016958 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l35:level1
	{mso-level-text:%1;
	mso-level-tab-stop:103.5pt;
	mso-level-number-position:left;
	margin-left:103.5pt;
	text-indent:-18.45pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Guys,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>=A0=A0=A0=A0=A0=A0=A0=A0 let me try to summarize what =
we have said so far:<o:p></o:p></span></font></p>

<p class=3DMsoListNumber><![if !supportLists]><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:11.0pt;color:blue'><span =
style=3D'mso-list:Ignore'>1<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font color=3Dblue><span
style=3D'color:blue'>The basic idea behind the ID is based on some facts =
(I hope
we all agree that are facts </span></font><font color=3Dblue =
face=3DWingdings><span
style=3D'font-family:Wingdings;color:blue'>J</span></font><font =
color=3Dblue><span
style=3D'color:blue'>);<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>1.1<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>Ethernet services are (likely) =
bidirectional
with asymmetric bandwidth;<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>1.2<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>GMPLS now allows to set-up =
bi-directional LSP
with symmetrical bandwidth;<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>1.3<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>If, with the existing protocols, =
there is
the need to set-up a bi-directional service with asymmetric bandwidth
requirement (e.g. IpTv) and with upstream and downstream path that =
follow the
same route we have to signal two different LSPs using the RRO of the =
first one
as strict ERO for the second one. =A0If we also want to bind the two =
LSPs in
order to identify them as part of the same service we can use the =
ASSOCIATON
obj (modified I suppose)<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:42.5pt;text-indent:-24.1pt'><![if =
!supportLists]><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'><span
style=3D'mso-list:Ignore'>1.4<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
color=3Dblue><span style=3D'color:blue'>Likely (I would say very likely) =
the NMS
that requests the LSP(s) set-up knows in advance the bandwidth needed in =
the
two directions. =A0So we are in a different situation w.r.t. the =
original RSVP
situation.=A0 We have all the information we need to set-up the LSP at =
the Path
processing<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'>Now if
all of we are happy with point 1.3 then we have finished. =A0If someone =
think
that is better to have the possibility to set-up and identify a =
bidirectional
service with a single LSP then the ID have reason to exists at least for
discussion </span></font><font color=3Dblue face=3DWingdings><span
style=3D'font-family:Wingdings;color:blue'>J</span></font><font =
color=3Dblue><span
style=3D'color:blue'>.<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'>IMHO
having the possibility to set-up the LSP at the path processing speed up =
the
service establishment and this is particularly useful in case of LSP =
rerouting
in case of failure.=A0 In fact if the service is made of the two LSP =
what could
happens is the first one can be set-up and the second one fails during
signaling this means that first one have to be deleted and two LSP path
recomputed and re-signaled.=A0 <o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'>Best
Regards<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><o:p>&nbsp;</o:p></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:11.0pt;color:blue'>Diego =
=A0<o:p></o:p></span></font></p>

<p class=3DMsoListNumber =
style=3D'margin-left:0cm;text-indent:0cm;mso-list:none'><font
size=3D2 color=3Dblue face=3DArial><o:p>&nbsp;</o:p></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Attila Takacs =
(IJ/ETH)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 6 marzo =
2007 11.35<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Pandian, Vijay; Don =
Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D2 =
face=3DArial><o:p>&nbsp;</o:p></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hi Vijay,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>let me answer this. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>If you need different protection for each direction =
then you
likely will need differently routed LSPs. In this case one better uses =
separate
sessions for the two directions since all the benefits of having a =
single
session (like fate sharing) is gone if the LSPs take different =
routes.&nbsp;The
ID only&nbsp;proposes to relax the symmetrical bandwidth property of the
bidirectional LSP establishment given in =
RFC3471.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Attila</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Pandian, Vijay<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, March 06, =
2007 1:36
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Don Fedyk<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Don,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>The question I had regarding P&amp;R was trying to =
figure
out if one direction required a better P&amp;R (say 1+1) and the reverse
direction&nbsp;probably&nbsp;required&nbsp;some basic P&amp;R
(say&nbsp;Re-routing).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>So the requirement is to use the same &quot;physical
link&quot; for the forward and reverse direction. Am I =
right?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Vijay</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Don Fedyk
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 6:41
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Pandian, Vijay; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hi Vijay</span></font><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<p class=3DMsoNormal><font size=3D2 =
face=3DArial><o:p>&nbsp;</o:p></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
face=3DArial><span style=3D'font-size:11.0pt'>

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Pandian, Vijay<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 2:07
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Questions on
draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Hi,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>I
have some basic questions, primarily trying to understand the scope of =
this ID
as well as the application behind such a =
requirement.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>1.
Does this ID address just an asymmetric Bandwidth requirement?<font =
color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>The postulation was that GMPLS today supports =
bi-directional
service with a single RSVP-TE session creating a bidirectional =
LSP.&nbsp; The
most common implementation of this is Optical TDM =
networks.</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>&nbsp;<font color=3Dblue><span
style=3D'color:blue'> Since this was the starting point, the ID =
postulates
setting up an asymmetric service with a single&nbsp;asymmetric =
LSP.&nbsp; (Like
many new drafts it sets a requirement and postulates a an
implementation.)&nbsp;&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>So to your question besides =
bandwidth&nbsp;there&nbsp;is
also underlying requirement to align with GMPLS single session =
procedures and
support a bi-directional packet data plane as Ethernet does today.&nbsp; =
A
single bidirectional (in this case asymmetric BW capable) LSP.&nbsp; In =
other
words a single RSVP-TE session.&nbsp; Several people have pointed out =
this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).&nbsp; Rather than reopen that debate on this thread I will =
acknowledge
the authors&nbsp;had a single session in mind more as a requirement of =
the
technology. &nbsp;Ethernet data forwarding is bi-directional symmetric =
and
there are efficiencies in a single session of a bi-directional =
LSP.&nbsp; On
the other hand the issue is there is currently no way to specify the =
asymmetric
BW. If you want to discuss the pros and cons of multiple sessions versus =
single
there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>|</span></font><strong><b><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'> =
</span></font></b></strong><font
size=3D2 color=3Dblue><span =
style=3D'font-size:10.0pt;color:blue'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>2. How about other attributes? =
in
particular LSP Protection &amp; Recovery (P&amp;R) related =
attributes?<font
color=3Dblue><span =
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>With respect to GMPLS, the plan was to =
allow&nbsp;bi-directional
Protection or Recovery LSPs controlled by separate RSVP-TE sessions in =
separate
from&nbsp;the single RSVP-TE session associated with the primary =
bidirectional
LSP. &nbsp;</span></font><font size=3D2><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>3. If
P&amp;R are indeed different,&nbsp;doesn't&nbsp;it make sense =
to&nbsp;route
them separately (separate CSPF calculation at each end) and
eventually&nbsp;signal them independently as well?<font =
color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Hopefully I addressed part of this already. Recovery =
of the
bi-directional LSP could be handled by another RSVP-TE session &amp; =
LSP.&nbsp;
The data plane in our case must have a bi-directional symmetric path so =
you can
only do a CSPF at one end and/or force the paths to =
align.&nbsp;</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>4. Is
there a need for the forward and reverse flows to be on the same =
path?<font
color=3Dblue><span =
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>That is the way an Ethernet data plane works, and in =
my case
this is where the requirement comes from. There is Ethernet data plane =
OAM and
in some cases Ethernet forwarding rules that both require bi-directional
symmetric paths.&nbsp; The requirement is to be able to support native =
Ethernet
loopback and data plane trace functions and bi-directional symmetry in =
the data
plane is required. </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>5.
What is &quot;fate sharing&quot;? I couldn't find this in other RFCs or =
IDs. Is
it same as link/node/SRLG disjoint paths?<font color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Yes it is related.&nbsp; A shared resource link group
identifies shared resources at some granularity. Fate shared paths have =
shared
resources at a very high level of granularity.&nbsp;&nbsp;Disjoint paths =
have
none or very few shared resources.&nbsp;&nbsp;For a bidirectional path =
the
shared fate comes from the fact that both direction have common =
resources and
if one fails the other is likely to =
fail.&nbsp;&nbsp;&nbsp;</span></font><font
size=3D2><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;color:blue'>Don </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:11.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Vijay</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C75FE2.AA8D5950--

Delivery-date: Tue, 06 Mar 2007 11:06:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>
Subject: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Date: Tue, 6 Mar 2007 11:05:20 -0000
Organization: Old Dog Consulting

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 
of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue is 
not impacted by bidirectional or associated signaling as the directions can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.

Regards,
Attila

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Don,

The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).

So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

Hi,

I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.

1. Does this ID address just an asymmetric
Bandwidth requirement?

The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)

So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)

|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?

With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.

3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?

Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.

4. Is there a need for the forward and reverse
flows to be on the same path?

That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.

5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?

Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.

Regards,
Don

Regards,

Vijay

Delivery-date: Tue, 06 Mar 2007 10:35:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 11:34:53 +0100
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75FDB.13B4FBE9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Vijay,
=20
let me answer this.=20
=20
If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.
=20
Regards,
Attila
=20
________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	Don,
	=20
	The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).
	=20
	So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?
	=20
	Regards,
	=20
	Vijay
	=20
	=20

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay

________________________________

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
			Sent: Monday, March 05, 2007 2:07 PM
			To: [email-masked]
			Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt
		=09
		=09
			Hi,
			=20
			I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.
			=20
			1. Does this ID address just an asymmetric
Bandwidth requirement?=20

		The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.) =20
		=20
		So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)
		=20
		|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes?=20
		=20
		With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.  =20

			3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well?=20
			=20

		Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align.=20

			4. Is there a need for the forward and reverse
flows to be on the same path?=20
			=20

		That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required.=20

			5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?=20
			=20

		Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.   =20
		=20
		Regards,
		Don=20

			=20
			Regards,
			=20
			Vijay

------_=_NextPart_001_01C75FDB.13B4FBE9
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=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Vijay,</FONT></SPAN></DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>let me=20
answer this. </FONT></SPAN></DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>If you=20
need different protection for each direction then you likely will need=20
differently routed LSPs. In this case one better uses separate sessions =
for the=20
two directions since all the benefits of having a single session (like =
fate=20
sharing) is gone if the LSPs take different routes.&nbsp;The ID=20
only</FONT></SPAN><SPAN class=3D443562510-06032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;proposes to relax the symmetrical bandwidth property of =
the=20
bidirectional LSP establishment given in RFC3471.</FONT></SPAN></DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =

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

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

size=3D2>Attila</FONT></SPAN></DIV>
<DIV><SPAN class=3D443562510-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV>
<HR tabIndex=3D-1>
</DIV>
<DIV><FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Pandian,=20
Vijay<BR><B>Sent:</B> Tuesday, March 06, 2007 1:36 AM<BR><B>To:</B> Don=20
Fedyk<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: Questions =
on=20
draft-takacs-asym-bw-lsp-00.txt<BR></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Don,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
  question I had regarding P&amp;R was trying to figure out if one =
direction=20
  required a better P&amp;R (say 1+1) and the reverse=20
  direction&nbsp;probably&nbsp;required&nbsp;some basic P&amp;R=20
  (say&nbsp;Re-routing).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff size=3D2>So=20
  the requirement is to use the same "physical link" for the forward and =
reverse=20
  direction. Am I right?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Vijay</FONT></SPAN></DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D873282200-06032007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Don Fedyk=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Monday, March 05, 2007 =
6:41=20
    PM<BR><B>To:</B> Pandian, Vijay; =
[email-masked]<BR><B>Subject:</B> RE:=20
    Questions on draft-takacs-asym-bw-lsp-00.txt<BR><BR></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D964004621-05032007>Hi Vijay</SPAN></FONT></DIV><BR>
    <BLOCKQUOTE dir=3Dltr=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] =

      [mailto:[email-masked]] <B>On Behalf Of </B>Pandian,=20
      Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B> =

      [email-masked]<BR><B>Subject:</B> Questions on=20
      draft-takacs-asym-bw-lsp-00.txt<BR></FONT><BR></DIV>
      <DIV></DIV>
      <DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007>Hi,</SPAN></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D232211417-05032007>I have some=20
      basic questions, primarily trying to understand the scope of this =
ID as=20
      well as the application behind such a =
requirement.</SPAN></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>1. Does=20
      this ID address just an asymmetric Bandwidth requirement?<SPAN=20
      class=3D964004621-05032007><FONT=20
      =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV></DIV></BL=
OCKQUOTE>
    <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
    size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>The=20
    postulation was that GMPLS today supports bi-directional service =
with a=20
    single RSVP-TE session creating a bidirectional LSP.&nbsp; The most =
common=20
    implementation of this is Optical TDM networks.</FONT>&nbsp;<FONT=20
    color=3D#0000ff> Since this was the starting point, the ID =
postulates setting=20
    up an asymmetric service with a single&nbsp;asymmetric LSP.&nbsp; =
(Like many=20
    new drafts it sets a requirement and postulates a an=20
    =
implementation.)&nbsp;&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></D=
IV>
    <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
    size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT=20
    =
color=3D#0000ff></FONT></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
    size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>So=20
    to your question besides bandwidth&nbsp;there&nbsp;is also =
underlying=20
    requirement to align with GMPLS single session=20
    </FONT></SPAN></FONT></FONT></SPAN></FONT><FONT face=3DArial><SPAN=20
    class=3D232211417-05032007><FONT size=3D+0><FONT color=3D#0000ff =
size=3D2><SPAN=20
    class=3D964004621-05032007>procedures and support a bi-directional =
packet data=20
    plane as Ethernet does today.&nbsp; A single bidirectional (in this =
case=20
    asymmetric BW capable) LSP.&nbsp; In other words a single RSVP-TE=20
    session.&nbsp; Several people have pointed out this is also =
achievable with=20
    two unidirectional RSVP-TE sessions (one at each end).&nbsp; Rather =
than=20
    reopen that debate on this thread I will acknowledge the =
authors&nbsp;had a=20
    single session in mind more as a requirement of the technology.=20
    &nbsp;Ethernet data forwarding is bi-directional symmetric and there =
are=20
    efficiencies in a single session of a bi-directional=20
    LSP.</SPAN></FONT></FONT></SPAN></FONT><FONT face=3DArial><SPAN=20
    class=3D232211417-05032007><FONT size=3D+0><FONT color=3D#0000ff =
size=3D2><SPAN=20
    class=3D964004621-05032007>&nbsp; On the other hand the issue is =
there is=20
    currently no way to specify the asymmetric BW. If you want to =
discuss the=20
    pros and cons of multiple sessions versus single there is already a =
thread=20
    on this (RE: I-D=20
    =
ACTION:draft-takacs-asym-bw-lsp-00.txt)</SPAN></FONT></FONT></SPAN></FONT=
></DIV>
    <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
    size=3D+0><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
    face=3DArial><SPAN class=3D232211417-05032007><FONT size=3D+0><FONT =
color=3D#0000ff=20
    size=3D2><SPAN=20
    class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
    face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
    class=3D964004621-05032007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
    size=3D2><FONT color=3D#0000ff><SPAN =
class=3D964004621-05032007><FONT=20
    color=3D#000000><FONT color=3D#0000ff>|</FONT><STRONG>=20
    </STRONG></FONT>&nbsp;</SPAN></FONT><SPAN =
class=3D232211417-05032007>2. How=20
    about other attributes? in particular LSP Protection &amp; Recovery=20
    (P&amp;R) related attributes?<SPAN class=3D964004621-05032007><FONT=20
    =
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D232211417-05032007><SPAN=20
    =
class=3D964004621-05032007></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
    <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D232211417-05032007><SPAN =
class=3D964004621-05032007><FONT=20
    color=3D#0000ff>With respect to GMPLS, the plan was to=20
    allow&nbsp;bi-directional Protection or Recovery LSPs controlled by =
separate=20
    RSVP-TE sessions in separate from&nbsp;the single RSVP-TE session =
associated=20
    with the primary bidirectional LSP.=20
    &nbsp;</FONT>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>3. If=20
      P&amp;R are indeed different,&nbsp;doesn't&nbsp;it make sense=20
      to&nbsp;route them separately (separate CSPF calculation at each =
end) and=20
      eventually&nbsp;signal them independently as well?<SPAN=20
      class=3D964004621-05032007><FONT=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
      =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>Hopefully I=20
    addressed part of this already. Recovery of the bi-directional LSP =
could be=20
    handled by another RSVP-TE session &amp; LSP.&nbsp; The data plane =
in our=20
    case must have a bi-directional symmetric path so you can only do a =
CSPF at=20
    one end and/or force the paths to=20
    align.&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>4. Is=20
      there a need for the forward and reverse flows to be on the same=20
      path?<SPAN class=3D964004621-05032007><FONT=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
      =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>That =
is the way an=20
    Ethernet data plane works, and in my case this is where the =
requirement=20
    comes from. There is Ethernet data plane OAM and in some cases =
Ethernet=20
    forwarding rules that both require bi-directional symmetric =
paths.&nbsp; The=20
    requirement is to be able to support native Ethernet loopback and =
data plane=20
    trace functions and bi-directional symmetry in the data plane is =
required.=20
    </FONT></SPAN></FONT></FONT></SPAN></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>5. What=20
      is "fate sharing"? I couldn't find this in other RFCs or IDs. Is =
it same=20
      as link/node/SRLG disjoint paths?<SPAN =
class=3D964004621-05032007><FONT=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
      <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
      =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>Yes =
it is=20
    related.&nbsp; A shared resource link group identifies shared =
resources at=20
    some granularity. Fate shared paths have shared resources at a very =
high=20
    level of granularity.&nbsp;&nbsp;Disjoint paths have none or very =
few shared=20
    resources.&nbsp;&nbsp;For a bidirectional path the shared fate comes =
from=20
    the fact that both direction have common resources and if one fails =
the=20
    other is likely to=20
    =
fail.&nbsp;&nbsp;&nbsp;</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    color=3D#0000ff size=3D2><SPAN=20
    class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    color=3D#0000ff size=3D2><SPAN=20
    =
class=3D964004621-05032007>Regards,</SPAN></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
    color=3D#0000ff size=3D2><SPAN class=3D964004621-05032007>Don=20
    </SPAN></FONT></FONT></SPAN></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007>Regards,</SPAN></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2><SPAN=20
      =
class=3D232211417-05032007>Vijay</SPAN></FONT></DIV></BLOCKQUOTE></BLOCKQ=
UOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C75FDB.13B4FBE9--

Delivery-date: Tue, 06 Mar 2007 10:25:37 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 11:24:56 +0100
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, "Igor Bryskin" <[email-masked]>, "Diego Caviglia \(GA/ERI\)" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>

Hi Julien,

The point is that having a single session has its benefits in some cases
(as pointed out in previous postings) but to leverage this the
applicability is limited (again pointed out previously, e.g., single
sided control) compared to a general RSVP-TE case with separate
sessions. So we are not saying that the single session is *the*
solution, it as an alternative option (maybe "valuable") to the separate
session approach.

Regards,
Attila=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of MEURIC Julien=20
> RD-CORE-LAN
> Sent: Monday, March 05, 2007 5:50 PM
> To: Igor Bryskin; Diego Caviglia (GA/ERI); Igor Bryskin;=20
> [email-masked]; [email-masked]
> Cc: [email-masked]; Don Fedyk
> Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
>=20
> Hi Igor.
>=20
> Please, find my answers in-line.
>=20
> Regards,
>=20
> Julien
>=20
>=20
> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]=20
>=20
> Julien,
>=20
> Please, see in-line.
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
>=20
> Hi all.
>=20
> To answer the 1st question, I would say that there is a=20
> requirement for asymmetrical bidirectional *service* (think=20
> about IP TV transport for instance). What is more, as Igor=20
> said, being able to handle both directions as a single=20
> service brings advantages (such as fate sharing), especially=20
> in terms of operating a network. Question is: does this=20
> necessarily map to "single LSP"? Not so sure...
>=20
> Then, I do not see any strong requirement for having a single=20
> signalling exchange.
>=20
> IB>> Well, if everything goes smoothly, the setup of a single
> bi-directional LSP is twice as fast as the setup of two=20
> unidirectional LSPs. If there are some provisioning problems,=20
> then the difference may be much bigger. Think about the=20
> situation when there is a resource allocation failure for the=20
> opposite direction on the service node, say, next after the=20
> ingress. If you setup a single bi-directional LSP the failure=20
> is detected almost right away, the path is recomputed and LSP=20
> is re-routed. However, if you setup two reciprocal=20
> unidirectional LSPs, the failure won't be even detected=20
> before the Path message for the second LSP arrives on the=20
> failure detecting node. And now you will have to signal the=20
> release of both LSPs and start the whole setup again. So, the=20
> recovery time won't be all that great, don't you agree?
>=20
> [JM] I agree with you. That is why, for recovery, a node=20
> should not rely on a third party (such as a manager or the=20
> other end-node). However, you are only saying that a single=20
> LSP may fit the requirement, but I still cannot say that the=20
> requirement leads only to this exact solution. :-)
>=20
>=20
>  Besides, I do not think a scenario with a management system=20
> communicating with both end-nodes should be excluded neither.=20
> However, in this case, it may be detrimental for the control=20
> plane to rely on an external party to correlate both directions.
>=20
> IB>> My customers say that if one set's up a soft-PVC and one needs to
> access both edges of the soft-PVC, one might just touch all=20
> other nodes, that is, setup a PVC instead. They believe that=20
> it is a significant advantage to be able to control service=20
> from one node. That's what makes the service provisioning=20
> *dynamic*. Frankly, as I see it the only situation for the=20
> management plane to access nodes other than ingress is when=20
> there is a problem with the CP. For example, one of the=20
> controllers went out of service and there is a need to tear=20
> down or reroute the service.
>=20
> [JM] I do not think it is an issue of communication sessions.=20
> A PVC does not provide with the same kind of services as a=20
> soft-PVC, whether it rely on a bi-directional or 2=20
> uni-directional LSPs: differences are deeper than only=20
> head-node handling. Of course it is an advantage to control=20
> the service from a single point (node, manager...), but I do=20
> not see how provisioning from 2 nodes makes it less dynamic=20
> than provisioning from one node... Anyway I admit that it may=20
> ease automatic end-to-end provisioning in case of multi-layer=20
> or multi-domain services.
>=20
>=20
> Can you give me other examples when such need arises?
>=20
> [JM] I think if you want use the information in MIBs, you=20
> need to communicate with all nodes... From my point of view,=20
> the requirement is managing from a single *point* and=20
> defining this point as a node is only
> *a* (valuable) solution.
>=20
>=20
> Thanks,
> Igor
>  =20
>=20
> Diego, to answer you, I think you are correct: re-using the=20
> RRO of the 1st one is an option to consider when routing by=20
> the controling plane, and using management-built ERO for both=20
> directions is valid in case of manual routing. As a result,=20
> it looks like tools are there to for provisioning,=20
> nevertheless it may bring an issue to guarantee fate sharing=20
> in case of recovery.
>=20
> Regards,
>=20
> Julien
>=20
> ________________________________
>=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Diego Caviglia (GA/ERI)
>=20
> From my experience I can quote everything Igor said.  GMPLS=20
> tunnel establishment is, AFAIK, always driven by the NMS/OSS=20
> that (quoting Neil Harrison here) is the King.
>=20
> =20
>=20
> So I think that in the real world the Ingress node knows the=20
> upstream and downstream bandwidth of the GMPLS Tunnel is=20
> going to set-up.
>=20
> Moreover if I'll use two uni-directional LSPs in order to=20
> set-up an LSP with asymmetrical bandwidth requirement I can=20
> force the path of the two LSPs to be the same?  Do I have to=20
> use the RRO of the first one as ERO for the second one?  Or I=20
> suppose to use a fully defined ERO for both the two LSP?  In=20
> this case I do suppose that the ERO has been calculated by the NMS?
>=20
> =20
>=20
> Regards
>=20
>=20
> Diego
>=20
> =20
>=20
> ________________________________
>=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Igor Bryskin
>=20
> Adrian and Dimitri,
>=20
> When a GMPLS tunnel is setup, it is setup for a reason. =20
> Let's say, management plane requests a tunnel ingress node to=20
> setup a tunnel. The request may not (and normally does not)=20
> contain an explicit path, but it definitely contains all=20
> bandwidth parameters, because the tunnel was requested, as I=20
> siad,  for a particular reason  (application, SLA, etc.).=20
> Also, how else you can ensure the fate sharing other than=20
> computing a path on the ingress node taking in consideration=20
> the bandwidth requirements for both directions?
> So, yes, I'd say that it is safe to assume that ingress node=20
> always knows about bandiwidth in both directions.
>=20
> I'd say even more. We have a strict requirement from our=20
> customers that actively deploy our GMPLS CP, that a=20
> communication between management and control plane should=20
> always hapen at one (ingress) node.
>=20
> Igor
>=20
> PS It would be interesting to hear from providers on this topic.
>=20
> [email-masked] wrote:
>=20
> "Adrian Farrel"=20
> 04/03/2007 00:35
> Please respond to "Adrian Farrel"
>=20
> To: "Igor Bryskin" , Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> cc: , "Don Fedyk"=20
> Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> > 3. if a) is selected there is no other choice than an upstream
> flowspec=20
> in
> > the Path msg and a upstream tspec in the Resv message
>=20
> That *does* raise an interesting question. Namely, does the=20
> ingress know
>=20
> the=20
> bandwidth to request? If it does then there is no need for a TSpec on
> the=20
> Resv as the reservation has already been made commensurate with the=20
> FlowSpec=20
> on the Path.
>=20
> -> if you do that you prevent the ingress-side to never adapt resource
> reservation to the traffic parameters of the egress (in fact, it would
> boil down to "single-sided" asymmetry forever)
>=20
> -> hence, initially you must satisfy at least condition where=20
> flowspec=20
> =3D< tspec, nevertheless, after the tspec may "increase" and therefore =

> the flowspec may be adapted=20
>=20
> If the ingress does *not* know and needs to see a TSpec from=20
> the egress,
>=20
> then we need another Path exchange after the Resv in order to=20
> make the=20
> actual reservations. In that case it really would be a mess and not
> worth=20
> trying to shoe-horn into a bidirectional LSP format.
>=20
> -> this is what i said also to don, the case where initially=20
> the ingress
>=20
> is completely unaware of what it can reserve is impossible=20
> without major
> protocol modifications
>=20
> -> my partial conclusion, is that a workable asym bw lsp=20
> doesn't elevate
> the need for the general case, and only provides apparent facilitation
> in
> a corner case, whereas a technique making use of association object
> would
> prevent all this protocol massaging, keep full backward compatibility,
> and
> provide full flexibility
>=20
>=20
> A=20
>=20
>=20
>=20

Delivery-date: Tue, 06 Mar 2007 09:49:15 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Non-member submission from [mike shand <[email-masked]>]   
Date: Tue, 6 Mar 2007 09:45:36 -0000
Organization: Old Dog Consulting

> To: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
> From: mike shand <[email-masked]>
> Subject: RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt
>  from ISIS WG
> Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>,
>        "les Ginsberg \(ginsberg\)" <[email-masked]>
>
> At 19:48 01/03/2007, LE ROUX Jean-Louis RD-CORE-LAN wrote:
>>Hi Mike,
>>
>>Thanks for these comments.
>>
>>Please see inline,
>>
>> > -----Message d'origine-----
>> > De : [email-masked]
>> > [mailto:[email-masked]] De la part de Adrian Farrel
>> > Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10
>> > =C0 : [email-masked]
>> > Objet : Review comments on
>> > draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
>> >
>> >
>> > From: "mike shand" <[email-masked]>
>> > To: "Adrian Farrel" <[email-masked]>
>> > Cc: <[email-masked]>; "'Jean Philippe Vasseur'" <[email-masked]>
>> > Sent: Thursday, February 15, 2007 10:47 AM
>> > Subject: Re: [Isis-wg] PCE working group last call on
>> > draft-ietf-pce-disco-proto-isis-02.txt
>> >
>> >
>> > > Adrian, JP,
>> > >
>> > >
>> > > A few comments below, mostly typos.
>> > >
>> > >         Mike
>> > >
>> > >
>> > > General comment... sometimes the document refers to octets and
>> > > sometimes to bytes. It would be preferable to use a
>> > consistent term throughout.
>>
>>OK
>>
>> > >
>> > >
>> > >
>> > > Abstract
>> > >
>> > >
>> > >    along with some of information that can be used for PCE
>> > selection.
>> > >
>> > >
>> > > some of THE information
>> > >
>> > > or
>> > >
>> > > some information
>>
>>OK
>>
>> > >
>> > > 1. Terminology
>> > >
>> > > ABR is not a commonly used term in the context of IS-IS and doesn't
>> > > appear to be referenced in the document.
>>
>>OK
>>
>> > >
>> > > domain. This definition is different from that commonly used for
>> > > IS-IS. Is there a reason for the difference? The document refers to
>> > > IS-IS routing domains. Is it intended that a domain is
>> > different from a routing domain?
>>
>>This is a domain as defined in the PCE architecture spec (RFC4655)
>>
>>"A domain is any collection of network elements=20
>>within a common sphere of address management or=20
>>path computation responsibility.  Examples of=20
>>domains include IGP areas, Autonomous Systems=20
>>(ASes), and multiple ASes within a Service=20
>>Provider network.  Domains of path computation=20
>>responsibility may also exist as sub-domains of areas or ASes."
>>
>>We are going to clarify. We can use the term=20
>>"Path Computation Domain" to be more specific.
>
> Yes. I think it is important to make that differentiation.
>
>
>
>> > >
>> > >
>> > > top of page 5
>> > >
>> > >
>> > > This document does not define any new IS-IS elements of procedure.
>> > >    The procedures defined in [IS-IS-CAP] should be used.
>> > >
>> > >
>> > > should that be ... MUST be used?
>>
>>OK, MUST be used
>>
>> > >
>> > > 3.2 flooding scope
>> > >
>> > >
>> > >   be limited to one or more IS-IS areas the PCE belongs to,
>> > or can be
>> > >
>> > > one or more IS-IS areas to which the PCE belongs
>> > >
>> > > would be better
>> > >
>> > >
>> > > 4.1. The IS-IS PCED TLV
>> > >
>> > > In the introduction this is referred to (correctly) as a
>> > sub-TLV, but
>> > > here and in subsequent text it is referred to as a TLV. This is
>> > > confusing to say the least.
>>
>>OK, to be changed to sub-TLV
>>
>> > >
>> > >
>> > > The format of the IS-IS PCED TLV and its sub-TLVs is the
>> > identical to
>> > >
>> > > is identical to
>>
>>OK
>>
>> > >
>> > >
>> > >
>> > > 4.1.6. The CONGESTION sub-TLV
>> > >
>> > >
>> > >   The CONGESTION sub-TLV is used to indicate a PCE's experiences a
>> > >
>> > > to indicate THAT a PCE experiences
>> > >
>> > > or
>> > >
>> > > to indicate a PCE's experience of a
>> > >
>> > > or
>> > >
>> > > to indicate that a PCE is experiencing a
>>
>>OK
>>
>> > >
>> > >
>> > >  VALUE: This comprises a one-byte bit flags indicating the
>> > >
>> > >
>> > > this reads rather strangely
>> > >
>> > > this comprises one byte of bit flags....
>>
>>OK
>>
>> > >
>> > >
>> > >
>> > >
>> > > 5. Elements of Procedure
>> > >
>> > >
>> > > typo
>> > >
>> > >
>> > >   domain, itMUST be carried within an IS-IS CAPABILITY TLV
>> > having the
>> > > S
>> > >
>> > >
>> > >    When the PCE function is deactivated on a node, the node MUST
>> > >    originate a new IS-IS LSP with no longer any PCED TLV. A
>> > PCC MUST be
>> > >    able to detect that the PCED TLV has been removed from
>> > an IS-IS LSP.
>> > >
>> > >
>> > > are we assuming here that all this information will always
>> > fit within
>> > > a single LSP?  That is probably reasonable
>>
>>Yes
>>
>> > >
>> > > Are we also assuming that it will always fit within a
>> > single IS-IS CAP
>> > > TLV? That may not be so reasonable.
>>
>>Actually this sounds reasonable
>>
>>2 * PCE-ADDRESS + PATH-SCOPE + CONGESTION +=20
>>PCE-CAP-FLAGs (with 32 flags) =3D 40 bytes.
>>
>>This let 256 - 2 -40 =3D 214 bytes for the=20
>>PCE-DOMAINS and PCE-NEIG-DOMAINS, which allows=20
>>encoding 35 neighbor ASes for instance.
>>
>>Splitting a PCED TLV would add useless complexity.
>>We are going to add this statement : The PCED=20
>>TLV MUST fit in with a single ISIS CAP TLV.
>>By the way this restricts the number of PCE=20
>>domains and neighbor domains to a reasonable value.
>>
>>Does that make sense?
>
> Yes. The above statement removes any problems.
>
>
>
>> > >
>> > > If it requires two IS-IS CAP TLVS, is there a requirement
>> > that they be
>> > > carried in the same LSP?
>> > >
>> > >
>> > >
>> > > 7.1. IS-IS sub-TLV
>> > >
>> > >    Once a registry for the IS-IS Router Capability TLV defined in
>> > >    [IS-IS-CAP] will have been assigned, IANA will assign a new
>> > >
>> > >
>> > > "has been assigned" would be better
>>
>>OK
>>
>> > >
>> > >
>> > >
>> > > 9.5. Requirements on Other Protocols and Functional Components
>> > >
>> > >    The IS-IS extensions defined in this documents does not imply any
>> > >    requirement on other protocols.
>> > >
>> > > do not imply (IS-IS extensions is plural)
>>
>>OK
>>
>>Thanks a lot. Once the last call is completed,=20
>>we are going to submit a new revision that accounts for all these 
>>comments.
>>
>>Regards,
>>
>>JL

Delivery-date: Tue, 06 Mar 2007 00:36:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 19:36:23 -0500
From: "Pandian, Vijay" <[email-masked]>
To: "Don Fedyk" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Don,
=20
The question I had regarding P&R was trying to figure out if one =
direction required a better P&R (say 1+1) and the reverse direction =
probably required some basic P&R (say Re-routing).
=20
So the requirement is to use the same "physical link" for the forward =
and reverse direction. Am I right?
=20
Regards,
=20
Vijay
=20
=20

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi,
=20
I have some basic questions, primarily trying to understand the scope of =
this ID as well as the application behind such a requirement.
=20
1. Does this ID address just an asymmetric Bandwidth requirement?=20

The postulation was that GMPLS today supports bi-directional service =
with a single RSVP-TE session creating a bidirectional LSP.  The most =
common implementation of this is Optical TDM networks.  Since this was =
the starting point, the ID postulates setting up an asymmetric service =
with a single asymmetric LSP.  (Like many new drafts it sets a =
requirement and postulates a an implementation.) =20
=20
So to your question besides bandwidth there is also underlying =
requirement to align with GMPLS single session procedures and support a =
bi-directional packet data plane as Ethernet does today.  A single =
bidirectional (in this case asymmetric BW capable) LSP.  In other words =
a single RSVP-TE session.  Several people have pointed out this is also =
achievable with two unidirectional RSVP-TE sessions (one at each end).  =
Rather than reopen that debate on this thread I will acknowledge the =
authors had a single session in mind more as a requirement of the =
technology.  Ethernet data forwarding is bi-directional symmetric and =
there are efficiencies in a single session of a bi-directional LSP.  On =
the other hand the issue is there is currently no way to specify the =
asymmetric BW. If you want to discuss the pros and cons of multiple =
sessions versus single there is already a thread on this (RE: I-D =
ACTION:draft-takacs-asym-bw-lsp-00.txt)
=20
|  2. How about other attributes? in particular LSP Protection & =
Recovery (P&R) related attributes?=20
=20
With respect to GMPLS, the plan was to allow bi-directional Protection =
or Recovery LSPs controlled by separate RSVP-TE sessions in separate =
from the single RSVP-TE session associated with the primary =
bidirectional LSP.  =20

3. If P&R are indeed different, doesn't it make sense to route them =
separately (separate CSPF calculation at each end) and eventually signal =
them independently as well?=20
=20

Hopefully I addressed part of this already. Recovery of the =
bi-directional LSP could be handled by another RSVP-TE session & LSP.  =
The data plane in our case must have a bi-directional symmetric path so =
you can only do a CSPF at one end and/or force the paths to align.=20

4. Is there a need for the forward and reverse flows to be on the same =
path?=20
=20

That is the way an Ethernet data plane works, and in my case this is =
where the requirement comes from. There is Ethernet data plane OAM and =
in some cases Ethernet forwarding rules that both require bi-directional =
symmetric paths.  The requirement is to be able to support native =
Ethernet loopback and data plane trace functions and bi-directional =
symmetry in the data plane is required.=20

5. What is "fate sharing"? I couldn't find this in other RFCs or IDs. Is =
it same as link/node/SRLG disjoint paths?=20
=20

Yes it is related.  A shared resource link group identifies shared =
resources at some granularity. Fate shared paths have shared resources =
at a very high level of granularity.  Disjoint paths have none or very =
few shared resources.  For a bidirectional path the shared fate comes =
from the fact that both direction have common resources and if one fails =
the other is likely to fail.   =20
=20
Regards,
Don=20

=20
Regards,
=20
Vijay

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

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

<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2>Don,</FONT></SPAN></DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
question I had regarding P&amp;R was trying to figure out if one =
direction=20
required a better P&amp;R (say 1+1) and the reverse=20
direction&nbsp;probably&nbsp;required&nbsp;some basic P&amp;R=20
(say&nbsp;Re-routing).</FONT></SPAN></DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =
size=3D2>So the=20
requirement is to use the same "physical link" for the forward and =
reverse=20
direction. Am I right?</FONT></SPAN></DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =

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

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

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

size=3D2>Vijay</FONT></SPAN></DIV>
<DIV><SPAN class=3D873282200-06032007><FONT face=3DArial color=3D#0000ff =

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

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Don Fedyk=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, March 05, 2007 =
6:41=20
  PM<BR><B>To:</B> Pandian, Vijay; [email-masked]<BR><B>Subject:</B> =
RE:=20
  Questions on draft-takacs-asym-bw-lsp-00.txt<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D964004621-05032007>Hi Vijay</SPAN></FONT></DIV><BR>
  <BLOCKQUOTE dir=3Dltr=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>Pandian,=20
    Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B>=20
    [email-masked]<BR><B>Subject:</B> Questions on=20
    draft-takacs-asym-bw-lsp-00.txt<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007>Hi,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>I =
have some=20
    basic questions, primarily trying to understand the scope of this ID =
as well=20
    as the application behind such a requirement.</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>1. Does=20
    this ID address just an asymmetric Bandwidth requirement?<SPAN=20
    class=3D964004621-05032007><FONT=20
    =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV></DIV></BL=
OCKQUOTE>
  <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
  size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>The=20
  postulation was that GMPLS today supports bi-directional service with =
a single=20
  RSVP-TE session creating a bidirectional LSP.&nbsp; The most common=20
  implementation of this is Optical TDM networks.</FONT>&nbsp;<FONT=20
  color=3D#0000ff> Since this was the starting point, the ID postulates =
setting up=20
  an asymmetric service with a single&nbsp;asymmetric LSP.&nbsp; (Like =
many new=20
  drafts it sets a requirement and postulates a an=20
  =
implementation.)&nbsp;&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></D=
IV>
  <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
  size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT=20
  color=3D#0000ff></FONT></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
  size=3D+0><FONT size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>So to=20
  your question besides bandwidth&nbsp;there&nbsp;is also underlying =
requirement=20
  to align with GMPLS single session=20
  </FONT></SPAN></FONT></FONT></SPAN></FONT><FONT face=3DArial><SPAN=20
  class=3D232211417-05032007><FONT size=3D+0><FONT color=3D#0000ff =
size=3D2><SPAN=20
  class=3D964004621-05032007>procedures and support a bi-directional =
packet data=20
  plane as Ethernet does today.&nbsp; A single bidirectional (in this =
case=20
  asymmetric BW capable) LSP.&nbsp; In other words a single RSVP-TE=20
  session.&nbsp; Several people have pointed out this is also achievable =
with=20
  two unidirectional RSVP-TE sessions (one at each end).&nbsp; Rather =
than=20
  reopen that debate on this thread I will acknowledge the =
authors&nbsp;had a=20
  single session in mind more as a requirement of the technology. =
&nbsp;Ethernet=20
  data forwarding is bi-directional symmetric and there are efficiencies =
in a=20
  single session of a bi-directional=20
  LSP.</SPAN></FONT></FONT></SPAN></FONT><FONT face=3DArial><SPAN=20
  class=3D232211417-05032007><FONT size=3D+0><FONT color=3D#0000ff =
size=3D2><SPAN=20
  class=3D964004621-05032007>&nbsp; On the other hand the issue is there =
is=20
  currently no way to specify the asymmetric BW. If you want to discuss =
the pros=20
  and cons of multiple sessions versus single there is already a thread =
on this=20
  (RE: I-D=20
  =
ACTION:draft-takacs-asym-bw-lsp-00.txt)</SPAN></FONT></FONT></SPAN></FONT=
></DIV>
  <DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT=20
  size=3D+0><FONT color=3D#0000ff size=3D2><SPAN=20
  class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
  face=3DArial><SPAN class=3D232211417-05032007><FONT size=3D+0><FONT =
color=3D#0000ff=20
  size=3D2><SPAN =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
  face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
  class=3D964004621-05032007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
  size=3D2><FONT color=3D#0000ff><SPAN class=3D964004621-05032007><FONT=20
  color=3D#000000><FONT color=3D#0000ff>|</FONT><STRONG>=20
  </STRONG></FONT>&nbsp;</SPAN></FONT><SPAN =
class=3D232211417-05032007>2. How=20
  about other attributes? in particular LSP Protection &amp; Recovery =
(P&amp;R)=20
  related attributes?<SPAN class=3D964004621-05032007><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D232211417-05032007><SPAN=20
  =
class=3D964004621-05032007></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
  <DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT size=3D+0><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D232211417-05032007><SPAN =
class=3D964004621-05032007><FONT=20
  color=3D#0000ff>With respect to GMPLS, the plan was to =
allow&nbsp;bi-directional=20
  Protection or Recovery LSPs controlled by separate RSVP-TE sessions in =

  separate from&nbsp;the single RSVP-TE session associated with the =
primary=20
  bidirectional LSP.=20
&nbsp;</FONT>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>3. If=20
    P&amp;R are indeed different,&nbsp;doesn't&nbsp;it make sense =
to&nbsp;route=20
    them separately (separate CSPF calculation at each end) and=20
    eventually&nbsp;signal them independently as well?<SPAN=20
    class=3D964004621-05032007><FONT=20
    color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
    =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>Hopefully I=20
  addressed part of this already. Recovery of the bi-directional LSP =
could be=20
  handled by another RSVP-TE session &amp; LSP.&nbsp; The data plane in =
our case=20
  must have a bi-directional symmetric path so you can only do a CSPF at =
one end=20
  and/or force the paths to=20
align.&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>4. Is=20
    there a need for the forward and reverse flows to be on the same =
path?<SPAN=20
    class=3D964004621-05032007><FONT=20
    color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
    =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>That =
is the way an=20
  Ethernet data plane works, and in my case this is where the =
requirement comes=20
  from. There is Ethernet data plane OAM and in some cases Ethernet =
forwarding=20
  rules that both require bi-directional symmetric paths.&nbsp; The =
requirement=20
  is to be able to support native Ethernet loopback and data plane trace =

  functions and bi-directional symmetry in the data plane is required.=20
  </FONT></SPAN></FONT></FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>5. What is=20
    "fate sharing"? I couldn't find this in other RFCs or IDs. Is it =
same as=20
    link/node/SRLG disjoint paths?<SPAN class=3D964004621-05032007><FONT =

    color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
    <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
    =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>Yes it =
is=20
  related.&nbsp; A shared resource link group identifies shared =
resources at=20
  some granularity. Fate shared paths have shared resources at a very =
high level=20
  of granularity.&nbsp;&nbsp;Disjoint paths have none or very few shared =

  resources.&nbsp;&nbsp;For a bidirectional path the shared fate comes =
from the=20
  fact that both direction have common resources and if one fails the =
other is=20
  likely to=20
  fail.&nbsp;&nbsp;&nbsp;</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D964004621-05032007>Regards,</SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT =
face=3DArial><FONT=20
  color=3D#0000ff size=3D2><SPAN class=3D964004621-05032007>Don=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007>Regards,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    =
class=3D232211417-05032007>Vijay</SPAN></FONT></DIV></BLOCKQUOTE></BLOCKQ=
UOTE></BODY></HTML>

------_=_NextPart_001_01C75F87.7793B3D3--

Delivery-date: Mon, 05 Mar 2007 23:46:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "MEURIC Julien RD-CORE-LAN" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: New communication from the OIF
Date: Mon, 5 Mar 2007 23:46:21 -0000
Organization: Old Dog Consulting

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of multiple 
Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a construction, 
like the label stack in MPLS, is easily available in Ethernet. Is there a 
specific reason why the end-to-end labels must be visible in the data plane 
in the core of the network?

In this sense, the request for a concatenation of labels is simply so that 
multiple labels can be treated in the same way, not (unlike the TDM case) in 
order to construct some for of virtual concatenation. If it were the case 
that each Ethernet label had a limited amount of bandwidth associated and it 
was necessary to clump labels to make a bigger unit of bandwidth, the case 
would be different, but that does not apply to Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message between 
source and destination when multiple LSPs are formed between the same pair 
of end-points. One might argue the same case in L3VPN deployments.

Adrian

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[email-masked]>
        cc:
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
====
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked],
IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating
large numbers of VLAN IDs in the Label objects in control signaling
messages
for Ethernet connections with frame switching granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on
October 2006.

Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further
definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

Delivery-date: Mon, 05 Mar 2007 23:43:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 18:41:24 -0500
From: "Don Fedyk" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75F7F.CA22882C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Vijay

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pandian, Vijay
	Sent: Monday, March 05, 2007 2:07 PM
	To: [email-masked]
	Subject: Questions on draft-takacs-asym-bw-lsp-00.txt
=09
=09
	Hi,
	=20
	I have some basic questions, primarily trying to understand the
scope of this ID as well as the application behind such a requirement.
	=20
	1. Does this ID address just an asymmetric Bandwidth
requirement?=20

The postulation was that GMPLS today supports bi-directional service
with a single RSVP-TE session creating a bidirectional LSP.  The most
common implementation of this is Optical TDM networks.  Since this was
the starting point, the ID postulates setting up an asymmetric service
with a single asymmetric LSP.  (Like many new drafts it sets a
requirement and postulates a an implementation.) =20
=20
So to your question besides bandwidth there is also underlying
requirement to align with GMPLS single session procedures and support a
bi-directional packet data plane as Ethernet does today.  A single
bidirectional (in this case asymmetric BW capable) LSP.  In other words
a single RSVP-TE session.  Several people have pointed out this is also
achievable with two unidirectional RSVP-TE sessions (one at each end).
Rather than reopen that debate on this thread I will acknowledge the
authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)
=20
|  2. How about other attributes? in particular LSP Protection &
Recovery (P&R) related attributes?=20
=20
With respect to GMPLS, the plan was to allow bi-directional Protection
or Recovery LSPs controlled by separate RSVP-TE sessions in separate
from the single RSVP-TE session associated with the primary
bidirectional LSP.  =20

	3. If P&R are indeed different, doesn't it make sense to route
them separately (separate CSPF calculation at each end) and eventually
signal them independently as well?=20
	=20

Hopefully I addressed part of this already. Recovery of the
bi-directional LSP could be handled by another RSVP-TE session & LSP.
The data plane in our case must have a bi-directional symmetric path so
you can only do a CSPF at one end and/or force the paths to align.=20

	4. Is there a need for the forward and reverse flows to be on
the same path?=20
	=20

That is the way an Ethernet data plane works, and in my case this is
where the requirement comes from. There is Ethernet data plane OAM and
in some cases Ethernet forwarding rules that both require bi-directional
symmetric paths.  The requirement is to be able to support native
Ethernet loopback and data plane trace functions and bi-directional
symmetry in the data plane is required.=20

	5. What is "fate sharing"? I couldn't find this in other RFCs or
IDs. Is it same as link/node/SRLG disjoint paths?=20
	=20

Yes it is related.  A shared resource link group identifies shared
resources at some granularity. Fate shared paths have shared resources
at a very high level of granularity.  Disjoint paths have none or very
few shared resources.  For a bidirectional path the shared fate comes
from the fact that both direction have common resources and if one fails
the other is likely to fail.   =20
=20
Regards,
Don=20

	=20
	Regards,
	=20
	Vijay

------_=_NextPart_001_01C75F7F.CA22882C
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=3D964004621-05032007>Hi Vijay</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=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>Pandian,=20
  Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Questions on=20
  draft-takacs-asym-bw-lsp-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007>Hi,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>I =
have some basic=20
  questions, primarily trying to understand the scope of this ID as well =
as the=20
  application behind such a requirement.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>1. Does this=20
  ID address just an asymmetric Bandwidth requirement?<SPAN=20
  class=3D964004621-05032007><FONT=20
  =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV></DIV></BL=
OCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT><FONT=20
size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>The =
postulation was=20
that GMPLS today supports bi-directional service with a single RSVP-TE =
session=20
creating a bidirectional LSP.&nbsp; The most common implementation of =
this is=20
Optical TDM networks.</FONT>&nbsp;<FONT color=3D#0000ff> Since this was =
the=20
starting point, the ID postulates setting up an asymmetric service with =
a=20
single&nbsp;asymmetric LSP.&nbsp; (Like many new drafts it sets a =
requirement=20
and postulates a an=20
implementation.)&nbsp;&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></D=
IV>
<DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT><FONT=20
size=3D2><SPAN class=3D964004621-05032007><FONT=20
color=3D#0000ff></FONT></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT><FONT=20
size=3D2><SPAN class=3D964004621-05032007><FONT color=3D#0000ff>So to =
your question=20
besides bandwidth&nbsp;there&nbsp;is also underlying requirement to =
align with=20
GMPLS single session </FONT></SPAN></FONT></FONT></SPAN></FONT><FONT=20
face=3DArial><SPAN class=3D232211417-05032007><FONT><FONT =
color=3D#0000ff size=3D2><SPAN=20
class=3D964004621-05032007>procedures and support a bi-directional =
packet data=20
plane as Ethernet does today.&nbsp; A single bidirectional (in this case =

asymmetric BW capable) LSP.&nbsp; In other words a single RSVP-TE =
session.&nbsp;=20
Several people have pointed out this is also achievable with two =
unidirectional=20
RSVP-TE sessions (one at each end).&nbsp; Rather than reopen that debate =
on this=20
thread I will acknowledge the authors&nbsp;had a single session in mind =
more as=20
a requirement of the technology. &nbsp;Ethernet data forwarding is=20
bi-directional symmetric and there are efficiencies in a single session =
of a=20
bi-directional LSP.</SPAN></FONT></FONT></SPAN></FONT><FONT =
face=3DArial><SPAN=20
class=3D232211417-05032007><FONT><FONT color=3D#0000ff size=3D2><SPAN=20
class=3D964004621-05032007>&nbsp; On the other hand the issue is there =
is=20
currently no way to specify the asymmetric BW. If you want to discuss =
the pros=20
and cons of multiple sessions versus single there is already a thread on =
this=20
(RE: I-D=20
ACTION:draft-takacs-asym-bw-lsp-00.txt)</SPAN></FONT></FONT></SPAN></FONT=
></DIV>
<DIV dir=3Dltr><FONT face=3DArial><SPAN =
class=3D232211417-05032007><FONT><FONT=20
color=3D#0000ff size=3D2><SPAN=20
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
face=3DArial><SPAN class=3D232211417-05032007><FONT><FONT =
color=3D#0000ff size=3D2><SPAN=20
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN></FONT><FONT=20
face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D964004621-05032007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT><FONT =
face=3DArial><FONT size=3D2><FONT=20
color=3D#0000ff><SPAN class=3D964004621-05032007><FONT =
color=3D#000000><FONT=20
color=3D#0000ff>|</FONT><STRONG> =
</STRONG></FONT>&nbsp;</SPAN></FONT><SPAN=20
class=3D232211417-05032007>2. How about other attributes? in particular =
LSP=20
Protection &amp; Recovery (P&amp;R) related attributes?<SPAN=20
class=3D964004621-05032007><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT><FONT =
face=3DArial><FONT size=3D2><SPAN=20
class=3D232211417-05032007><SPAN=20
class=3D964004621-05032007></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
<DIV dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT><FONT =
face=3DArial><FONT size=3D2><SPAN=20
class=3D232211417-05032007><SPAN class=3D964004621-05032007><FONT =
color=3D#0000ff>With=20
respect to GMPLS, the plan was to allow&nbsp;bi-directional Protection =
or=20
Recovery LSPs controlled by separate RSVP-TE sessions in separate =
from&nbsp;the=20
single RSVP-TE session associated with the primary bidirectional LSP.=20
&nbsp;</FONT>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>3. If=20
  P&amp;R are indeed different,&nbsp;doesn't&nbsp;it make sense =
to&nbsp;route=20
  them separately (separate CSPF calculation at each end) and=20
  eventually&nbsp;signal them independently as well?<SPAN=20
  class=3D964004621-05032007><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D964004621-05032007><FONT color=3D#0000ff>Hopefully I addressed =
part of this=20
already. Recovery of the bi-directional LSP could be handled by another =
RSVP-TE=20
session &amp; LSP.&nbsp; The data plane in our case must have a =
bi-directional=20
symmetric path so you can only do a CSPF at one end and/or force the =
paths to=20
align.&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>4. Is there=20
  a need for the forward and reverse flows to be on the same path?<SPAN=20
  class=3D964004621-05032007><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D964004621-05032007><FONT color=3D#0000ff>That is the way an =
Ethernet data=20
plane works, and in my case this is where the requirement comes from. =
There is=20
Ethernet data plane OAM and in some cases Ethernet forwarding rules that =
both=20
require bi-directional symmetric paths.&nbsp; The requirement is to be =
able to=20
support native Ethernet loopback and data plane trace functions and=20
bi-directional symmetry in the data plane is required.=20
</FONT></SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2>5. What is=20
  "fate sharing"? I couldn't find this in other RFCs or IDs. Is it same =
as=20
  link/node/SRLG disjoint paths?<SPAN class=3D964004621-05032007><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D964004621-05032007><FONT color=3D#0000ff>Yes it is =
related.&nbsp; A shared=20
resource link group identifies shared resources at some granularity. =
Fate shared=20
paths have shared resources at a very high level of=20
granularity.&nbsp;&nbsp;Disjoint paths have none or very few shared=20
resources.&nbsp;&nbsp;For a bidirectional path the shared fate comes =
from the=20
fact that both direction have common resources and if one fails the =
other is=20
likely to =
fail.&nbsp;&nbsp;&nbsp;</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2><SPAN =
class=3D964004621-05032007></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2><SPAN =
class=3D964004621-05032007>Regards,</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D232211417-05032007><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2><SPAN class=3D964004621-05032007>Don =
</SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D232211417-05032007>Vijay</SPAN></FONT></DIV></BLOCKQUOTE></BODY><=
/HTML>

------_=_NextPart_001_01C75F7F.CA22882C--

Delivery-date: Mon, 05 Mar 2007 20:42:24 +0000
Content-class: urn:content-classes:message
Subject: New Draft : LMP Graceful Restart Procedure
Date: Mon, 5 Mar 2007 14:41:47 -0600
From: "Bardalai, Snigdho" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Dear CCAMPers,
We've posted a new draft: LMP Graceful Restart Procedure.
Your comments are very welcome.=20

Thanks,

Snigdho

Abstract

For the LMP graceful restart functionality, under some circumstance the =
restart node may get wrong LMP states from its neighbor. So the =
clarification of LMP graceful restart procedure is described in this =
document. A control-channel failure following some form of network re- =
configuration typically could lead to the release of LSP resources. =
Since LMP graceful restart prevents the re-discovery of the control- =
channel, link verification will not be triggered. The only way to =
recover LMP from this state is by some operator intervention.
=20
Because we have missed the final ID submission cut-off date, this draft =
can be found under the missing drafts link at:

<http://www.olddog.co.uk/ccamp.htm>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7234.20">
<TITLE>New Draft : LMP Graceful Restart Procedure</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT FACE=3D"Arial">Dear CCAMPers,</FONT>

<BR><FONT FACE=3D"Arial">We&#8217;ve posted a new draft: LMP Graceful =
Restart Procedure.</FONT>

<BR><FONT FACE=3D"Arial">Your comments are very welcome. </FONT>
</P>

<P><FONT FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT FACE=3D"Arial">Snigdho</FONT>
</P>

<P><FONT FACE=3D"Courier">Abstract</FONT>
</P>

<P><FONT FACE=3D"Courier">For the LMP graceful restart functionality, =
under some circumstance the restart node may get wrong LMP states from =
its neighbor. So the clarification of LMP graceful restart procedure is =
described in this document. A control-channel failure following some =
form of network re- configuration typically could lead to the release of =
LSP resources. Since LMP graceful restart prevents the re-discovery of =
the control- channel, link verification will not be triggered. The only =
way to recover LMP from this state is by some operator =
intervention.</FONT></P>

<P><FONT FACE=3D"Arial">&nbsp;</FONT>

<BR><FONT FACE=3D"Arial">Because we have missed the final ID submission =
cut-off date, this draft can be found under the missing drafts link =
at:</FONT>
</P>

<P><U><FONT COLOR=3D"#0000FF" FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</A>&gt;</FONT></U>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C75F66.B1D5D5C6--

Delivery-date: Mon, 05 Mar 2007 20:20:34 +0000
Content-class: urn:content-classes:message
Subject: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt 
Date: Mon, 5 Mar 2007 14:19:28 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

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: Mon, 05 Mar 2007 20:13:11 +0000
Content-class: urn:content-classes:message
Subject: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Date: Mon, 5 Mar 2007 14:12:35 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

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: Mon, 05 Mar 2007 20:09:15 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt 
Date: Mon, 5 Mar 2007 14:07:40 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

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: Mon, 05 Mar 2007 19:07:01 +0000
Content-class: urn:content-classes:message
Subject: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 14:07:07 -0500
From: "Pandian, Vijay" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi,
=20
I have some basic questions, primarily trying to understand the scope of =
this ID as well as the application behind such a requirement.
=20
1. Does this ID address just an asymmetric Bandwidth requirement?
2. How about other attributes? in particular LSP Protection & Recovery =
(P&R) related attributes?
3. If P&R are indeed different, doesn't it make sense to route them =
separately (separate CSPF calculation at each end) and eventually signal =
them independently as well?
4. Is there a need for the forward and reverse flows to be on the same =
path?
5. What is "fate sharing"? I couldn't find this in other RFCs or IDs. Is =
it same as link/node/SRLG disjoint paths?
=20
Regards,
=20
Vijay

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

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

<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>I have =
some basic=20
questions, primarily trying to understand the scope of this ID as well =
as the=20
application behind such a requirement.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>1. =
Does this ID=20
address just an asymmetric Bandwidth requirement?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>2. How =
about other=20
attributes? in particular LSP Protection &amp; Recovery (P&amp;R) =
related=20
attributes?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>3. If =
P&amp;R are=20
indeed different,&nbsp;doesn't&nbsp;it make sense to&nbsp;route them =
separately=20
(separate CSPF calculation at each end) and eventually&nbsp;signal them=20
independently as well?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>4. Is =
there a need=20
for the forward and reverse flows to be on the same =
path?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D232211417-05032007>5. =
What is "fate=20
sharing"? I couldn't find this in other RFCs or IDs. Is it same as=20
link/node/SRLG disjoint paths?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D232211417-05032007>Vijay</SPAN></FONT></DIV></FONT></DIV></BODY><=
/HTML>

------_=_NextPart_001_01C75F59.785482B8--

Delivery-date: Mon, 05 Mar 2007 17:45:47 +0000
Content-class: urn:content-classes:message
Subject: RE: New communication from the OIF
Date: Mon, 5 Mar 2007 18:44:26 +0100
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

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

adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their=20

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web=20

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
=3D=3D=3D=3D
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,=20
[email-masked],
IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating=20
large numbers of VLAN IDs in the Label objects in control signaling=20
messages=20
for Ethernet connections with frame switching granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on=20
October 2006.

Accordingly, our carrier WG has developed a small set of illustrative=20
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these=20
scenarios can be supported using existing GMPLS methods or if any
further=20
definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair=20

Delivery-date: Mon, 05 Mar 2007 16:51:46 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 17:49:56 +0100
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Diego Caviglia \(GA/ERI\)" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>

Hi Igor.

Please, find my answers in-line.

Regards,

Julien

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

Julien,

Please, see in-line.

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

Hi all.

To answer the 1st question, I would say that there is a requirement for
asymmetrical bidirectional *service* (think about IP TV transport for
instance). What is more, as Igor said, being able to handle both
directions as a single service brings advantages (such as fate sharing),
especially in terms of operating a network. Question is: does this
necessarily map to "single LSP"? Not so sure...

Then, I do not see any strong requirement for having a single signalling
exchange.

IB>> Well, if everything goes smoothly, the setup of a single
bi-directional LSP is twice as fast as the setup of two unidirectional
LSPs. If there are some provisioning problems, then the difference may
be much bigger. Think about the situation when there is a resource
allocation failure for the opposite direction on the service node, say,
next after the ingress. If you setup a single bi-directional LSP the
failure is detected almost right away, the path is recomputed and LSP is
re-routed. However, if you setup two reciprocal unidirectional LSPs, the
failure won't be even detected before the Path message for the second
LSP arrives on the failure detecting node. And now you will have to
signal the release of both LSPs and start the whole setup again. So, the
recovery time won't be all that great, don't you agree?

[JM] I agree with you. That is why, for recovery, a node should not rely
on a third party (such as a manager or the other end-node). However, you
are only saying that a single LSP may fit the requirement, but I still
cannot say that the requirement leads only to this exact solution. :-)

 Besides, I do not think a scenario with a management system
communicating with both end-nodes should be excluded neither. However,
in this case, it may be detrimental for the control plane to rely on an
external party to correlate both directions.

IB>> My customers say that if one set's up a soft-PVC and one needs to
access both edges of the soft-PVC, one might just touch all other nodes,
that is, setup a PVC instead. They believe that it is a significant
advantage to be able to control service from one node. That's what makes
the service provisioning *dynamic*. Frankly, as I see it the only
situation for the management plane to access nodes other than ingress is
when there is a problem with the CP. For example, one of the controllers
went out of service and there is a need to tear down or reroute the
service.

[JM] I do not think it is an issue of communication sessions. A PVC does
not provide with the same kind of services as a soft-PVC, whether it
rely on a bi-directional or 2 uni-directional LSPs: differences are
deeper than only head-node handling. Of course it is an advantage to
control the service from a single point (node, manager...), but I do not
see how provisioning from 2 nodes makes it less dynamic than
provisioning from one node... Anyway I admit that it may ease automatic
end-to-end provisioning in case of multi-layer or multi-domain services.

Can you give me other examples when such need arises?

[JM] I think if you want use the information in MIBs, you need to
communicate with all nodes... From my point of view, the requirement is
managing from a single *point* and defining this point as a node is only
*a* (valuable) solution.

Thanks,
Igor
 =20

Diego, to answer you, I think you are correct: re-using the RRO of the
1st one is an option to consider when routing by the controling plane,
and using management-built ERO for both directions is valid in case of
manual routing. As a result, it looks like tools are there to for
provisioning, nevertheless it may bring an issue to guarantee fate
sharing in case of recovery.

Regards,

Julien

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia (GA/ERI)

>From my experience I can quote everything Igor said.  GMPLS tunnel
establishment is, AFAIK, always driven by the NMS/OSS that (quoting Neil
Harrison here) is the King.

=20

So I think that in the real world the Ingress node knows the upstream
and downstream bandwidth of the GMPLS Tunnel is going to set-up.

Moreover if I'll use two uni-directional LSPs in order to set-up an LSP
with asymmetrical bandwidth requirement I can force the path of the two
LSPs to be the same?  Do I have to use the RRO of the first one as ERO
for the second one?  Or I suppose to use a fully defined ERO for both
the two LSP?  In this case I do suppose that the ERO has been calculated
by the NMS?

=20

Regards

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The
request may not (and normally does not) contain an explicit path, but it
definitely contains all bandwidth parameters, because the tunnel was
requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always
knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management
and control plane should always hapen at one (ingress) node.

Igor

PS It would be interesting to hear from providers on this topic.

[email-masked] wrote:

"Adrian Farrel"=20
04/03/2007 00:35
Please respond to "Adrian Farrel"

To: "Igor Bryskin" , Dimitri=20
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: , "Don Fedyk"=20
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> 3. if a) is selected there is no other choice than an upstream
flowspec=20
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know

the=20
bandwidth to request? If it does then there is no need for a TSpec on
the=20
Resv as the reservation has already been made commensurate with the=20
FlowSpec=20
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec=20
=3D< tspec, nevertheless, after the tspec may "increase" and therefore=20
the flowspec may be adapted=20

If the ingress does *not* know and needs to see a TSpec from the egress,

then we need another Path exchange after the Resv in order to make the=20
actual reservations. In that case it really would be a mess and not
worth=20
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress

is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation
in
a corner case, whereas a technique making use of association object
would
prevent all this protocol massaging, keep full backward compatibility,
and
provide full flexibility

A=20

Delivery-date: Mon, 05 Mar 2007 15:21:34 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 10:19:29 -0500
From: "Don Fedyk" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75F39.ABCBCF8C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi All
=20
Igor has captured my understanding as well that the situation we are
concerned with is a GMPLS control plane being deployed to map the
capabilities from a management plane.=20
=20
In terms of this requirement I see GMPLS control of optical/tdm and
GMPLS control of Ethernet being just as you say: The ingress node knows
the bandwidth for both directions.=20
 =20
Regards,
Don=20
=20

________________________________

	From: Igor Bryskin [mailto:[email-masked]]=20
	Sent: Sunday, March 04, 2007 8:56 AM
	To: [email-masked]; Adrian Farrel
	Cc: [email-masked]; Fedyk, Don (BL60:1A00); Igor Bryskin
	Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
=09
=09
	Adrian and Dimitri,
=09
	When a GMPLS tunnel is setup, it is setup for a reason.  Let's
say, management plane requests a tunnel ingress node to setup a tunnel.
The request may not (and normally does not) contain an explicit path,
but it definitely contains all bandwidth parameters, because the tunnel
was requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
	So, yes, I'd say that it is safe to assume that ingress node
always knows about bandiwidth in both directions.
=09
	I'd say even more. We have a strict requirement from our
customers that actively deploy our GMPLS CP, that a communication
between management and control plane should always hapen at one
(ingress) node.
=09
	Igor
=09
	PS It would be interesting to hear from providers on this topic.
=09
	[email-masked] wrote:=20

		"Adrian Farrel"=20
		04/03/2007 00:35
		Please respond to "Adrian Farrel"
	=09
		To: "Igor Bryskin" , Dimitri=20
		PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		cc: , "Don Fedyk"=20
		Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		> 3. if a) is selected there is no other choice than an
upstream flowspec=20
		in
		> the Path msg and a upstream tspec in the Resv message
	=09
		That *does* raise an interesting question. Namely, does
the ingress know=20
		the=20
		bandwidth to request? If it does then there is no need
for a TSpec on the=20
		Resv as the reservation has already been made
commensurate with the=20
		FlowSpec=20
		on the Path.
	=09
		-> if you do that you prevent the ingress-side to never
adapt resource
		reservation to the traffic parameters of the egress (in
fact, it would
		boil down to "single-sided" asymmetry forever)
	=09
		-> hence, initially you must satisfy at least condition
where flowspec=20
		=3D< tspec, nevertheless, after the tspec may "increase"
and therefore=20
		the flowspec may be adapted=20
	=09
		If the ingress does *not* know and needs to see a TSpec
from the egress,=20
		then we need another Path exchange after the Resv in
order to make the=20
		actual reservations. In that case it really would be a
mess and not worth=20
		trying to shoe-horn into a bidirectional LSP format.
	=09
		-> this is what i said also to don, the case where
initially the ingress=20
		is completely unaware of what it can reserve is
impossible without major
		protocol modifications
	=09
		-> my partial conclusion, is that a workable asym bw lsp
doesn't elevate
		the need for the general case, and only provides
apparent facilitation in
		a corner case, whereas a technique making use of
association object would
		prevent all this protocol massaging, keep full backward
compatibility, and
		provide full flexibility
	=09
	=09
		A=20
	=09
	=09
	=09
	=09
	=09

=09
________________________________

	It's here! Your new message!
	Get new email alerts
<http://us.rd.yahoo.com/evt=3D49938/*http://tools.search.yahoo.com/toolba=
r
/features/mail/>  with the free Yahoo! Toolbar.
<http://us.rd.yahoo.com/evt=3D49938/*http://tools.search.yahoo.com/toolba=
r
/features/mail/>=20

------_=_NextPart_001_01C75F39.ABCBCF8C
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><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D139114713-05032007>Hi All</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D139114713-05032007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Igor has captured my understanding as well that =
the=20
situation we are concerned with is a GMPLS control plane being deployed =
to map=20
the capabilities from a management plane.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN><SPAN =
class=3D139114713-05032007><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>In terms of this requirement I see GMPLS =
control of=20
optical/tdm and GMPLS control of Ethernet being just as you say: The =
ingress=20
node knows the bandwidth for both directions.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp; </FONT></SPAN><SPAN =
class=3D139114713-05032007><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Don </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D139114713-05032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<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> Igor Bryskin=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Sunday, March 04, 2007 =
8:56=20
  AM<BR><B>To:</B> [email-masked]; Adrian=20
  Farrel<BR><B>Cc:</B> [email-masked]; Fedyk, Don (BL60:1A00); Igor=20
  Bryskin<BR><B>Subject:</B> Re: I-D=20
  ACTION:draft-takacs-asym-bw-lsp-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>Adrian and Dimitri,<BR><BR>When a GMPLS tunnel is setup, it =
is=20
  setup for a reason.&nbsp; Let's say, management plane requests a =
tunnel=20
  ingress node to setup a tunnel. The request may not (and normally does =
not)=20
  contain an explicit path, but it definitely contains all bandwidth =
parameters,=20
  because the tunnel was requested, as I siad,&nbsp; for a particular=20
  reason&nbsp; (application, SLA, etc.). Also, how else you can ensure =
the fate=20
  sharing other than computing a path on the ingress node taking in=20
  consideration the bandwidth requirements for both directions?<BR>So, =
yes, I'd=20
  say that it is safe to assume that ingress node always knows about =
bandiwidth=20
  in both directions.<BR><BR>I'd say even more. We have a strict =
requirement=20
  from our customers that actively deploy our GMPLS CP, that a =
communication=20
  between management and control plane should always hapen at one =
(ingress)=20
  node.<BR><BR>Igor<BR><BR>PS It would be interesting to hear from =
providers on=20
  this =
topic.<BR><BR><B><I>[email-masked]</I></B>=20
wrote:
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(16,16,255) 2px solid">"Adrian=20
    Farrel" <[email-masked]><BR>04/03/2007 00:35<BR>Please respond =
to=20
    "Adrian Farrel"<BR><BR>To: "Igor Bryskin" <[email-masked]>, =
Dimitri=20
    <BR>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<BR>cc: <[email-masked]>, =
"Don=20
    Fedyk" <[email-masked]><BR>Subject: Re: I-D=20
    ACTION:draft-takacs-asym-bw-lsp-00.txt<BR><BR><BR>&gt; 3. if a) is =
selected=20
    there is no other choice than an upstream flowspec <BR>in<BR>&gt; =
the Path=20
    msg and a upstream tspec in the Resv message<BR><BR>That *does* =
raise an=20
    interesting question. Namely, does the ingress know <BR>the =
<BR>bandwidth to=20
    request? If it does then there is no need for a TSpec on the =
<BR>Resv as the=20
    reservation has already been made commensurate with the <BR>FlowSpec =
<BR>on=20
    the Path.<BR><BR>-&gt; if you do that you prevent the ingress-side =
to never=20
    adapt resource<BR>reservation to the traffic parameters of the =
egress (in=20
    fact, it would<BR>boil down to "single-sided" asymmetry=20
    forever)<BR><BR>-&gt; hence, initially you must satisfy at least =
condition=20
    where flowspec <BR>=3D&lt; tspec, nevertheless, after the tspec may =
"increase"=20
    and therefore <BR>the flowspec may be adapted <BR><BR>If the ingress =
does=20
    *not* know and needs to see a TSpec from the egress, <BR>then we =
need=20
    another Path exchange after the Resv in order to make the <BR>actual =

    reservations. In that case it really would be a mess and not worth=20
    <BR>trying to shoe-horn into a bidirectional LSP =
format.<BR><BR>-&gt; this=20
    is what i said also to don, the case where initially the ingress =
<BR>is=20
    completely unaware of what it can reserve is impossible without=20
    major<BR>protocol modifications<BR><BR>-&gt; my partial conclusion, =
is that=20
    a workable asym bw lsp doesn't elevate<BR>the need for the general =
case, and=20
    only provides apparent facilitation in<BR>a corner case, whereas a =
technique=20
    making use of association object would<BR>prevent all this protocol=20
    massaging, keep full backward compatibility, and<BR>provide full=20
    flexibility<BR><BR><BR>A=20
    =
<BR><BR><BR><BR><BR></[email-masked]></[email-masked]></I_BRYSKIN=
@YAHOO.COM></[email-masked]></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>
  It's here! Your new message!<BR>Get <A=20
  =
href=3D"http://us.rd.yahoo.com/evt=3D49938/*http://tools.search.yahoo.com=
/toolbar/features/mail/">new=20
  email alerts</A> with the free <A=20
  =
href=3D"http://us.rd.yahoo.com/evt=3D49938/*http://tools.search.yahoo.com=
/toolbar/features/mail/">Yahoo!=20
  Toolbar.</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C75F39.ABCBCF8C--

Delivery-date: Mon, 05 Mar 2007 14:07:56 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 15:03:47 +0100
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Diego Caviglia \(GA/ERI\)" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>

Hi all.

To answer the 1st question, I would say that there is a requirement for
asymmetrical bidirectional *service* (think about IP TV transport for
instance). What is more, as Igor said, being able to handle both
directions as a single service brings advantages (such as fate sharing),
especially in terms of operating a network. Question is: does this
necessarily map to "single LSP"? Not so sure...

Then, I do not see any strong requirement for having a single signalling
exchange. Besides, I do not think a scenario with a management system
communicating with both end-nodes should be excluded neither. However,
in this case, it may be detrimental for the control plane to rely on an
external party to correlate both directions.

Diego, to answer you, I think you are correct: re-using the RRO of the
1st one is an option to consider when routing by the controling plane,
and using management-built ERO for both directions is valid in case of
manual routing. As a result, it looks like tools are there to for
provisioning, nevertheless it may bring an issue to guarantee fate
sharing in case of recovery.

Regards,

Julien

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia (GA/ERI)

>From my experience I can quote everything Igor said.  GMPLS tunnel
establishment is, AFAIK, always driven by the NMS/OSS that (quoting Neil
Harrison here) is the King.

=20

So I think that in the real world the Ingress node knows the upstream
and downstream bandwidth of the GMPLS Tunnel is going to set-up.

Moreover if I'll use two uni-directional LSPs in order to set-up an LSP
with asymmetrical bandwidth requirement I can force the path of the two
LSPs to be the same?  Do I have to use the RRO of the first one as ERO
for the second one?  Or I suppose to use a fully defined ERO for both
the two LSP?  In this case I do suppose that the ERO has been calculated
by the NMS?

=20

Regards

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The
request may not (and normally does not) contain an explicit path, but it
definitely contains all bandwidth parameters, because the tunnel was
requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always
knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management
and control plane should always hapen at one (ingress) node.

Igor

PS It would be interesting to hear from providers on this topic.

[email-masked] wrote:

"Adrian Farrel"=20
04/03/2007 00:35
Please respond to "Adrian Farrel"

To: "Igor Bryskin" , Dimitri=20
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: , "Don Fedyk"=20
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> 3. if a) is selected there is no other choice than an upstream
flowspec=20
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know

the=20
bandwidth to request? If it does then there is no need for a TSpec on
the=20
Resv as the reservation has already been made commensurate with the=20
FlowSpec=20
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec=20
=3D< tspec, nevertheless, after the tspec may "increase" and therefore=20
the flowspec may be adapted=20

If the ingress does *not* know and needs to see a TSpec from the egress,

then we need another Path exchange after the Resv in order to make the=20
actual reservations. In that case it really would be a mess and not
worth=20
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress

is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation
in
a corner case, whereas a technique making use of association object
would
prevent all this protocol massaging, keep full backward compatibility,
and
provide full flexibility

A=20

Delivery-date: Mon, 05 Mar 2007 08:13:22 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 09:11:48 +0100
From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>

This is a multi-part message in MIME format.

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

>From my experience I can quote everything Igor said.  GMPLS tunnel
establishment is, AFAIK, always driven by the NMS/OSS that (quoting Neil
Harrison here) is the King.

=20

So I think that in the real world the Ingress node knows the upstream
and downstream bandwidth of the GMPLS Tunnel is going to set-up.

Moreover if I'll use two uni-directional LSPs in order to set-up an LSP
with asymmetrical bandwidth requirement I can force the path of the two
LSPs to be the same?  Do I have to use the RRO of the first one as ERO
for the second one?  Or I suppose to use a fully defined ERO for both
the two LSP?  In this case I do suppose that the ERO has been calculated
by the NMS?

=20

Regards

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin
Sent: domenica 4 marzo 2007 14.56
To: [email-masked]; Adrian Farrel
Cc: [email-masked]; Don Fedyk; Igor Bryskin
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

=20

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The
request may not (and normally does not) contain an explicit path, but it
definitely contains all bandwidth parameters, because the tunnel was
requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always
knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management
and control plane should always hapen at one (ingress) node.

Igor

PS It would be interesting to hear from providers on this topic.

[email-masked] wrote:

"Adrian Farrel"=20
04/03/2007 00:35
Please respond to "Adrian Farrel"

To: "Igor Bryskin" , Dimitri=20
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: , "Don Fedyk"=20
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> 3. if a) is selected there is no other choice than an upstream
flowspec=20
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know

the=20
bandwidth to request? If it does then there is no need for a TSpec on
the=20
Resv as the reservation has already been made commensurate with the=20
FlowSpec=20
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec=20
=3D< tspec, nevertheless, after the tspec may "increase" and therefore=20
the flowspec may be adapted=20

If the ingress does *not* know and needs to see a TSpec from the egress,

then we need another Path exchange after the Resv in order to make the=20
actual reservations. In that case it really would be a mess and not
worth=20
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress

is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation
in
a corner case, whereas a technique making use of association object
would
prevent all this protocol massaging, keep full backward compatibility,
and
provide full flexibility

A=20

=20

 =20

________________________________

It's here! Your new message!
Get new email alerts
<http://us.rd.yahoo.com/evt=3D49938/*http:/tools.search.yahoo.com/toolbar=
/
features/mail/>  with the free Yahoo! Toolbar.

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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>From my experience I can quote =
everything
Igor said.&nbsp; GMPLS tunnel establishment is, AFAIK, always driven by =
the
NMS/OSS that (quoting Neil Harrison here) is the =
King.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So I think that in the real world =
the
Ingress node knows the upstream and downstream bandwidth of the GMPLS =
Tunnel is
going to set-up.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Moreover if I&#8217;ll use two
uni-directional LSPs in order to set-up an LSP with asymmetrical =
bandwidth
requirement I can force the path of the two LSPs to be the same? =
&nbsp;Do I
have to use the RRO of the first one as ERO for the second one? &nbsp;Or =
I
suppose to use a fully defined ERO for both the two LSP? &nbsp;In this =
case I
do suppose that the ERO has been calculated by the =
NMS?<o:p></o:p></span></font></p>

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

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Igor Bryskin<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> domenica 4 marzo =
2007 14.56<br>
<b><span style=3D'font-weight:bold'>To:</span></b>
[email-masked]; Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]; =
Don Fedyk;
Igor Bryskin<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Adrian and Dimitri,<br>
<br>
When a GMPLS tunnel is setup, it is setup for a reason.&nbsp; Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The =
request
may not (and normally does not) contain an explicit path, but it =
definitely
contains all bandwidth parameters, because the tunnel was requested, as =
I
siad,&nbsp; for a particular reason&nbsp; (application, <st1:place =
w:st=3D"on">SLA</st1:place>,
etc.). Also, how else you can ensure the fate sharing other than =
computing a
path on the ingress node taking in consideration the bandwidth =
requirements for
both directions?<br>
So, yes, I'd say that it is safe to assume that ingress node always =
knows about
bandiwidth in both directions.<br>
<br>
I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management =
and
control plane should always hapen at one (ingress) node.<br>
<br>
Igor<br>
<br>
PS It would be interesting to hear from providers on this topic.<br>
<br>
<b><i><span =
style=3D'font-weight:bold;font-style:italic'>Dimitri.Papadimitriou@alcate=
l-lucent.be</span></i></b>
wrote:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&quot;Adrian Farrel&quot; <br>
<[email-masked]>04/03/2007 00:35<br>
Please respond to &quot;Adrian Farrel&quot;<br>
<br>
To: &quot;Igor Bryskin&quot; <[email-masked]>, Dimitri <br>
PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>
cc: <[email-masked]>, &quot;Don Fedyk&quot; <br>
<[email-masked]>Subject: Re: I-D =
ACTION:draft-takacs-asym-bw-lsp-00.txt<br>
<br>
<br>
&gt; 3. if a) is selected there is no other choice than an upstream =
flowspec <br>
in<br>
&gt; the Path msg and a upstream tspec in the Resv message<br>
<br>
That *does* raise an interesting question. Namely, does the ingress know =
<br>
the <br>
bandwidth to request? If it does then there is no need for a TSpec on =
the <br>
Resv as the reservation has already been made commensurate with the <br>
FlowSpec <br>
on the Path.<br>
<br>
-&gt; if you do that you prevent the ingress-side to never adapt =
resource<br>
reservation to the traffic parameters of the egress (in fact, it =
would<br>
boil down to &quot;single-sided&quot; asymmetry forever)<br>
<br>
-&gt; hence, initially you must satisfy at least condition where =
flowspec <br>
=3D&lt; tspec, nevertheless, after the tspec may &quot;increase&quot; =
and
therefore <br>
the flowspec may be adapted <br>
<br>
If the ingress does *not* know and needs to see a TSpec from the egress, =
<br>
then we need another Path exchange after the Resv in order to make the =
<br>
actual reservations. In that case it really would be a mess and not =
worth <br>
trying to shoe-horn into a bidirectional LSP format.<br>
<br>
-&gt; this is what i said also to don, the case where initially the =
ingress <br>
is completely unaware of what it can reserve is impossible without =
major<br>
protocol modifications<br>
<br>
-&gt; my partial conclusion, is that a workable asym bw lsp doesn't =
elevate<br>
the need for the general case, and only provides apparent facilitation =
in<br>
a corner case, whereas a technique making use of association object =
would<br>
prevent all this protocol massaging, keep full backward compatibility, =
and<br>
provide full flexibility<br>
<br>
<br>
A <br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></span></font></p>

</[email-masked]></[email-masked]></[email-masked]></adrian@=
olddog.co.uk>

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

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

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

<hr size=3D1 width=3D"100%" align=3Dcenter>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>It's here! Your new message!<br>
Get <a
href=3D"http://us.rd.yahoo.com/evt=3D49938/*http:/tools.search.yahoo.com/=
toolbar/features/mail/">new
email alerts</a> with the free <a
href=3D"%0d%0ahttp:/us.rd.yahoo.com/evt=3D49938/*http:/tools.search.yahoo=
.com/toolbar/features/mail/">Yahoo!
Toolbar.</a><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C75EFD.DB337606--

Delivery-date: Sun, 04 Mar 2007 22:08:41 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Sun, 4 Mar 2007 23:06:05 +0100
From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Don Fedyk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

Please see inline.
Regards,
Attila=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, March 03, 2007 1:11 AM
> To: Don Fedyk; [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
>=20
> Cutting to the chase (I hope):
>=20
> >>-> btw, where this requirement come from ?
> > [DF] Specifically GMPLS control of Ethernet.
> >
> >
> > [dp] i think i should be more precise WHY this specific req ?
> > is that specific to Ethernet ?
>=20
> 1.a. Do we have a clear requirement for an asymmetrical=20
> bidirectional service?
>=20
> 1.b. Do we have a clear requirement for asymmetrical=20
> bidirectional LSPs?
> (Does 1.b follow from 1.a?)
>=20

It would be good to have operators reflect on these. My two cents are
that asymmetrical bidirectional services are apparently there. In
regards to LSPs carrying highly aggregated traffic in backbones
asymmetry might be of less importance, however LSPs getting further out
to the edges of the network may have really asymmetrical loads.

> > [dp] the issue is threefold
> >
> > a) you will see from the above that asym bi-dir LSP do not=20
> call for an=20
> > upstream tspec
>=20
> 2. If 1.b, what should we use on a Path message to indicate=20
> the bandwidth of the forward flow.
> 2.a. an 'upstream' TSpec
> 2.b. a FlowSpec
>=20

I agree with Don and Igor on this. Having a TSpec there and ending up
with "single-sided" LSP control would be not a problem in practice.

> > b) the gain compared to the cost of having a real bi-dir.
> > setup is so low that setting unidir LSP is simpler
> >
> > c) but there is an operational issue in linking two LSPs
> > (asymmetric) together that one could think of associating them, we=20
> > have a very efficient technique for this, that does not impact=20
> > intermediate nodes (ASSOCIATION object) and provides for full=20
> > flexibility (common or diverse spatial path for the upstream and=20
> > downstream flow)
>=20
> 3. Even if 1.b. we can consider:
> 3.a. A single signaling exchange for both directions 3.b. Two=20
> 'associated' signaling exchanges
>=20
> Personally, I think that the discussion is confused by=20
> talking about "bidirectional LSPs". The issue really seems to=20
> revolve around the signaling exchanges. The data plane=20
> presence can be established identically by 3.a. or 3.b.

Agree. The target of the ID was to have a discussion on the topic and
see if there is interest to add a new *option* (3.a) for asymmetric
bidirectional LSP establishment.=20

>=20
> Adrian=20
>=20
>=20
>=20
>=20

Delivery-date: Sun, 04 Mar 2007 18:11:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Agenda slots for CCAMP in Prague
Date: Sun, 4 Mar 2007 17:32:26 -0000
Organization: Old Dog Consulting

Hi,

In San Diego we ran hopelessly out of time and the room was almost unanimous 
in support of the idea of having a two shot CCAMP meeting in Prague. So that 
is what we have booked.

CCAMP will meet at 9am on Monday morning for 2.5 hours, and at 1pm on 
Tuesday afternoon for 2 hours.

We propose to split the work between working group drafts and milestones, 
and new material, dedicating one session to each although there may need to 
be some jiggling to avoid conflicts with other working groups.

Please send your requests for agenda slots to Deborah and me as soon as you 
like (or sooner!).

Thanks,
Deborah and Adrian 

Delivery-date: Sun, 04 Mar 2007 13:57:53 +0000
Date: Sun, 4 Mar 2007 05:55:30 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: [email-masked], Don Fedyk <[email-masked]>, Igor Bryskin <[email-masked]>

--0-2031406607-1173016530=:18484
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say, management plane requests a tunnel ingress node to setup a tunnel. The request may not (and normally does not) contain an explicit path, but it definitely contains all bandwidth parameters, because the tunnel was requested, as I siad,  for a particular reason  (application, SLA, etc.). Also, how else you can ensure the fate sharing other than computing a path on the ingress node taking in consideration the bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that actively deploy our GMPLS CP, that a communication between management and control plane should always hapen at one (ingress) node.

Igor

PS It would be interesting to hear from providers on this topic.

[email-masked] wrote: "Adrian Farrel" 
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     , "Don Fedyk" 
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> 3. if a) is selected there is no other choice than an upstream flowspec 
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know 
the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the 
FlowSpec 
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec 
=< tspec, nevertheless, after the tspec may "increase" and therefore 
the flowspec may be adapted 

If the ingress does *not* know and needs to see a TSpec from the egress, 
then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not worth 
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress 
is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation in
a corner case, whereas a technique making use of association object would
prevent all this protocol massaging, keep full backward compatibility, and
provide full flexibility

A 

---------------------------------
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
--0-2031406607-1173016530=:18484
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Adrian and Dimitri,<br><br>When a GMPLS tunnel is setup, it is setup for a reason.&nbsp; Let's say, management plane requests a tunnel ingress node to setup a tunnel. The request may not (and normally does not) contain an explicit path, but it definitely contains all bandwidth parameters, because the tunnel was requested, as I siad,&nbsp; for a particular reason&nbsp; (application, SLA, etc.). Also, how else you can ensure the fate sharing other than computing a path on the ingress node taking in consideration the bandwidth requirements for both directions?<br>So, yes, I'd say that it is safe to assume that ingress node always knows about bandiwidth in both directions.<br><br>I'd say even more. We have a strict requirement from our customers that actively deploy our GMPLS CP, that a communication between management and control plane should always hapen at one (ingress) node.<br><br>Igor<br><br>PS It would be interesting to hear from providers on this
 topic.<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;"> "Adrian Farrel" <[email-masked]><br>04/03/2007 00:35<br>Please respond to "Adrian Farrel"<br> <br>        To:     "Igor Bryskin" <[email-masked]>, Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     <[email-masked]>, "Don Fedyk" <[email-masked]><br>        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt<br><br><br>&gt; 3. if a) is selected there is no other choice than an upstream flowspec <br>in<br>&gt; the Path msg and a upstream tspec in the Resv message<br><br>That *does* raise an interesting question. Namely, does the ingress know <br>the <br>bandwidth to request? If it does then there is no need for a TSpec on the <br>Resv as the reservation has already been made commensurate with the <br>FlowSpec <br>on the Path.<br><br>-&gt; if you do
 that you prevent the ingress-side to never adapt resource<br>reservation to the traffic parameters of the egress (in fact, it would<br>boil down to "single-sided" asymmetry forever)<br><br>-&gt; hence, initially you must satisfy at least condition where flowspec <br>=&lt; tspec, nevertheless, after the tspec may "increase" and therefore <br>the flowspec may be adapted <br><br>If the ingress does *not* know and needs to see a TSpec from the egress, <br>then we need another Path exchange after the Resv in order to make the <br>actual reservations. In that case it really would be a mess and not worth <br>trying to shoe-horn into a bidirectional LSP format.<br><br>-&gt; this is what i said also to don, the case where initially the ingress <br>is completely unaware of what it can reserve is impossible without major<br>protocol modifications<br><br>-&gt; my partial conclusion, is that a workable asym bw lsp doesn't elevate<br>the need for the general case, and only provides
 apparent facilitation in<br>a corner case, whereas a technique making use of association object would<br>prevent all this protocol massaging, keep full backward compatibility, and<br>provide full flexibility<br><br><br>A <br><br><br><br><br></[email-masked]></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>It's here! Your new message!<br>Get
<a href="http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar/features/mail/"> new email alerts</a> with the free <a href="
http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar/features/mail/">Yahoo! Toolbar.</a>
--0-2031406607-1173016530=:18484--

Delivery-date: Sun, 04 Mar 2007 00:26:55 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], "Don Fedyk" <[email-masked]>, "Igor Bryskin" <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Sun, 4 Mar 2007 01:25:43 +0100

"Adrian Farrel" <[email-masked]>
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "Don Fedyk" <[email-masked]>
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> 3. if a) is selected there is no other choice than an upstream flowspec 
in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know 
the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the 
FlowSpec 
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec 
=< tspec, nevertheless, after the tspec may "increase" and therefore 
the flowspec may be adapted 

If the ingress does *not* know and needs to see a TSpec from the egress, 
then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not worth 
trying to shoe-horn into a bidirectional LSP format.

-> this is what i said also to don, the case where initially the ingress 
is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation in
a corner case, whereas a technique making use of association object would
prevent all this protocol massaging, keep full backward compatibility, and
provide full flexibility

A 

Delivery-date: Sat, 03 Mar 2007 23:44:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Don Fedyk" <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Sat, 3 Mar 2007 23:35:20 -0000
Organization: Old Dog Consulting

> 3. if a) is selected there is no other choice than an upstream flowspec in
> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the FlowSpec 
on the Path.

If the ingress does *not* know and needs to see a TSpec from the egress, 
then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not worth 
trying to shoe-horn into a bidirectional LSP format.

A 

Delivery-date: Sat, 03 Mar 2007 22:44:39 +0000
Date: Sat, 3 Mar 2007 14:43:54 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [email-masked]
Cc: Adrian Farrel <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>

--0-1671932405-1172961834=:61415
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, see in-line

[email-masked] wrote: igor

"If you need to re-route both LSPs, than recovery of a bi-directional LSP 
will be twice faster than recovery of two unidirectional LSPs."

that is clearly not the case. there is no sequential operation(s) in case 
of unidirectional LSPs, recovery time diff depends on the failure location 
and notif. propagation, at best they would be equal, otherwise you may 
have a slight difference (in favor of bi-dir LSP, 

IB>> True, if you don't need to preserve the fate -sharing, if you do you need to correleate the path selection for both LSPs.

but remember that the 
major reasoning behind bi-dir LSP has always been to facilitate 
timeslot/lambda selection).

IB>> am not sure that I got the rest of your message.

Igor
the real problem of asym LSPs. compared with sym bidir LSP where it is 
assumed that bw control is sym. (which is, at the end, the only reason for 
making this case sensible) the result here with asym bw LSP is that the 
control of both direction/data paths is concentrated at the head-end, in 
case the tail-end desires increasing the upstream bw.

-d.

Igor Bryskin 
03/03/2007 21:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Adrian Farrel , [email-masked], 
Don Fedyk 
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Dimitri,

Suppose a link carrying a bi-directional service in one direction fails 
and you need to perform e2e recovery. Suppose the service is mapped on 2 
unidirectional reciprocal LSPs. If you re-route just one LSP you will 
loose fate sharing. If you need to re-route both LSPs, than recovery of a 
bi-directional LSP will be twice faster than recovery of two 
unidirectional LSPs.
If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have 
extra flexibility , but you do have extra complexity.

Igor

[email-masked] wrote:
igor

1. treating the LSPs independently is an added value (in terms of 
flexibility), the sole reason for departing in case of bi-directional LSP 
was (look at the discussion on the list in 2000) due to a) keeping 
establishment of data path independent would have led to lambda LSPs with 
different wavelength in up and downstream direction over different paths 
b) improve setup and recovery time 

now, the conditions are totally different, reason why expliciting these is 

de-facto required in addition to the claim "i have a clear requirement 
for" that kind of service

2. at the end, the question is whether you need to have for the underlying 

data paths 

a) a signaled association on each intermediate node 

b) a signaled association at the end-points

c) no signaled association

3. if a) is selected there is no other choice than an upstream flowspec in 

the Path msg and a upstream tspec in the Resv message

the reason is ultra-clear, if you use an upstream tspec as this draft 
proposes it is equivalent to the dest. (source Rx) telling to the source 
(Dest Tx) what are traffic characteristics of the data flow that the 
"sender" (= Dest Tx) will generate hence just telling what the latter 
knows; hence resulting in requiring to send back over the Resv the adapted 

upstream tspec, and a third exchange in the form of an upstream flowspec 
(ok totally irrealistic and completely opposed to the simple and 
inexpensive method you are looking at)

note that any method creates for providing a) creates a real 
interoperability issue, reason why even a (correct) proposal along the 
lines of upstream flowspec in the Path msg and a upstream tspec in the 
Resv message did not progress (see e.g. draft-dube, that was partially 
going into the correct direction)

-d.

Igor Bryskin 
03/03/2007 14:26

To: Adrian Farrel , Don Fedyk 
, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked]
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi,

Provided that we have 1.a - there is a clear requirement for asymmetrical 
bidirectional services ��� I tend to agree with Don on this. 

If implementing a bidirectional service by an association of two 
reciprocal unidirectional LSPs is so great, then why do we need 
bi-directional LSPs in the first place? The answer is well recognized:
a) the setup is faster;
b) the CP state is smaller
c) the management is simpler (fate-sharing, recovery, alarm 
distribution,,,,)
d) solution for the opposite direction resource allocation contention 
problem
e) ���

That���s why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)���..

Igor 
Adrian Farrel wrote:
Cutting to the chase (I hope):

>>-> btw, where this requirement come from ?
> [DF] Specifically GMPLS control of Ethernet.
>
>
> [dp] i think i should be more precise WHY this specific req ?
> is that specific to Ethernet ?

1.a. Do we have a clear requirement for an asymmetrical bidirectional 
service?

1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?
(Does 1.b follow from 1.a?)

> [dp] the issue is threefold
>
> a) you will see from the above that asym bi-dir LSP do not
> call for an upstream tspec

2. If 1.b, what should we use on a Path message to indicate the bandwidth 
of 
the forward flow.
2.a. an 'upstream' TSpec
2.b. a FlowSpec

> b) the gain compared to the cost of having a real bi-dir.
> setup is so low that setting unidir LSP is simpler
>
> c) but there is an operational issue in linking two LSPs
> (asymmetric) together that one could think of associating
> them, we have a very efficient technique for this, that
> does not impact intermediate nodes (ASSOCIATION object)
> and provides for full flexibility (common or diverse spatial
> path for the upstream and downstream flow)

3. Even if 1.b. we can consider:
3.a. A single signaling exchange for both directions
3.b. Two 'associated' signaling exchanges

Personally, I think that the discussion is confused by talking about 
"bidirectional LSPs". The issue really seems to revolve around the 
signaling 
exchanges. The data plane presence can be established identically by 3.a. 
or 
3.b.

Adrian 

TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

 Need a quick answer? Get one in minutes from people who know. Ask your 
question on Yahoo! Answers.

---------------------------------
Don't get soaked.  Take a quick peak at the forecast 
 with theYahoo! Search weather shortcut.
--0-1671932405-1172961834=:61415
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, see in-line<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;"> igor<br><br>"If you need to re-route both LSPs, than recovery of a bi-directional LSP <br>will be twice faster than recovery of two unidirectional LSPs."<br><br>that is clearly not the case. there is no sequential operation(s) in case <br>of unidirectional LSPs, recovery time diff depends on the failure location <br>and notif. propagation, at best they would be equal, otherwise you may <br>have a slight difference (in favor of bi-dir LSP, <br><br>IB&gt;&gt; True, if you don't need to preserve the fate -sharing, if you do you need to correleate the path selection for both LSPs.<br><br>but remember that the <br>major reasoning behind bi-dir LSP has always been to facilitate <br>timeslot/lambda selection).<br><br>IB&gt;&gt; am not sure that I got the rest of your
 message.<br><br>Igor<br>the real problem of asym LSPs. compared with sym bidir LSP where it is <br>assumed that bw control is sym. (which is, at the end, the only reason for <br>making this case sensible) the result here with asym bw LSP is that the <br>control of both direction/data paths is concentrated at the head-end, in <br>case the tail-end desires increasing the upstream bw.<br><br>-d.<br><br><br><br><br><br><br>Igor Bryskin <[email-masked]><br>03/03/2007 21:03<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     Adrian Farrel <[email-masked]>, [email-masked], <br>Don Fedyk <[email-masked]><br>        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt<br><br><br>Dimitri,<br><br>Suppose a link carrying a bi-directional service in one direction fails <br>and you need to perform e2e recovery. Suppose the service is mapped on 2 <br>unidirectional reciprocal LSPs. If you re-route just one LSP you will <br>loose
 fate sharing. If you need to re-route both LSPs, than recovery of a <br>bi-directional LSP will be twice faster than recovery of two <br>unidirectional LSPs.<br>If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have <br>extra flexibility , but you do have extra complexity.<br><br>Igor<br><br>[email-masked] wrote:<br>igor<br><br><br>1. treating the LSPs independently is an added value (in terms of <br>flexibility), the sole reason for departing in case of bi-directional LSP <br>was (look at the discussion on the list in 2000) due to a) keeping <br>establishment of data path independent would have led to lambda LSPs with <br>different wavelength in up and downstream direction over different paths <br>b) improve setup and recovery time <br><br>now, the conditions are totally different, reason why expliciting these is <br><br>de-facto required in addition to the claim "i have a clear requirement <br>for" that kind of
 service<br><br><br>2. at the end, the question is whether you need to have for the underlying <br><br>data paths <br><br>a) a signaled association on each intermediate node <br><br>b) a signaled association at the end-points<br><br>c) no signaled association<br><br><br>3. if a) is selected there is no other choice than an upstream flowspec in <br><br>the Path msg and a upstream tspec in the Resv message<br><br>the reason is ultra-clear, if you use an upstream tspec as this draft <br>proposes it is equivalent to the dest. (source Rx) telling to the source <br>(Dest Tx) what are traffic characteristics of the data flow that the <br>"sender" (= Dest Tx) will generate hence just telling what the latter <br>knows; hence resulting in requiring to send back over the Resv the adapted <br><br>upstream tspec, and a third exchange in the form of an upstream flowspec <br>(ok totally irrealistic and completely opposed to the simple and <br>inexpensive method you are looking
 at)<br><br>note that any method creates for providing a) creates a real <br>interoperability issue, reason why even a (correct) proposal along the <br>lines of upstream flowspec in the Path msg and a upstream tspec in the <br>Resv message did not progress (see e.g. draft-dube, that was partially <br>going into the correct direction)<br><br>-d.<br><br><br><br><br><br>Igor Bryskin <br>03/03/2007 14:26<br><br>To: Adrian Farrel , Don Fedyk <br>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [email-masked]<br>Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi,<br><br>Provided that we have 1.a - there is a clear requirement for asymmetrical <br>bidirectional services ��� I tend to agree with Don on this. <br><br>If implementing a bidirectional service by an association of two <br>reciprocal unidirectional LSPs is so great, then why do we need <br>bi-directional LSPs in the first place? The answer is well recognized:<br>a) the setup is faster;<br>b) the
 CP state is smaller<br>c) the management is simpler (fate-sharing, recovery, alarm <br>distribution,,,,)<br>d) solution for the opposite direction resource allocation contention <br>problem<br>e) ���<br><br>That���s why we decided to introduce Upstream Label and support <br>bi-directional LSPs.<br>The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and <br>relatively inexpensive price for preserving the a),b),c)���..<br><br><br>Igor <br>Adrian Farrel wrote:<br>Cutting to the chase (I hope):<br><br>&gt;&gt;-&gt; btw, where this requirement come from ?<br>&gt; [DF] Specifically GMPLS control of Ethernet.<br>&gt;<br>&gt;<br>&gt; [dp] i think i should be more precise WHY this specific req ?<br>&gt; is that specific to Ethernet ?<br><br>1.a. Do we have a clear requirement for an asymmetrical bidirectional <br>service?<br><br>1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?<br>(Does 1.b follow from 1.a?)<br><br>&gt; [dp] the issue is
 threefold<br>&gt;<br>&gt; a) you will see from the above that asym bi-dir LSP do not<br>&gt; call for an upstream tspec<br><br>2. If 1.b, what should we use on a Path message to indicate the bandwidth <br>of <br>the forward flow.<br>2.a. an 'upstream' TSpec<br>2.b. a FlowSpec<br><br>&gt; b) the gain compared to the cost of having a real bi-dir.<br>&gt; setup is so low that setting unidir LSP is simpler<br>&gt;<br>&gt; c) but there is an operational issue in linking two LSPs<br>&gt; (asymmetric) together that one could think of associating<br>&gt; them, we have a very efficient technique for this, that<br>&gt; does not impact intermediate nodes (ASSOCIATION object)<br>&gt; and provides for full flexibility (common or diverse spatial<br>&gt; path for the upstream and downstream flow)<br><br>3. Even if 1.b. we can consider:<br>3.a. A single signaling exchange for both directions<br>3.b. Two 'associated' signaling exchanges<br><br>Personally, I think that the discussion is
 confused by talking about <br>"bidirectional LSPs". The issue really seems to revolve around the <br>signaling <br>exchanges. The data plane presence can be established identically by 3.a. <br>or <br>3.b.<br><br>Adrian <br><br><br><br><br>TV dinner still cooling?<br>Check out "Tonight's Picks" on Yahoo! TV.<br><br><br> Need a quick answer? Get one in minutes from people who know. Ask your <br>question on Yahoo! Answers.<br><br></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>
Don't get soaked.  Take a<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> quick peak at the forecast </a><br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search weather shortcut.</a>
--0-1671932405-1172961834=:61415--

Delivery-date: Sat, 03 Mar 2007 21:54:01 +0000
To: Igor Bryskin <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Sat, 3 Mar 2007 22:52:14 +0100

Delivery-date: Sat, 03 Mar 2007 20:05:28 +0000
Date: Sat, 3 Mar 2007 12:03:15 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [email-masked]
Cc: Adrian Farrel <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>

--0-478059516-1172952195=:32586
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,

Suppose a link carrying a bi-directional service in one direction fails and you need to perform e2e recovery. Suppose the service is mapped on 2 unidirectional reciprocal LSPs. If you re-route just one LSP you will loose fate sharing. If you need to re-route both LSPs, than recovery of a bi-directional LSP will be twice faster than recovery of two unidirectional LSPs.
If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have extra flexibility , but you do have extra complexity.

Igor

[email-masked] wrote: igor

1. treating the LSPs independently is an added value (in terms of 
flexibility), the sole reason for departing in case of bi-directional LSP 
was (look at the discussion on the list in 2000) due to a) keeping 
establishment of data path independent would have led to lambda LSPs with 
different wavelength in up and downstream direction over different paths 
b) improve setup and recovery time 

now, the conditions are totally different, reason why expliciting these is 
de-facto required in addition to the claim "i have a clear requirement 
for" that kind of service

2. at the end, the question is whether you need to have for the underlying 
data paths 

a) a signaled association on each intermediate node 

b) a signaled association at the end-points

c) no signaled association

3. if a) is selected there is no other choice than an upstream flowspec in 
the Path msg and a upstream tspec in the Resv message

the reason is ultra-clear, if you use an upstream tspec as this draft 
proposes it is equivalent to the dest. (source Rx) telling to the source 
(Dest Tx) what are traffic characteristics of the data flow that the 
"sender" (= Dest Tx) will generate hence just telling what the latter 
knows; hence resulting in requiring to send back over the Resv the adapted 
upstream tspec, and a third exchange in the form of an upstream flowspec 
(ok totally irrealistic and completely opposed to the simple and 
inexpensive method you are looking at)

note that any method creates for providing a) creates a real 
interoperability issue, reason why even a (correct) proposal along the 
lines of upstream flowspec in the Path msg and a upstream tspec in the 
Resv message did not progress (see e.g. draft-dube, that was partially 
going into the correct direction)

-d.

Igor Bryskin 
03/03/2007 14:26
 
        To:     Adrian Farrel , Don Fedyk 
, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi,

Provided that we have 1.a - there is a clear requirement for  asymmetrical 
bidirectional services &#1090;&#1040;&#1059; I tend to agree with Don on this. 
 
If implementing a bidirectional service by an association of two 
reciprocal unidirectional LSPs is so great, then why do we need 
bi-directional LSPs in the first place? The answer is well recognized:
a)      the setup is faster;
b)      the CP state is smaller
c)      the management is simpler (fate-sharing, recovery, alarm 
distribution,,,,)
d)      solution for the opposite direction resource allocation contention 
problem
e)      &#1090;&#1040;&#1078;
 
That&#1090;&#1040;&#1065;s why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)&#1090;&#1040;&#1078;..

Igor 
Adrian Farrel  wrote:
Cutting to the chase (I hope):

>>-> btw, where this requirement come from ?
> [DF] Specifically GMPLS control of Ethernet.
>
>
> [dp] i think i should be more precise WHY this specific req ?
> is that specific to Ethernet ?

1.a. Do we have a clear requirement for an asymmetrical bidirectional 
service?

1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?
(Does 1.b follow from 1.a?)

> [dp] the issue is threefold
>
> a) you will see from the above that asym bi-dir LSP do not
> call for an upstream tspec

2. If 1.b, what should we use on a Path message to indicate the bandwidth 
of 
the forward flow.
2.a. an 'upstream' TSpec
2.b. a FlowSpec

> b) the gain compared to the cost of having a real bi-dir.
> setup is so low that setting unidir LSP is simpler
>
> c) but there is an operational issue in linking two LSPs
> (asymmetric) together that one could think of associating
> them, we have a very efficient technique for this, that
> does not impact intermediate nodes (ASSOCIATION object)
> and provides for full flexibility (common or diverse spatial
> path for the upstream and downstream flow)

3. Even if 1.b. we can consider:
3.a. A single signaling exchange for both directions
3.b. Two 'associated' signaling exchanges

Personally, I think that the discussion is confused by talking about 
"bidirectional LSPs". The issue really seems to revolve around the 
signaling 
exchanges. The data plane presence can be established identically by 3.a. 
or 
3.b.

Adrian 

 TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.
--0-478059516-1172952195=:32586
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri,<br><br>Suppose a link carrying a bi-directional service in one direction fails and you need to perform e2e recovery. Suppose the service is mapped on 2 unidirectional reciprocal LSPs. If you re-route just one LSP you will loose fate sharing. If you need to re-route both LSPs, than recovery of a bi-directional LSP will be twice faster than recovery of two unidirectional LSPs.<br>If fate sharing is a "MUST", I say with reciprocal LSPs&nbsp; you don't have extra flexibility , but you do have extra complexity.<br><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;"> igor<br><br><br>1. treating the LSPs independently is an added value (in terms of <br>flexibility), the sole reason for departing in case of bi-directional LSP <br>was (look at the discussion on the list in 2000) due to a) keeping <br>establishment of data path independent
 would have led to lambda LSPs with <br>different wavelength in up and downstream direction over different paths <br>b) improve setup and recovery time <br><br>now, the conditions are totally different, reason why expliciting these is <br>de-facto required in addition to the claim "i have a clear requirement <br>for" that kind of service<br><br><br>2. at the end, the question is whether you need to have for the underlying <br>data paths <br><br>a) a signaled association on each intermediate node <br><br>b) a signaled association at the end-points<br><br>c) no signaled association<br><br><br>3. if a) is selected there is no other choice than an upstream flowspec in <br>the Path msg and a upstream tspec in the Resv message<br><br>the reason is ultra-clear, if you use an upstream tspec as this draft <br>proposes it is equivalent to the dest. (source Rx) telling to the source <br>(Dest Tx) what are traffic characteristics of the data flow that the <br>"sender" (= Dest Tx) will
 generate hence just telling what the latter <br>knows; hence resulting in requiring to send back over the Resv the adapted <br>upstream tspec, and a third exchange in the form of an upstream flowspec <br>(ok totally irrealistic and completely opposed to the simple and <br>inexpensive method you are looking at)<br><br>note that any method creates for providing a) creates a real <br>interoperability issue, reason why even a (correct) proposal along the <br>lines of upstream flowspec in the Path msg and a upstream tspec in the <br>Resv message did not progress (see e.g. draft-dube, that was partially <br>going into the correct direction)<br><br>-d.<br><br><br><br><br><br>Igor Bryskin <[email-masked]><br>03/03/2007 14:26<br> <br>        To:     Adrian Farrel <[email-masked]>, Don Fedyk <br><[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [email-masked]<br>        Subject:        Re: I-D
 ACTION:draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi,<br><br>Provided that we have 1.a - there is a clear requirement for  asymmetrical <br>bidirectional services &#1090;&#1040;&#1059; I tend to agree with Don on this. <br> <br>If implementing a bidirectional service by an association of two <br>reciprocal unidirectional LSPs is so great, then why do we need <br>bi-directional LSPs in the first place? The answer is well recognized:<br>a)      the setup is faster;<br>b)      the CP state is smaller<br>c)      the management is simpler (fate-sharing, recovery, alarm <br>distribution,,,,)<br>d)      solution for the opposite direction resource allocation contention <br>problem<br>e)      &#1090;&#1040;&#1078;<br> <br>That&#1090;&#1040;&#1065;s why we decided to introduce Upstream Label and support <br>bi-directional LSPs.<br>The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and <br>relatively inexpensive price for preserving the
 a),b),c)&#1090;&#1040;&#1078;..<br> <br> <br>Igor <br>Adrian Farrel <[email-masked]> wrote:<br>Cutting to the chase (I hope):<br><br>&gt;&gt;-&gt; btw, where this requirement come from ?<br>&gt; [DF] Specifically GMPLS control of Ethernet.<br>&gt;<br>&gt;<br>&gt; [dp] i think i should be more precise WHY this specific req ?<br>&gt; is that specific to Ethernet ?<br><br>1.a. Do we have a clear requirement for an asymmetrical bidirectional <br>service?<br><br>1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?<br>(Does 1.b follow from 1.a?)<br><br>&gt; [dp] the issue is threefold<br>&gt;<br>&gt; a) you will see from the above that asym bi-dir LSP do not<br>&gt; call for an upstream tspec<br><br>2. If 1.b, what should we use on a Path message to indicate the bandwidth <br>of <br>the forward flow.<br>2.a. an 'upstream' TSpec<br>2.b. a FlowSpec<br><br>&gt; b) the gain compared to the cost of having a real bi-dir.<br>&gt; setup is so low that setting
 unidir LSP is simpler<br>&gt;<br>&gt; c) but there is an operational issue in linking two LSPs<br>&gt; (asymmetric) together that one could think of associating<br>&gt; them, we have a very efficient technique for this, that<br>&gt; does not impact intermediate nodes (ASSOCIATION object)<br>&gt; and provides for full flexibility (common or diverse spatial<br>&gt; path for the upstream and downstream flow)<br><br>3. Even if 1.b. we can consider:<br>3.a. A single signaling exchange for both directions<br>3.b. Two 'associated' signaling exchanges<br><br>Personally, I think that the discussion is confused by talking about <br>"bidirectional LSPs". The issue really seems to revolve around the <br>signaling <br>exchanges. The data plane presence can be established identically by 3.a. <br>or <br>3.b.<br><br>Adrian <br><br><br><br><br> TV dinner still cooling?<br>Check out "Tonight's Picks" on Yahoo!
 TV.<br><br></[email-masked]></[email-masked]></[email-masked]></[email-masked]></blockquote><br><p>&#32;

<hr size=1>Need a quick answer? Get one in minutes from people who know. Ask your question on
 <a href="http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx">Yahoo! Answers</a>.
--0-478059516-1172952195=:32586--

Delivery-date: Sat, 03 Mar 2007 16:56:14 +0000
To: Igor Bryskin <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], Don Fedyk <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Sat, 3 Mar 2007 17:53:25 +0100

Delivery-date: Sat, 03 Mar 2007 13:29:03 +0000
Date: Sat, 3 Mar 2007 05:26:53 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: Adrian Farrel <[email-masked]>, Don Fedyk <[email-masked]>, [email-masked]
Cc: [email-masked]

--0-642856478-1172928413=:1739
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hi,
 
 Provided that we have 1.a - there is a clear requirement for  asymmetrical bidirectional services � I tend to agree with Don on this. 
   
  If implementing a bidirectional service by an association of two reciprocal unidirectional LSPs is so great, then why do we need bi-directional LSPs in the first place? The answer is well recognized:
  a)      the setup is faster;
  b)      the CP state is smaller
  c)      the management is simpler (fate-sharing, recovery, alarm distribution,,,,)
  d)      solution for the opposite direction resource allocation contention problem
  e)      �
   
  That�s why we decided to introduce Upstream Label and support bi-directional LSPs.
  The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and relatively inexpensive price for preserving the a),b),c)�..

  Igor 
  Adrian Farrel <[email-masked]> wrote: Cutting to the chase (I hope):

>>-> btw, where this requirement come from ?
> [DF] Specifically GMPLS control of Ethernet.
>
>
> [dp] i think i should be more precise WHY this specific req ?
> is that specific to Ethernet ?

1.a. Do we have a clear requirement for an asymmetrical bidirectional 
service?

1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?
(Does 1.b follow from 1.a?)

> [dp] the issue is threefold
>
> a) you will see from the above that asym bi-dir LSP do not
> call for an upstream tspec

2. If 1.b, what should we use on a Path message to indicate the bandwidth of 
the forward flow.
2.a. an 'upstream' TSpec
2.b. a FlowSpec

> b) the gain compared to the cost of having a real bi-dir.
> setup is so low that setting unidir LSP is simpler
>
> c) but there is an operational issue in linking two LSPs
> (asymmetric) together that one could think of associating
> them, we have a very efficient technique for this, that
> does not impact intermediate nodes (ASSOCIATION object)
> and provides for full flexibility (common or diverse spatial
> path for the upstream and downstream flow)

3. Even if 1.b. we can consider:
3.a. A single signaling exchange for both directions
3.b. Two 'associated' signaling exchanges

Personally, I think that the discussion is confused by talking about 
"bidirectional LSPs". The issue really seems to revolve around the signaling 
exchanges. The data plane presence can be established identically by 3.a. or 
3.b.

Adrian 

---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
--0-642856478-1172928413=:1739
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  <div class="MsoNormal">Hi,<br> <br> Provided that we have 1.a - there is a clear requirement for<span style="">&nbsp; </span>asymmetrical bidirectional services � I tend to agree with Don on this. </div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">If implementing a bidirectional service by an association of two reciprocal unidirectional LSPs is so great, then why do we need bi-directional LSPs in the first place? The answer is well recognized:</div>  <div class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">a)<span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!--[endif]-->the setup is faster;</div>  <div class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if
 !supportLists]--><span style="">b)<span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!--[endif]-->the CP state is smaller</div>  <div class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">c)<span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!--[endif]-->the management is simpler (fate-sharing, recovery, alarm distribution,,,,)</div>  <div class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">d)<span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant:
 normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!--[endif]-->solution for the opposite direction resource allocation contention problem</div>  <div class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">e)<span style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><!--[endif]-->�</div>  <div class="MsoNormal" style="margin-left: 0.25in;"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">That�s why we decided to introduce Upstream Label and support bi-directional LSPs.</div>  <div class="MsoNormal">The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and relatively inexpensive price for preserving the
 a),b),c)�..</div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal"><o:p>&nbsp;</o:p></div>  <div class="MsoNormal">Igor </div>  <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;"> Cutting to the chase (I hope):<br><br>&gt;&gt;-&gt; btw, where this requirement come from ?<br>&gt; [DF] Specifically GMPLS control of Ethernet.<br>&gt;<br>&gt;<br>&gt; [dp] i think i should be more precise WHY this specific req ?<br>&gt; is that specific to Ethernet ?<br><br>1.a. Do we have a clear requirement for an asymmetrical bidirectional <br>service?<br><br>1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?<br>(Does 1.b follow from 1.a?)<br><br>&gt; [dp] the issue is threefold<br>&gt;<br>&gt; a) you will see from the above that asym bi-dir LSP do not<br>&gt; call for an upstream tspec<br><br>2. If 1.b, what should we use on
 a Path message to indicate the bandwidth of <br>the forward flow.<br>2.a. an 'upstream' TSpec<br>2.b. a FlowSpec<br><br>&gt; b) the gain compared to the cost of having a real bi-dir.<br>&gt; setup is so low that setting unidir LSP is simpler<br>&gt;<br>&gt; c) but there is an operational issue in linking two LSPs<br>&gt; (asymmetric) together that one could think of associating<br>&gt; them, we have a very efficient technique for this, that<br>&gt; does not impact intermediate nodes (ASSOCIATION object)<br>&gt; and provides for full flexibility (common or diverse spatial<br>&gt; path for the upstream and downstream flow)<br><br>3. Even if 1.b. we can consider:<br>3.a. A single signaling exchange for both directions<br>3.b. Two 'associated' signaling exchanges<br><br>Personally, I think that the discussion is confused by talking about <br>"bidirectional LSPs". The issue really seems to revolve around the signaling <br>exchanges. The data plane presence can be established
 identically by 3.a. or <br>3.b.<br><br>Adrian <br><br><br><br></blockquote><br><p>&#32;

<hr size=1>TV dinner still cooling?<br><a href="http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/">Check out "Tonight's Picks"</a> on Yahoo! TV.
--0-642856478-1172928413=:1739--

Delivery-date: Sat, 03 Mar 2007 00:12:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Sat, 3 Mar 2007 00:10:57 -0000
Organization: Old Dog Consulting

Cutting to the chase (I hope):

>>-> btw, where this requirement come from ?
> [DF] Specifically GMPLS control of Ethernet.
>
>
> [dp] i think i should be more precise WHY this specific req ?
> is that specific to Ethernet ?

1.a. Do we have a clear requirement for an asymmetrical bidirectional 
service?

1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?
(Does 1.b follow from 1.a?)

> [dp] the issue is threefold
>
> a) you will see from the above that asym bi-dir LSP do not
> call for an upstream tspec

2. If 1.b, what should we use on a Path message to indicate the bandwidth of 
the forward flow.
2.a. an 'upstream' TSpec
2.b. a FlowSpec

> b) the gain compared to the cost of having a real bi-dir.
> setup is so low that setting unidir LSP is simpler
>
> c) but there is an operational issue in linking two LSPs
> (asymmetric) together that one could think of associating
> them, we have a very efficient technique for this, that
> does not impact intermediate nodes (ASSOCIATION object)
> and provides for full flexibility (common or diverse spatial
> path for the upstream and downstream flow)

3. Even if 1.b. we can consider:
3.a. A single signaling exchange for both directions
3.b. Two 'associated' signaling exchanges

Personally, I think that the discussion is confused by talking about 
"bidirectional LSPs". The issue really seems to revolve around the signaling 
exchanges. The data plane presence can be established identically by 3.a. or 
3.b.

Adrian 

Delivery-date: Fri, 02 Mar 2007 23:57:51 +0000
To: "Don Fedyk" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Sat, 3 Mar 2007 00:56:09 +0100

hi don

see inline

>"Don Fedyk" <[email-masked]> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[email-masked]>
>
>Hi Dimitri 
>
>Please see inline:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> 
>> let's go back to basic
>> 
>> per RFC 3471
>> 
>> "4. Bidirectional LSPs
>> 
>>    This section defines direct support of bidirectional
>>    LSPs.  Support is defined for LSPs that have the same
>>    traffic engineering requirements including fate
>>    sharing, protection and restoration, LSRs, and resource
>>    requirements (e.g., latency and jitter) in each
>>    direction."
>> 
>> what does it mean in practice that Path msg can carry a
>> TSPEC and the Resv a FLOWSPEC, and still allow for
>> establishment of two data paths (upstream & downstream)
>> 
>> [...]
>> 
>>  "With bidirectional LSPs both the downstream and upstream
>>  data paths, i.e., from initiator to terminator and
>>  terminator to initiator, they are established using a
>>  single set of signaling messages."
>> 
>> in brief, a single msg exchange for two data paths
>> (upstream & downstream)
>> 
>> but if you change the initial condition and still be
>> somehow respectful of the RSVP operation
>> 
>> the path msg shall carry an (upstream) FLOWSPEC and
>> (downstream) TSPEC and not a downstream TSPEC and a
>> (default) TSPEC, but now you got the real issue of
>> carrying a FLOWSPEC in a Path msg ??? 
>
>Well we have with GMPLS that a Path message with a single
>TSPEC for both upstream and downstream and in a Resv message
>a single FLOWSPEC for both upstream and downstream is
>available today. 
>
>-> well, the problem is that in bi-dir. symmetric LSPs,
>there is no "upstream flowspec" because redundant with the
>tspec values, hence, symmetry allows for simplification
>
>This draft proposes that that single TSPEC can be split into
>an upstream and downstream component. 
>
>-> that is impossible, there is no upstream and dowstream
>component to the tspec (the source is not the Tx for both
>components)
[DF]I don't see this a big issue in the case of GMPLS. 

[dp] well see below

>The FLOWSPEC is proabably redundant in this case.
>
>-> simple, the problem is that we're going to have an object
>that does not make any sense in Path msg (or any other
>"name" we will find for it)
[DF] my understanding is it is already there. It seems odd
to me to follow the reasoning that says it is OK for
symmetric BW to have the object but deny it for asymmetric
BW. 

[dp] step 1: unidir LSP between A-B: Tx ----> Rx 

tspec A->B (Path), flowspec B->A (Resv)

[dp] step 2: sym bidir LSP between A-B: Tx ----> Rx 
                                        Rx <---- Tx

but tspec A->B (Path)    == flowspec A->B (Resv)
and flowspec B->A (Resv) == tspec B->A (Path)

in brief, tspec A->B (Path) acts as is floswpec A->B (Resv)
was sent from A to B (for upstream data path)

[dp] step 3: asymmetric bidir LSP A-B:

w/  tspec A->B (Path)    =/= flowspec A->B (Resv)
and flowspec B->A (Resv) =/= tspec B->A (Path)

therefore, you need

tspec A->B & flowspec A->B (in Path) 

and

flowspec B->A & tspec B->A (in Resv)

>> hence, better forget about this idea and look at a simple
>> extensions consisting in linking two uni-directional LSP
>> with an association oject
>> 
>
>The requirement is one Path message for a bidirectional path
>with asymmetric bandwidth. In GMPLS we already have one Path
>message for a path with symmetric bandwidth. The requirement
>is to signal this all from the upstream end. 
>
>-> btw, where this requirement come from ? 
[DF] Specifically GMPLS control of Ethernet. 

[dp] i think i should be more precise WHY this specific req ?
is that specific to Ethernet ? or to PBB-TE probably ;-)

>The question is: Do we make simple extensions to GMPLS
>signaling or go to uni-directional LSPs and define the
>procedures to associate bi-directional labels that have been
>set up with two associated sessions? 
>
>-> the question is more basic, there is no reason, to
>contortionate the protocol to find a solution here (full
>flexibility without any backward compatibility issue)
>
[DF] RFC 3945 Section 7.10.  Bi-directional LSP: makes all the
arguments for a single LSP setup. Besides RSVP-TE is
extensible as well so the additional object will not show up
unless it is GMPLS and unless it involves a technology that
supports asymmetrical bandwidth. I don't see the issue. 

[dp] the issue is threefold 

a) you will see from the above that asym bi-dir LSP do not
call for an upstream tspec

b) the gain compared to the cost of having a real bi-dir.
setup is so low that setting unidir LSP is simpler

c) but there is an operational issue in linking two LSPs
(asymmetric) together that one could think of associating
them, we have a very efficient technique for this, that
does not impact intermediate nodes (ASSOCIATION object)
and provides for full flexibility (common or diverse spatial
path for the upstream and downstream flow) 

thanks,
- d.

Regards,
Don 

>thanks, -d.
>
>While I have not added up the changes to compare the
>differences it sure seems like processing an upstream and
>downs stream TSPEC in a path message is a smaller delta than
>defining all the procedures for associated LSPs. 
>
>Regards, Don <snip>
>
>
>

Delivery-date: Fri, 02 Mar 2007 21:24:42 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Fri, 2 Mar 2007 16:21:35 -0500
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Dimitri

See inline [DF]

>hi don
>
>"Don Fedyk" <[email-masked]> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[email-masked]>
>
>Hi Dimitri=20
>
>Please see inline:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>>=20
>> let's go back to basic
>>=20
>> per RFC 3471
>>=20
>> "4. Bidirectional LSPs
>>=20
>>    This section defines direct support of bidirectional
>>    LSPs.  Support is defined for LSPs that have the same
>>    traffic engineering requirements including fate
>>    sharing, protection and restoration, LSRs, and resource
>>    requirements (e.g., latency and jitter) in each
>>    direction."
>>=20
>> what does it mean in practice that Path msg can carry a
>> TSPEC and the Resv a FLOWSPEC, and still allow for
>> establishment of two data paths (upstream & downstream)
>>=20
>> [...]
>>=20
>>  "With bidirectional LSPs both the downstream and upstream
>>  data paths, i.e., from initiator to terminator and
>>  terminator to initiator, they are established using a
>>  single set of signaling messages."
>>=20
>> in brief, a single msg exchange for two data paths
>> (upstream & downstream)
>>=20
>> but if you change the initial condition and still be
>> somehow respectful of the RSVP operation
>>=20
>> the path msg shall carry an (upstream) FLOWSPEC and
>> (downstream) TSPEC and not a downstream TSPEC and a
>> (default) TSPEC, but now you got the real issue of
>> carrying a FLOWSPEC in a Path msg ???=20
>
>Well we have with GMPLS that a Path message with a single
>TSPEC for both upstream and downstream and in a Resv message
>a single FLOWSPEC for both upstream and downstream is
>available today.=20
>
>-> well, the problem is that in bi-dir. symmetric LSPs,
>there is no "upstream flowspec" because redundant with the
>tspec values, hence, symmetry allows for simplification
>
>This draft proposes that that single TSPEC can be split into
>an upstream and downstream component.=20
>
>-> that is impossible, there is no upstream and dowstream
>component to the tspec (the source is not the Tx for both
>components)
[DF]I don't see this a big issue in the case of GMPLS.=20
>
>The FLOWSPEC is proabably redundant in this case.
>
>-> simple, the problem is that we're going to have an object
>that does not make any sense in Path msg (or any other
>"name" we will find for it)
[DF] my understanding is it is already there. It seems odd
to me to follow the reasoning that says it is OK for
symmetric BW to have the object but deny it for asymmetric
BW.=20
>=20
>> hence, better forget about this idea and look at a simple
>> extensions consisting in linking two uni-directional LSP
>> with an association oject
>>=20
>
>The requirement is one Path message for a bidirectional path
>with asymmetric bandwidth. In GMPLS we already have one Path
>message for a path with symmetric bandwidth. The requirement
>is to signal this all from the upstream end.=20
>
>-> btw, where this requirement come from ?=20
[DF] Specifically GMPLS control of Ethernet. =20

>
>The question is: Do we make simple extensions to GMPLS
>signaling or go to uni-directional LSPs and define the
>procedures to associate bi-directional labels that have been
>set up with two associated sessions?=20
>
>-> the question is more basic, there is no reason, to
>contortionate the protocol to find a solution here (full
>flexibility without any backward compatibility issue)
>
[DF] RFC 3945 Section 7.10.  Bi-directional LSP: makes all the
arguments for a single LSP setup. Besides RSVP-TE is
extensible as well so the additional object will not show up
unless it is GMPLS and unless it involves a technology that
supports asymmetrical bandwidth. I don't see the issue. =20

Regards,
Don=20

>thanks, -d.
>
>While I have not added up the changes to compare the
>differences it sure seems like processing an upstream and
>downs stream TSPEC in a path message is a smaller delta than
>defining all the procedures for associated LSPs.=20
>
>Regards, Don <snip>
>
>
>

Delivery-date: Fri, 02 Mar 2007 17:07:07 +0000
To: "Don Fedyk" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Fri, 2 Mar 2007 18:06:23 +0100

hi don

"Don Fedyk" <[email-masked]>
02/03/2007 17:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
<[email-masked]>
        cc: 
        Subject:        RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi Dimitri 

Please see inline:
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 
> let's go back to basic
> 
> per RFC 3471
> 
> "4. Bidirectional LSPs
> 
>    This section defines direct support of bidirectional LSPs.  Support
>    is defined for LSPs that have the same traffic engineering
>    requirements including fate sharing, protection and restoration,
>    LSRs, and resource requirements (e.g., latency and jitter) in each
>    direction."
> 
> what does it mean in practice that Path msg can carry a TSPEC and the 
> Resv a FLOWSPEC, and still allow for establishment of two data paths
> (upstream & downstream)
> 
> [...]
> 
>  "With bidirectional LSPs both the downstream and upstream data paths,
>    i.e., from initiator to terminator and terminator to 
> initiator, they
>    are established using a single set of signaling messages."
> 
> in brief, a single msg exchange for two data paths (upstream 
> & downstream)
> 
> but if you change the initial condition and still be somehow 
> respectful
> of the RSVP operation
> 
> the path msg shall carry an (upstream) FLOWSPEC and (downstream) TSPEC
> and not a downstream TSPEC and a (default) TSPEC, but now you got the 
> real issue of carrying a FLOWSPEC in a Path msg ??? 

Well we have with GMPLS that a Path message with a single TSPEC for both
upstream and downstream and in a Resv message a single FLOWSPEC for both
upstream and downstream is available today. 

-> well, the problem is that in bi-dir. symmetric LSPs, there is no 
"upstream flowspec" because redundant with the tspec values, hence,
symmetry allows for simplification

This draft proposes that that single TSPEC can be split into an upstream
and downstream component. 

-> that is impossible, there is no upstream and dowstream component to
   the tspec (the source is not the Tx for both components)

The FLOWSPEC is proabably redundant in this case.

-> simple, the problem is that we're going to have an object that does
   not make any sense in Path msg (or any other "name" we will find for
   it)
 
> hence, better forget about this idea and look at a simple extensions
> consisting in linking two uni-directional LSP with an association 
> oject
> 

The requirement is one Path message for a bidirectional path with
asymmetric bandwidth. In GMPLS we already have one Path message for a
path with symmetric bandwidth. The requirement is to signal this all
from the upstream end. 

-> btw, where this requirement come from ? 

The question is: Do we make simple extensions to
GMPLS signaling or go to uni-directional LSPs and define the procedures
to associate bi-directional labels that have been set up with two
associated sessions? 

-> the question is more basic, there is no reason, to contortionate 
the protocol to find a solution here (full flexibility without any
backward compatibility issue)

thanks,
-d.

While I have not added up the changes to compare the differences it sure
seems like processing an upstream and downs stream TSPEC in a path
message is a smaller delta than defining all the procedures for
associated LSPs. 

Regards,
Don 
<snip>

Delivery-date: Fri, 02 Mar 2007 16:47:29 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Fri, 2 Mar 2007 11:44:42 -0500
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Dimitri=20

Please see inline:
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
>=20
> let's go back to basic
>=20
> per RFC 3471
>=20
> "4. Bidirectional LSPs
>=20
>    This section defines direct support of bidirectional LSPs.  Support
>    is defined for LSPs that have the same traffic engineering
>    requirements including fate sharing, protection and restoration,
>    LSRs, and resource requirements (e.g., latency and jitter) in each
>    direction."
>=20
> what does it mean in practice that Path msg can carry a TSPEC and the=20
> Resv a FLOWSPEC, and still allow for establishment of two data paths
> (upstream & downstream)
>=20
> [...]
>=20
>  "With bidirectional LSPs both the downstream and upstream data paths,
>    i.e., from initiator to terminator and terminator to=20
> initiator, they
>    are established using a single set of signaling messages."
>=20
> in brief, a single msg exchange for two data paths (upstream=20
> & downstream)
>=20
> but if you change the initial condition and still be somehow=20
> respectful
> of the RSVP operation
>=20
> the path msg shall carry an (upstream) FLOWSPEC and (downstream) TSPEC
> and not a downstream TSPEC and a (default) TSPEC, but now you got the=20
> real issue of carrying a FLOWSPEC in a Path msg ???=20
Well we have with GMPLS that a Path message with a single TSPEC for both
upstream and downstream and in a Resv message a single FLOWSPEC for both
upstream and downstream is available today.=20
This draft proposes that that single TSPEC can be split into an upstream
and downstream component.  The FLOWSPEC is proabably redundant in this
case.

>=20
> hence, better forget about this idea and look at a simple extensions
> consisting in linking two uni-directional LSP with an association=20
> oject
>=20
The requirement is one Path message for a bidirectional path with
asymmetric bandwidth. In GMPLS we already have one Path message for a
path with symmetric bandwidth. The requirement is to signal this all
from the upstream end.  The question is: Do we make simple extensions to
GMPLS signaling or go to uni-directional LSPs and define the procedures
to associate bi-directional labels that have been set up with two
associated sessions? =20

While I have not added up the changes to compare the differences it sure
seems like processing an upstream and downs stream TSPEC in a path
message is a smaller delta than defining all the procedures for
associated LSPs.=20

Regards,
Don=20
<snip>

Delivery-date: Fri, 02 Mar 2007 07:42:24 +0000
To: [email-masked]
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
From: [email-masked]
Date: Fri, 2 Mar 2007 08:40:29 +0100

let's go back to basic

per RFC 3471

"4. Bidirectional LSPs

   This section defines direct support of bidirectional LSPs.  Support
   is defined for LSPs that have the same traffic engineering
   requirements including fate sharing, protection and restoration,
   LSRs, and resource requirements (e.g., latency and jitter) in each
   direction."

what does it mean in practice that Path msg can carry a TSPEC and the 
Resv a FLOWSPEC, and still allow for establishment of two data paths
(upstream & downstream)

[...]

 "With bidirectional LSPs both the downstream and upstream data paths,
   i.e., from initiator to terminator and terminator to initiator, they
   are established using a single set of signaling messages."

in brief, a single msg exchange for two data paths (upstream & downstream)

but if you change the initial condition and still be somehow respectful
of the RSVP operation

the path msg shall carry an (upstream) FLOWSPEC and (downstream) TSPEC
and not a downstream TSPEC and a (default) TSPEC, but now you got the 
real issue of carrying a FLOWSPEC in a Path msg ??? 

hence, better forget about this idea and look at a simple extensions
consisting in linking two uni-directional LSP with an association 
oject

ps: the document includes in many places "marketing-like" statements 
completely - examples

" The limitation of symmetrical resource requirements may pose 
   difficulties for operators to efficiently support the services 
   foreseen for next generation networks."

pls give us a break with all the hype and hubub about "services 
foreseen for next generation networks" 

"Means must be provided by higher 
   layer entities, e.g., the network management system (NMS), to 
   correlate the LSPs not just from RSVP-TE but also from an OAM point 
   of view. "

which OAM ??? never heard someone complaining when using MPLS-BFD
where is the proof point ?

"Additionally, translation functionality may be required to 
   provide operators with a service oriented bidirectional abstraction 
   hiding the complex control plane operation."

could you speak with an IETF language please, this sentence just 
mean nothing

thanks,
-d.

[email-masked]
27/02/2007 21:50
Please respond to internet-drafts
 
        To:     [email-masked]
        cc: 
        Subject:        I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

                 Title                           : GMPLS RSVP-TE extension 
in support of bidirectional LSPs with 
                 Author(s)               : A. Takacs, et al.
                 Filename                : draft-takacs-asym-bw-lsp-00.txt
                 Pages                           : 8
                 Date                            : 2007-2-27
 
   GMPLS provides general connection control functionality supporting 
   different network technologies. This memo specifies a further 
   generalization to support bidirectional LSPs with asymmetric 
   requirements. The extension improves the flexibility of bidirectional 
   LSP establishment and at the same time simplifies the control and 
   management of asymmetric services. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-takacs-asym-bw-lsp-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-takacs-asym-bw-lsp-00.txt".

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

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

Send a message to:
                 [email-masked].
In the body type:
                 "FILE /internet-drafts/draft-takacs-asym-bw-lsp-00.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-takacs-asym-bw-lsp-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Thu, 01 Mar 2007 23:50:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt 
Date: Thu, 01 Mar 2007 18:50:02 -0500

--NextPart

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

	Title		: Label Switched Path Stitching with Generalized 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
	
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.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-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-lsp-stitching-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-lsp-stitching-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lsp-stitching-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: Thu, 01 Mar 2007 23:43:48 +0000
Content-class: urn:content-classes:message
Subject: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
Date: Thu, 1 Mar 2007 18:41:34 -0500
From: "Zafar Ali \(zali\)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>, "Jean Philippe Vasseur \(jvasseur\)" <[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75C5B.2661B6D1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Adrian, Deborah, Dimitri, and campers- =20
=20
As we mentioned at the last IETF meeting,
http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm, we have
addressed all outstanding comments, except the following comment from
Dimitri, related to this ID. Should you have any further comment, please
share.=20
=20
The only remaining comment that is not closed is "should this ID be
informational or standard track". IMO the ID defines a new error-subcode
and some specific behavior, and should be standard track. Can you please
comment on this.=20
=20
The ID has been stable for quite some time and following the closure of
the above, we would like to request last call.=20
=20
Thanks
=20
Regards... Zafar =20

------_=_NextPart_001_01C75C5B.2661B6D1
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.1561" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial size=3D2>Hi =
Adrian,=20
Deborah,&nbsp;Dimitri, and campers- &nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial size=3D2>As we =
mentioned at=20
the last IETF meeting, <A=20
href=3D"http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm">=
http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm</A>,=20
we have addressed all outstanding comments, except the following comment =
from=20
Dimitri,&nbsp;related to this ID. Should you have any further comment, =
please=20
share. </FONT></SPAN></DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial size=3D2>The =
only remaining=20
comment that is not closed is "should this ID be informational or =
standard=20
track".&nbsp;IMO the ID defines&nbsp;a new error-subcode and some =
specific=20
behavior, and should be standard track. Can you please&nbsp;comment on=20
this.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D766361923-01032007></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial size=3D2>The ID =
has been=20
stable for quite some time and&nbsp;following the closure of the above, =
we would=20
like to request last call.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D766361923-01032007></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial=20
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D766361923-01032007></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D766361923-01032007><FONT face=3DArial =
size=3D2>Regards... Zafar=20
</FONT>&nbsp;</SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C75C5B.2661B6D1--

Delivery-date: Thu, 01 Mar 2007 20:51:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Date: Thu, 01 Mar 2007 15:50:02 -0500

--NextPart

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

	Title		: 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
	
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-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-rsvp-te-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-rsvp-te-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-rsvp-te-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-rsvp-te-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: Thu, 01 Mar 2007 19:51:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
Date: Thu, 1 Mar 2007 20:48:53 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Mike,

Thanks for these comments.

Please see inline,

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de Adrian Farrel
> Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10
> =C0 : [email-masked]
> Objet : Review comments on=20
> draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
>=20
>=20
> From: "mike shand" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>; "'Jean Philippe Vasseur'" <[email-masked]>
> Sent: Thursday, February 15, 2007 10:47 AM
> Subject: Re: [Isis-wg] PCE working group last call on=20
> draft-ietf-pce-disco-proto-isis-02.txt
>=20
>=20
> > Adrian, JP,
> >
> >
> > A few comments below, mostly typos.
> >
> >         Mike
> >
> >
> > General comment... sometimes the document refers to octets and=20
> > sometimes to bytes. It would be preferable to use a=20
> consistent term throughout.

OK

> >
> >
> >
> > Abstract
> >
> >
> >    along with some of information that can be used for PCE=20
> selection.
> >
> >
> > some of THE information
> >
> > or
> >
> > some information

OK

> >
> > 1. Terminology
> >
> > ABR is not a commonly used term in the context of IS-IS and doesn't=20
> > appear to be referenced in the document.

OK

> >
> > domain. This definition is different from that commonly used for=20
> > IS-IS. Is there a reason for the difference? The document refers to=20
> > IS-IS routing domains. Is it intended that a domain is=20
> different from a routing domain?

This is a domain as defined in the PCE architecture spec (RFC4655)

"A domain is any collection of network elements within a common sphere =
of address management or path computation responsibility.  Examples of =
domains include IGP areas, Autonomous Systems (ASes), and multiple ASes =
within a Service Provider network.  Domains of path computation =
responsibility may also exist as sub-domains of areas or ASes."

We are going to clarify. We can use the term "Path Computation Domain" =
to be more specific.

> >
> >
> > top of page 5
> >
> >
> > This document does not define any new IS-IS elements of procedure.
> >    The procedures defined in [IS-IS-CAP] should be used.
> >
> >
> > should that be ... MUST be used?

OK, MUST be used

> >
> > 3.2 flooding scope
> >
> >
> >   be limited to one or more IS-IS areas the PCE belongs to,=20
> or can be
> >
> > one or more IS-IS areas to which the PCE belongs
> >
> > would be better
> >
> >
> > 4.1. The IS-IS PCED TLV
> >
> > In the introduction this is referred to (correctly) as a=20
> sub-TLV, but=20
> > here and in subsequent text it is referred to as a TLV. This is=20
> > confusing to say the least.

OK, to be changed to sub-TLV

> >
> >
> > The format of the IS-IS PCED TLV and its sub-TLVs is the=20
> identical to
> >
> > is identical to

OK

> >
> >
> >
> > 4.1.6. The CONGESTION sub-TLV
> >
> >
> >   The CONGESTION sub-TLV is used to indicate a PCE's experiences a
> >
> > to indicate THAT a PCE experiences
> >
> > or
> >
> > to indicate a PCE's experience of a
> >
> > or
> >
> > to indicate that a PCE is experiencing a

OK

> >
> >
> >  VALUE: This comprises a one-byte bit flags indicating the
> >
> >
> > this reads rather strangely
> >
> > this comprises one byte of bit flags....

OK

> >
> >
> >
> >
> > 5. Elements of Procedure
> >
> >
> > typo
> >
> >
> >   domain, itMUST be carried within an IS-IS CAPABILITY TLV=20
> having the=20
> > S
> >
> >
> >    When the PCE function is deactivated on a node, the node MUST
> >    originate a new IS-IS LSP with no longer any PCED TLV. A=20
> PCC MUST be
> >    able to detect that the PCED TLV has been removed from=20
> an IS-IS LSP.
> >
> >
> > are we assuming here that all this information will always=20
> fit within=20
> > a single LSP?  That is probably reasonable

Yes

> >
> > Are we also assuming that it will always fit within a=20
> single IS-IS CAP=20
> > TLV? That may not be so reasonable.

Actually this sounds reasonable

2 * PCE-ADDRESS + PATH-SCOPE + CONGESTION + PCE-CAP-FLAGs (with 32 =
flags) =3D 40 bytes.

This let 256 - 2 -40 =3D 214 bytes for the PCE-DOMAINS and =
PCE-NEIG-DOMAINS, which allows encoding 35 neighbor ASes for instance.

Splitting a PCED TLV would add useless complexity.
We are going to add this statement : The PCED TLV MUST fit in with a =
single ISIS CAP TLV.=20
By the way this restricts the number of PCE domains and neighbor domains =
to a reasonable value.

Does that make sense?

> >
> > If it requires two IS-IS CAP TLVS, is there a requirement=20
> that they be=20
> > carried in the same LSP?
> >
> >
> >
> > 7.1. IS-IS sub-TLV
> >
> >    Once a registry for the IS-IS Router Capability TLV defined in
> >    [IS-IS-CAP] will have been assigned, IANA will assign a new
> >
> >
> > "has been assigned" would be better

OK

> >
> >
> >
> > 9.5. Requirements on Other Protocols and Functional Components
> >
> >    The IS-IS extensions defined in this documents does not imply any
> >    requirement on other protocols.
> >
> > do not imply (IS-IS extensions is plural)

OK

Thanks a lot. Once the last call is completed, we are going to submit a =
new revision that accounts for all these comments.

Regards,

JL

>=20
>=20
>=20
>=20

Delivery-date: Thu, 01 Mar 2007 14:01:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>
Subject: New revision of draft-ietf-ccamp-lsp-stitching
Date: Thu, 1 Mar 2007 13:58:27 -0000
Organization: Old Dog Consulting

Hi,

I appear to have taken over editing this I-D to prepare it for WG last call.

Here are my responses to my own review comments (yes, really!) that have 
been incorporated into the new revision just submitted.

Adrian

> ===
>
> idnits generates the following comments
>  * There are 96 instances of too long lines in the document, the longest
>    one being 1 character in excess of 72.

Indentation fixed.

>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  - It seems as if not all pages are separated by form feeds - found 0 form
>    feeds but 22 pages

Form feeds inserted.

> ===
>
> The boilerplate will need to be updated for the new IETF Trust language.

Updated.

> ===
> Abstract.
>
> First paragraph is a good introduction.
> Second paragraph is fine and OK.
> But the Abstract also needs to say what the document is about!
> I suggest the addition of a new 2nd paragraph as follows...
>
>    This document describes extensions to the existing GMPLS signaling
>    protocol (RSVP-TE) to establish e2e LSPs from S-LSPs, and describes
>    how the LSPs can be managed using the GMPLS signaling and routing
>    protocols.

Test added.

> ===
>
> Acronyms
>
> Acronyms need to be expanded on their first use in the body of the 
> document regardless of whether they appear in the document title or in the 
> Abstract.
> I found...
> LSP
> GMPLS
> P2MP
> RRO

Changes made.

> ===
>
> Introduction
>
> The Introduction section is pretty lumpy. It seems to spend most of its 
> time talking about hierarchical LSPs, and only defines stitching in the 
> final paragraph.
>
> I suggest some re-ordering and a little editing as follows:
>
> New Section 1
>
>    A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
>    Engineering (TE) Label Switched Path (LSP) is built from a set of
>    different LSP segments (S-LSPs) that are connected together in the
>    data plane in such a way that a single end-to-end LSP is realized in
>    the data plane.  In this document, we define the concept of LSP
>    stitching and detail the control plane mechanisms and procedures
>    (routing and signaling) to accomplish this.  Where applicable,
>    similarities and differences between LSP hierarchy [2] and LSP
>    stitching are highlighted.  Signaling extensions required for LSP
>    stitching are also described here.
>
>    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, and such that the operation is completely transparent to
>    other nodes.  This results in LSP stitching in the data plane, but
>    requires management intervention at the node where the stitching is
>    performed.  With the mechanism described in this document, the node
>    performing the stitching does not require configuration of the pair
>    of S-LSPs to be stitched together.  Also, LSP stitching as defined
>    here results in an end-to-end LSP both in the control and data
>    planes.

Done.

> Move the following paragraphs (unchanged) from Section 1 to the top of 
> Section 2.
>
>    LSP hierarchy ([2]) provides signaling and routing procedures so
>    that:
>
>    a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
>        in one layer can appear as a data link to LSPs in higher layers.
>        As such, one or more LSPs in a higher layer can traverse this
>        H-LSP as a single hop; we call this "nesting".
>
>    b.  An H-LSP may be managed and advertised (although this is not a
>        requirement) as a Traffic Engineering (TE) link.  Advertising an
>        H-LSP as a TE link allows other nodes in the TE domain in which
>        it is advertised to use this H-LSP in path computation.  If the
>        H-LSP TE link is advertised in the same instance of control plane
>        (TE domain) in which the H-LSP was provisioned, it is then
>        defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
>        can form a forwarding adjacency (FA) over this FA-LSP.  There is
>        usually no routing adjacency between end points of an FA.  An
>        H-LSP may also be advertised as a TE link in a different TE
>        domain.  In this case, the end points of the H-LSP are required
>        have a routing adjacency between them.
>
>    c.  RSVP signaling for LSP setup can occur between nodes that do not
>        have a routing adjacency.

Done, resulting in a shorter Section 1, and a longer Section 2.

> ===
>
> Section 3.2
>
> It might be useful to include a reference to RFC4726 to give some context 
> for inter-domain uses of stitching.

Added in 2nd paragraph.

> ===
>
> Security considerations
>
> I don't think we will get away with what is currently written :-(
> The killer is:
>    Mechanisms described in [6] should be
>    re-examined and may need to be altered to define new security
>    associations based on receiver's IP address instead of the sending
>    and receiving interfaces.
>
> I think that if you say that the re-examination is needed, you must do it. 
> You need to satisfy yourself as to whether any changes (beyond those 
> expressed in RFC4206) are needed.
>
> My view is that you should be able to echo the text of RFC4206 without 
> needing anything further. This is because the relationship between the 
> end-points of the S-LSP is the same as that between the end points of the 
> H-LSP in RFC4206. The precedent for remote signaling adjacencies has 
> already been established, and you are not defining anything new.

Security section re-written as follows:

   From a security point of view, the changes introduced in this
   document model the changes introduced by [2].  That is, the control
   interface over which RSVP messages are sent or received need not be
   the same as the data interface which the message identifies for
   switching traffic.  But the capability for this function was
   introduced in [4] to support the concept of out-of-fiber control
   channels, so there is nothing new in this concept for signaling or
   security.

   The application of this facility means that the "sending interface"
   or "receiving interface" may change as routing changes.  So, these
   interfaces cannot be used to establish security association between
   neighbors, and security associations MUST be bound to the
   communicating neighbors themselves.

   [6] provides a solution to this issue: in Section 2.1, under "Key
   Identifier", an IP address is a valid identifier for the sending (and
   by analogy, receiving) interface.  Since RSVP messages for a given
   LSP are sent to an IP address that identifies the next/previous hop
   for the LSP, one can replace all occurrences of 'sending [receiving]
   interface' with 'receiver's [sender's] IP address' (respectively).
   For example, in Section 4, third paragraph, instead of:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured sending interface (or LIH).  ...  At the sender,
       security association selection is based on the interface through
       which the message is sent."

   it should read:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured receiver's IP address. ...  At the sender, security
       association selection is based on the IP address to which the
       message is sent."

   Thus the mechanisms of [6] can be used unchanged to establish
   security associations between control plane neighbors.

   This document allows the IP destination address of Path and PathTear
   messages to be the IP address of a nexthop node (receiver's address)
   instead of the RSVP session destination address.  This means that the
   use of the IPsec Authentication Header (AH) (ruled out in [6] because
   RSVP messages were encapsulated in IP packets addressed to the
   ultimate destination of the Path or PathTear messages) is now
   perfectly applicable, and standard IPsec procedures can be used to
   secure the message exchanges.

   An analysis of GMPLS security issues can be found in [16].

> ===
>
> IANA considerations
>
> It would be helpful to name the sub-registries to help IANA get these 
> allocations right.
>
> In section 7.1 the registry is "RSVP TE Parameters" (not the registry 
> quoted in section 7) and the sub-registry is "Attributes Flags"
>
> In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP) 
> Parameters" and the sub-registry is "Error Codes and Globally-Defined 
> Error Value Sub-Codes"

Done.

> It is also helpful to supply the precise text you would like added to the 
> registry.
>
> For section 7.1:
>
>                                       Path      Resv      RRO
> Bit   Name                             message   message   sub-object 
> Reference
> ----  -------------------------------  --------  --------  ----------  ---------
> 5     LSP stitching desired bit        Yes       No        Yes 
> [This doc]
>
>
> For section 7.2:
>
>  24  Routing Problem                             [RFC3209]
>
>        23 = Stitching unsupported  [This doc]

Done.

Delivery-date: Thu, 01 Mar 2007 11:11:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
Date: Thu, 1 Mar 2007 11:05:51 -0000
Organization: Old Dog Consulting

Hi,

>From which response, I interpret Dimitri as saying that:

"Further, technology-specific documents might be written to define standard 
encoding of this (and other?) fields of the ISCD sub-TLV."

Is that correct?

The text in 4.2 appears more definitive than that. Perhaps, if the text 
shows just a potential encoding and not a defined encoding, you might 
consider making that very clear of removing the text?

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 01, 2007 7:54 AM
Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

> hi vijay
>
> technology specific information encoding as part
> of the techno specific field of the ISCD sub-TLV
> is outside scope of this document, that defines
> the generic routing mechanisms for OSPF
>
> the paragraph you pointed is given as example, to
> clearly indicate where this information has to be
> encoded but is not going to be further detailed
>
> in other terms techno-specific bw accounting is
> outside the scope of the document
>
> thanks,
> - d.
>
>
>
>
>
> "Pandian, Vijay" <[email-masked]>
> Sent by: [email-masked]
> 01/03/2007 03:35
>
>        To:     <[email-masked]>
>        cc:
>        Subject:        Question on
> draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
>
>
> Hi,
>
> In section 4.2 Technology Specific Bandwidth Accounting, it says:
>
>   In the ASON context, accounting on per timeslot basis using 32-bit
>   tuples of the form <signal_type (8 bits); number of unallocated
>   timeslots (24 bits)> may optionally be incorporated in the
>   technology specific field of the ISCD TE link attribute when the
>   switching capability field is set to TDM value. When included,
>   format and encoding MUST follow the rules defined in [RFC4202].
>
> The signal types as defined in RFC4606 Section 2.1 covers a basic set. The
> signal type is used in conjunction with the other attributes like RCC,
> NCC, etc., to determine other Elementary Signal such as STS-12c SPE,
> STS-48c SPE, STS-192c SPE etc.
>
> It is not clear to me how this 8-bit filed could be used to cover all the
> different types of signal types.
>
> Thanks and best regards,
>
> Vijay
>
>
>
>
> 

Delivery-date: Thu, 01 Mar 2007 07:56:46 +0000
To: "Pandian, Vijay" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
From: [email-masked]
Date: Thu, 1 Mar 2007 08:54:53 +0100

hi vijay

technology specific information encoding as part
of the techno specific field of the ISCD sub-TLV
is outside scope of this document, that defines
the generic routing mechanisms for OSPF

the paragraph you pointed is given as example, to
clearly indicate where this information has to be
encoded but is not going to be further detailed

in other terms techno-specific bw accounting is
outside the scope of the document

thanks,
- d.

"Pandian, Vijay" <[email-masked]>
Sent by: [email-masked]
01/03/2007 03:35
 
        To:     <[email-masked]>
        cc: 
        Subject:        Question on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

Hi,
 
In section 4.2 Technology Specific Bandwidth Accounting, it says:
 
   In the ASON context, accounting on per timeslot basis using 32-bit 
   tuples of the form <signal_type (8 bits); number of unallocated 
   timeslots (24 bits)> may optionally be incorporated in the 
   technology specific field of the ISCD TE link attribute when the 
   switching capability field is set to TDM value. When included, 
   format and encoding MUST follow the rules defined in [RFC4202]. 
 
The signal types as defined in RFC4606 Section 2.1 covers a basic set. The 
signal type is used in conjunction with the other attributes like RCC, 
NCC, etc., to determine other Elementary Signal such as STS-12c SPE, 
STS-48c SPE, STS-192c SPE etc.
 
It is not clear to me how this 8-bit filed could be used to cover all the 
different types of signal types.
 
Thanks and best regards,
 
Vijay

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Mar 2007 05:10:34 +0000
Date: Wed, 28 Feb 2007 21:08:55 -0800
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4803 on Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base
From: [email-masked]
Cc: [email-masked], [email-masked]

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

        RFC 4803

        Title:      Generalized Multiprotocol Label Switching (GMPLS) 
                    Label Switching Router (LSR) Management Information 
                    Base 
        Author:     T. Nadeau, Ed., A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      42
        Characters: 79925
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-lsr-mib-15.txt

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

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSR).  [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

...

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Mar 2007 05:10:26 +0000
Date: Wed, 28 Feb 2007 21:09:47 -0800
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4802 on Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base
From: [email-masked]
Cc: [email-masked], [email-masked]

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

        RFC 4802

        Title:      Generalized Multiprotocol Label Switching (GMPLS) 
                    Traffic Engineering Management Information Base 
        Author:     T. Nadeau, Ed., A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      60
        Characters: 118164
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-te-mib-16.txt

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

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for Generalized
Multiprotocol Label Switching (GMPLS)-based traffic engineering.
[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

...

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Mar 2007 05:10:18 +0000
Date: Wed, 28 Feb 2007 21:10:07 -0800
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4801 on Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management
From: [email-masked]
Cc: [email-masked], [email-masked]

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

        RFC 4801

        Title:      Definitions of Textual Conventions for 
                    Generalized Multiprotocol Label Switching (GMPLS) 
                    Management 
        Author:     T. Nadeau, Ed.,
                    A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      9
        Characters: 16347
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-tc-mib-11.txt

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

This document defines a Management Information Base (MIB) module
that contains textual conventions (TCs) to represent commonly used
Generalized Multiprotocol Label Switching (GMPLS) management
information.  The intent is that these textual conventions will
be imported and used in GMPLS-related MIB modules that would
otherwise define their own representations.  [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: Thu, 01 Mar 2007 02:36:23 +0000
Content-class: urn:content-classes:message
Subject: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt 
Date: Wed, 28 Feb 2007 21:35:38 -0500
From: "Pandian, Vijay" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi,
=20
In section 4.2 Technology Specific Bandwidth Accounting, it says:
=20
   In the ASON context, accounting on per timeslot basis using 32-bit=20
   tuples of the form <signal_type (8 bits); number of unallocated=20
   timeslots (24 bits)> may optionally be incorporated in the=20
   technology specific field of the ISCD TE link attribute when the=20
   switching capability field is set to TDM value. When included,=20
   format and encoding MUST follow the rules defined in [RFC4202].=20

=20
The signal types as defined in RFC4606 Section 2.1 covers a basic set. =
The signal type is used in conjunction with the other attributes like =
RCC, NCC, etc., to determine other Elementary Signal such as STS-12c =
SPE, STS-48c SPE, STS-192c SPE etc.
=20
It is not clear to me how this 8-bit filed could be used to cover all =
the different types of signal types.
=20
Thanks and best regards,
=20
Vijay

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

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

<META content=3D"MSHTML 6.00.2800.1561" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT size=3D2>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D423470116-20022007>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D423470116-20022007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D423470116-20022007>In =
section 4.2=20
Technology Specific Bandwidth Accounting, it says:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D423470116-20022007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D423470116-20022007>&nbsp;&nbsp; In the=20
ASON context, accounting on per timeslot basis using 32-bit =
<BR>&nbsp;&nbsp;=20
tuples of the form &lt;signal_type (8 bits); number of unallocated=20
<BR>&nbsp;&nbsp; timeslots (24 bits)&gt; may optionally be incorporated =
in the=20
<BR>&nbsp;&nbsp; technology specific field of the ISCD TE link attribute =
when=20
the <BR>&nbsp;&nbsp; switching capability field is set to TDM value. =
When=20
included, <BR>&nbsp;&nbsp; format and encoding MUST follow the rules =
defined in=20
[RFC4202]. <BR></SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3D423470116-20022007><FONT =
size=3D3><FONT face=3DArial=20
size=3D2></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D423470116-20022007><FONT face=3DArial><SPAN=20
class=3D714532302-01032007>T</SPAN>he signal type<SPAN =
class=3D714532302-01032007>s=20
a</SPAN>s defined&nbsp;in RFC4606 Section 2.1<SPAN =
class=3D714532302-01032007>=20
covers&nbsp;a basic set.</SPAN>&nbsp;<SPAN =
class=3D714532302-01032007>T</SPAN>he=20
signal type is used in conjunction with the other attributes like RCC, =
NCC,=20
etc., to determine&nbsp;<SPAN=20
class=3D714532302-01032007>other</SPAN>&nbsp;Elementary Signal<SPAN=20
class=3D714532302-01032007> such as STS-12c SPE, STS-48c SPE, STS-192c =
SPE=20
etc.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D423470116-20022007><FONT face=3DArial><SPAN=20
class=3D714532302-01032007></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D423470116-20022007><SPAN =
class=3D714532302-01032007><FONT=20
face=3DArial>It is not clear to me how this 8-bit filed could be used to =
cover all=20
the different types of signal types.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D423470116-20022007><SPAN =
class=3D714532302-01032007><FONT=20
face=3DArial></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><FONT size=3D2><SPAN class=3D423470116-20022007><FONT =
size=3D3><FONT face=3DArial=20
size=3D2>Thanks and best regards,</FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3D423470116-20022007><FONT =
size=3D3><FONT face=3DArial=20
size=3D2></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><SPAN class=3D423470116-20022007><FONT =
size=3D3><FONT face=3DArial=20
size=3D2>Vijay</FONT></DIV></FONT></SPAN></FONT></FONT></DIV></BODY></HTM=
L>

------_=_NextPart_001_01C75BAA.4C2DEEC8--