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

[Huub van Helvoort <[e-mail]>]

Hello Adrian,

You wondered:

> Huub, Kam,
> 
> Should we also liaise the VCAT/LCAS work to Q11/15?
> 
> Or is it enough to send it to SG15 and let the TSB work out who should 
> get it?

Since you already know that both Q14 and Q11 are involved
you may as well direct the liaison to both questions.

Cheers, Huub.





Envelope-to: [e-mail]
Delivery-date: Sat, 31 Mar 2007 21:26:59 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Mar 2007 23:23:40 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: "Lam, Hing-Kam \(Kam\)" <[e-mail]>,  [e-mail]
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Adrian,

You wondered:

> Huub, Kam,
> 
> Should we also liaise the VCAT/LCAS work to Q11/15?
> 
> Or is it enough to send it to SG15 and let the TSB work out who should 
> get it?

Since you already know that both Q14 and Q11 are involved
you may as well direct the liaison to both questions.

Cheers, Huub.



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Mar 2007 18:13:01 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: Greg Jones <[e-mail]>
Cc: Stephen Trowbridge <[e-mail]>, Kam Lam <[e-mail]>, Ross Callon <[e-mail]>, Dave Ward <[e-mail]>, Scott Bradner <[e-mail]>, CCAMP Mailing List <[e-mail]>, Deborah Brungard <[e-mail]>, Adrian Farrel <[e-mail]>, Deborah Brungard <[e-mail]>, Adrian Farrel <[e-mail]>, Deborah Brungard <[e-mail]>
From: Adrian Farrel (IETF CCAMP WG) <[e-mail]>
Subject: New Liaison Statement, "New CCAMP RFCs Published" 
Reply-To: Adrian Farrel <[e-mail]>
Message-Id: <[e-mail]>
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) <[e-mail]>
To: ITU-T SG15(Greg Jones <[e-mail]>)
Cc: Stephen Trowbridge <[e-mail]>
Kam Lam <[e-mail]>
Ross Callon <[e-mail]>
Dave Ward <[e-mail]>
Scott Bradner <[e-mail]>
CCAMP Mailing List <[e-mail]>
Deborah Brungard <[e-mail]>
Reponse Contact: Adrian Farrel <[e-mail]>
Deborah Brungard <[e-mail]>
Technical Contact: Adrian Farrel <[e-mail]>
Deborah Brungard <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 22:38:57 +0000
Message-ID: <0fe601c77252$cb85d960$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: DISCUSS: draft-ietf-ccamp-gmpls-rsvp-te-call 
Date: Thu, 29 Mar 2007 23:36:30 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

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

Adrian
----- Original Message ----- 
From: "Sam Hartman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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.





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 15:44:44 +0000
Message-ID: <0f3d01c77219$0606db50$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Dave Ward" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Another draft liaison to SG15: Call/Connection Separation
Date: Thu, 29 Mar 2007 15:53:41 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 14:50:15 +0000
Message-ID: <0eef01c77211$1b034c80$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Lam, Hing-Kam \(Kam\)" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Date: Thu, 29 Mar 2007 15:46:09 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

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


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





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 11:40:21 +0000
Message-ID: <0eab01c771f6$f7e10040$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Date: Thu, 29 Mar 2007 12:39:36 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

Thanks Huub,

I will make changes accordingly.

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


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





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 11:34:33 +0000
Message-ID: <0e5101c771f5$bf431800$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Dave Ward" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Draft liaison to ITU SG15 on process
Date: Thu, 29 Mar 2007 12:21:43 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

One of the larger issues raised by a recent liaison from ITU-T Study Group
15 is on process and how we can continue to build a better relationship
between SG15 and CCAMP.

Here is a draft response.

Comments please by end of April 5th.

Thanks,
Adrian and Deborah
===

To: ITU-T SG15
From: IETF CCAMP
Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross Callon,
Dave Ward
For Action
Deadline: 25th June 2007

Subject: Cooperative Relationship between ITU-T SG15 and CCAMP

CCAMP thanks you for your liaison   entitled "Liaison Statement to CCAMP
responding to ccamp liaison of 21 February 2007". The last paragraphs of
your liaison discuss the cooperative relationship between ITU-T SG15 and the
IETF's CCAMP working group and we would like to respond to these issues
separate from the technical discussions.

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

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

In your liaison, you say:

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

We appreciate your engagement with this process and we believe that it is to
the best interests of the industry and to all participants in both
bodies. In order to crystallise this process, the IETF has recently
published RFC 4775 ("Procedures for Protocol Extensions and Variations") and
has just consented for publication draft-andersson-rtg-gmpls-change-08.txt
("Change Process for Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Protocols and Procedures"). The net effect of these documents
is to give the ITU-T clear access into the IETF process and to commit the
IETF to work with the ITU-T to develop solutions to requirements that
originate in the ITU-T.

You state further:

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

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

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

As you go on to say:

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

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

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

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

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

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

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

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

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

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

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

Subsequent liaisons on the material of RFC 4652 included:

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

Your recent liaison concludes:

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

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

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

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

Best regards,

Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 11:34:25 +0000
Message-ID: <0e5301c771f5$c1cb97a0$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Dave Ward" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Update: Draft liaison to ITU-T SG15 : MLN work
Date: Thu, 29 Mar 2007 12:27:17 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

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,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group





Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 07:39:02 +0000
Message-ID: <30839666.1175153854204.JavaMail.root@amsfep17>
Date: Thu, 29 Mar 2007 7:37:34 +0000
From:  <[e-mail]>
To: [e-mail], Adrian Farrel <[e-mail]>
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
Cc: Scott Bradner <[e-mail]>, Dave Ward <[e-mail]>,  Ross Callon <[e-mail]>,  "Brungard, Deborah A, ALABS" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sensitivity: Normal

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 




Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 06:26:05 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Thu, 29 Mar 2007 02:24:35 -0400
Subject: Re: Draft liaison to ITU-T SG 15 : VCAT
From: Monique Morrow <[e-mail]>
To: Adrian Farrel <[e-mail]>, <[e-mail]>
CC: "Brungard, Deborah A, ALABS" <[e-mail]>, Ross Callon <[e-mail]>, Dave Ward <[e-mail]>, Scott Bradner <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Draft liaison to ITU-T SG 15 : VCAT
Thread-Index: AcdxyutlKeDJ9d2+EduENQANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1775; t=1175149476; x=1176013476; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Monique=20Morrow=20<[e-mail]> |Subject:=20Re=3A=20Draft=20liaison=20to=20ITU-T=20SG=2015=20=3A=20VCAT |Sender:=20; bh=pIRX/5N3dA6+MWGi9vmGFlz5Vb7O3OIvqM/S3rFPXwU=; b=G2Ttjr77rRynzodpuGeLyKqMuNKPlCJNZi45KV6wCvZWeQZz5YdMHn4z1Ls7OsjEjKV+w3Jf ydGJrWDSGis8FGpqHTCY83luWsHrmfGSbe30ZxS1ox324mbMzNuBJiDS;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

Looks fine  - thanks again!

/m


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

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



Envelope-to: [e-mail]
Delivery-date: Thu, 29 Mar 2007 06:25:57 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Thu, 29 Mar 2007 02:23:48 -0400
Subject: Re: Draft liaison to ITU-T SG15 : MLN work
From: Monique Morrow <[e-mail]>
To: Adrian Farrel <[e-mail]>, <[e-mail]>
CC: "Brungard, Deborah A, ALABS" <[e-mail]>, Ross Callon <[e-mail]>, Dave Ward <[e-mail]>, Scott Bradner <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Draft liaison to ITU-T SG15 : MLN work
Thread-Index: Acdxys9iDfA8Nt2+EduENQANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1964; t=1175149430; x=1176013430; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Monique=20Morrow=20<[e-mail]> |Subject:=20Re=3A=20Draft=20liaison=20to=20ITU-T=20SG15=20=3A=20MLN=20wor k |Sender:=20; bh=RXwKsF4p0LBMhiXMEnXpbkHC5GknMxiqphBm6bUdKB8=; b=EaO4U0n16D5xj3fC0IFUdBu2az/l+MM7FhRn6eEPu9/u6qZViWH2n4Cxn+oHnujDvOHrKhvY XEaCS4kWwRMsZp0Hgq8jhKeekXPsm0q8pEnE7Lbs32BxhysiRqJUghLI;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

Looks ok Adrian!

/m


On 28/3/07 3:22 pm, "Adrian Farrel" <[e-mail]> 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
> 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-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,
> Adrian Farrel and Deborah Brungard
> Co-chairs, IETF CCAMP Working Group
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Mar 2007 19:54:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77172.ACFFD779"
Subject: Draft minutes - Session II
Date: Wed, 28 Mar 2007 14:52:53 -0500
Message-ID: <[e-mail]>
Thread-Topic: Draft minutes - Session II
Thread-Index: Acdxcqx8wpWu6N5DTrymWL2znGo4cw==
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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
<[e-mail]><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Deborah=20
Brungard <[e-mail]><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--



Envelope-to: [e-mail]
Delivery-date: Wed, 28 Mar 2007 19:27:19 +0000
Message-ID: <0da801c7716f$0f071760$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Dave Ward" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Draft liaison to ITU-T SG 15 : VCAT
Date: Wed, 28 Mar 2007 20:26:49 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

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

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 





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Mar 2007 19:26:56 +0000
Message-ID: <0d9901c7716e$8529f850$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, "Ross Callon" <[e-mail]>, "Dave Ward" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Draft liaison to ITU-T SG15 : MLN work
Date: Wed, 28 Mar 2007 20:22:56 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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,
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group 





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Mar 2007 14:32:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77145.11C00D09"
Subject: Draft minutes
Date: Wed, 28 Mar 2007 09:26:24 -0500
Message-ID: <[e-mail]>
Thread-Topic: Draft minutes
Thread-Index: AcdxRRCdqUTCXW4MTA6kyWZeoSa+ig==
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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 <[e-mail]>
        Deborah Brungard <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Tue, 27 Mar 2007 13:57:27 +0000
Message-ID: <097501c77077$6b92f240$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Progressing the discussion on liaison responses
Date: Tue, 27 Mar 2007 14:53:02 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; "BRUNGARD, DEBORAH A, ATTLABS" 
<[e-mail]>
Cc: "Ong, Lyndon" <[e-mail]>
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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, March 20, 2007 11:39 AM
> To: [e-mail]
> 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





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Mar 2007 20:54:42 +0000
Message-ID: <087b01c76fe8$a12c0160$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Planned liaison responses to ITU-T SG15
Date: Mon, 26 Mar 2007 21:51:24 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Mar 2007 10:59:47 +0000
Message-ID: <05f101c76f95$c5bb86c0$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Non-member submission from ["Italo Busi" <[e-mail]>]   
Date: Mon, 26 Mar 2007 11:58:57 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> From [e-mail] Fri Mar 23 14:37:09 2007
> To: "Monique Morrow" <[e-mail]>,
>        "Huub van Helvoort" <[e-mail]>,
>        "Ong, Lyndon" <[e-mail]>
> Cc: <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]]On
>> Behalf Of Monique Morrow
>> Sent: Thursday, March 22, 2007 11:01 AM
>> To: Huub van Helvoort; Ong, Lyndon
>> Cc: [e-mail]
>> 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" <[e-mail]> 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.





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Mar 2007 10:49:54 +0000
Message-ID: <059601c76f91$26c42bc0$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw:Non-member submission from ["Ken Young" <[e-mail]>]   
Date: Mon, 26 Mar 2007 11:25:53 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> From [e-mail] Thu Mar 22 21:47:49 2007
> Subject: Re: Progressing the discussion on liaison responses
> To: "Adrian Farrel" <[e-mail]>,
> "Dimitri Papadimitriou" <[e-mail]>,
> "Lyndon Ong" <[e-mail]>
> Cc: <[e-mail]>,
> 
> 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





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Mar 2007 10:49:46 +0000
Message-ID: <059701c76f91$5f23a0e0$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw:Non-member submission from ["Ken Young" <[e-mail]>]   
Date: Mon, 26 Mar 2007 11:27:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> From [e-mail] Thu Mar 22 22:23:34 2007
> Subject: RE: Progressing the discussion on liaison responses
> To: "Ong, Lyndon" <[e-mail]>,
> "Adrian Farrel" <[e-mail]>,
> "Dimitri Papadimitriou" <[e-mail]>
> Cc: <[e-mail]>,
> 
> 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:[e-mail]]
> Sent: Thu 3/22/2007 18:12
> To: Ken Young; Adrian Farrel; Dimitri Papadimitriou
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: Thursday, March 22, 2007 2:47 PM
> To: Adrian Farrel; Dimitri Papadimitriou; Ong, Lyndon
> Cc: [e-mail]; [e-mail]
> 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





Envelope-to: [e-mail]
Delivery-date: Mon, 26 Mar 2007 08:35:07 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
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 <[e-mail]>
To: Italo Busi <[e-mail]>, Huub van Helvoort <[e-mail]>, "Ong, Lyndon" <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: ITU-T Q.14/15 alignment with ITU-T SG13 work
Thread-Index: AcdvgVKQkOS7L9t0EduEQwANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1911; t=1174897969; x=1175761969; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Monique=20Morrow=20<[e-mail]> |Subject:=20Re=3A=20ITU-T=20Q.14/15=20alignment=20with=20ITU-T=20SG13=20w ork |Sender:=20; bh=6/MXteuIETo7KvkVysRUPTtzTpiO9fGtxB8YOVSdo6o=; b=dMloxekaS462NRzKWzIRZ6tzmojE4QYBqaJwTlc20rnGtMzILlUwrldBHrH8+5zh6tBrv0vL N9k3Ye79rKJmosmwhJlZDorVkOgMSB171KDM3CHOGJ8zcLoFZO1V45Jb;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]]On
>> Behalf Of Monique Morrow
>> Sent: Thursday, March 22, 2007 11:01 AM
>> To: Huub van Helvoort; Ong, Lyndon
>> Cc: [e-mail]
>> 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" <[e-mail]> 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.
>> 
>> 



Envelope-to: [e-mail]
Delivery-date: Sat, 24 Mar 2007 10:17:54 +0000
To: [e-mail]
Subject: GELS slides - comments
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 24 Mar 2007 11:14:43 +0100
Content-Type: text/plain; charset="US-ASCII"

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.

 



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 22:16:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Progressing the discussion on liaison responses
Date: Thu, 22 Mar 2007 18:12:10 -0400
Message-ID: <[e-mail]>
Thread-Topic: Progressing the discussion on liaison responses
thread-index: Acdsyam9ETLP1rayQeOLs9/dSAh7iwAA0vKA
From: "Ong, Lyndon" <[e-mail]>
To: "Ken Young" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

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:[e-mail]]=20
Sent: Thursday, March 22, 2007 2:47 PM
To: Adrian Farrel; Dimitri Papadimitriou; Ong, Lyndon
Cc: [e-mail]; [e-mail]
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



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 18:18:37 +0000
Date: Thu, 22 Mar 2007 19:16:20 +0100
To: "Ong, Lyndon" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: Progressing the discussion on liaison responses
Cc: <[e-mail]>, "Adrian Farrel" <[e-mail]>,<[e-mail]>, <[e-mail]>, "JONES Jim D" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
>Behalf Of [e-mail]
>Sent: Tuesday, March 20, 2007 7:06 PM
>To: Adrian Farrel
>Cc: [e-mail]; [e-mail]
>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" <[e-mail]>
>Sent by: [e-mail]
>20/03/2007 16:39
>Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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




Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 10:02:56 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
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 <[e-mail]>
To: Huub van Helvoort <[e-mail]>, "Ong, Lyndon" <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: ITU-T Q.14/15 alignment with ITU-T SG13 work
Thread-Index: AcdsaQ7bTatj4thcEduKxwANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1063; t=1174557694; x=1175421694; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Monique=20Morrow=20<[e-mail]> |Subject:=20Re=3A=20ITU-T=20Q.14/15=20alignment=20with=20ITU-T=20SG13=20w ork |Sender:=20; bh=i5BLD7ealVAzanaGyPooHTVVrJTCy6Jdf949jpWVtnU=; b=p3pFQSyALFSx6rQ8N0OMDFoBeTMyO8p0W7BVtZQWIq/xXtoo90Jn5hSiH3JnrNIWMJscL74X gdljk4SdA+AiSkAdtbY3DQdFEFD6+EIBcBr0T+FbEr0elidcxuT5pNHw;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

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" <[e-mail]> 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.



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 09:21:30 +0000
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2007 10:20:21 +0100
From: Huub van Helvoort <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
CC:  [e-mail]
Subject: Re: ITU-T Q.14/15 alignment with ITU-T SG13 work
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 08:53:58 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
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 <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: ITU-T Q.14/15 alignment with ITU-T SG13 work
Thread-Index: AcdsWsxMyPRDGXYxTWiGAgxCRAzQtgABLbFq
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3257383988_178552"
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2476; t=1174553593; x=1175417593; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Monique=20Morrow=20<[e-mail]> |Subject:=20Re=3A=20ITU-T=20Q.14/15=20alignment=20with=20ITU-T=20SG13=20w ork |Sender:=20; bh=7Gof8kjls3kfrysbhMNmRY0lyufIRxRa3JPGE4Q74Yg=; b=f9dtT20F7dj+upljCVa47mFDF4OZpS3n0rZsaGLHVdZTPNWYTjL3ZOfsyVwydvlf6d7uBd4+ DPbGSAZiFHTcJh/JMjROfp5UBgbIhqPMrsdkYMi+kUaUlfRilb7pu+yy;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

> 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" <[e-mail]> 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;[e-mail]&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--



Envelope-to: [e-mail]
Delivery-date: Thu, 22 Mar 2007 08:23:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C5A.CD544131"
Subject: ITU-T Q.14/15 alignment with ITU-T SG13 work
Date: Thu, 22 Mar 2007 04:19:23 -0400
Message-ID: <[e-mail]>
Thread-Topic: ITU-T Q.14/15 alignment with ITU-T SG13 work
thread-index: AcdsWsxMyPRDGXYxTWiGAgxCRAzQtg==
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Wed, 21 Mar 2007 07:54:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Progressing the discussion on liaison responses
Date: Wed, 21 Mar 2007 03:49:25 -0400
Message-ID: <[e-mail]>
Thread-Topic: Progressing the discussion on liaison responses
thread-index: AcdrXqzoDTPnbCTBS+mDOA+WbTrexwALghQg
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "JONES Jim D" <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Tuesday, March 20, 2007 7:06 PM
To: Adrian Farrel
Cc: [e-mail]; [e-mail]
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" <[e-mail]>
Sent by: [e-mail]
20/03/2007 16:39
Please respond to "Adrian Farrel"
=20
        To:     <[e-mail]>
        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







Envelope-to: [e-mail]
Delivery-date: Wed, 21 Mar 2007 02:08:50 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Progressing the discussion on liaison responses
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 21 Mar 2007 03:05:43 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

YWRyaWFuDQoNCm8pIFZMQU4gSS1EDQoNCmkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIENhbGwgZnVu
Y3Rpb25hbGl0eSANCg0KIk5vIGluZm9ybWF0aW9uIHByb3ZpZGVkIG9uIFVOSSBUU1BFQyBleHBl
Y3RhdGlvbnMgKGUuZy4gZ3JhbnVsYXJpdHkgb2YgDQpDLVZMQU4gd2l0aGluIEVWQykgaW4gTGlh
aXNvbiINCg0KaSB0aGluayB0aGlzIGhhcyBiZWVuIGNsYXJpZmllZCBvbiB0aGlzIGxpc3QgaWYg
bXkgcmVjb3JkIGlzIGNvcnJlY3QNCg0KIkFueSBvdXRjb21lIG9mIGFkIGhvYyBkaXNjdXNzaW9u
cyB5ZXN0ZXJkYXk/Ig0KDQpyc3YgaXMgYXNzb2NpYXRlZCB0byB0aGUgdmMgYW5kIHRoZXJlIGFy
ZSB0d28gbW9kZXMgMToxIA0KPHZjL3Nlc3Npb24sbGFiZWwvc2Vzc2lvbiBhdHRyLj4gYW5kIDE6
TiA8dmMvc2Vzc2lvbixzZXQgb2YgbGFiZWxzL3Nlc3Npb24gDQphdHRyLj4gd2UgY2FuIGNvdmVy
IGJhc2UgY2FzZXMgYXMgbG9uZyBhcyBtc2cgc2l6ZSBkb2Vzbid0IGV4Y2VlZCBNVFUgc2l6ZSAN
Ci0gdGhlIHF1ZXN0aW9uIHdydCBwcm9ncmVzcyBhcmUgMSkgZG8gd2UgaGF2ZSBhIGNvcnJlY3Qg
dW5kZXJzdGFuZGluZyBvZiANCnRoZSBwcm9ibGVtIDIpIGRvIHdlIHdhbnQgdG8gcHJvZ3Jlc3Mg
b24gdGhlIHRvcGljIGlubGluZSB3aXRoIE1FRiANCmV4cGVjdGF0aW9ucyAzKSBpcyB0aGUgYmFz
ZSBtb2RlIGFjY2VwdGFibGUgdW50aWwgYSBtb3JlIGdlbmVyaWMgaXMgDQpwcm9wb3NlZCAob3Ig
c2hhbGwgd2UgcHJvcG9zZSBhIHNpbmdsZSBzb2x1dGlvbiBjb3ZlcmluZyBhbGwgY2FzZXMpDQoN
Cm8pIHRoZSBmb2xsb3dpbmcgaXMgb2RkLCBpbiBhIHNlbnNlIE9JRiBhc2tzIHRvIGNvbW1lbnQg
YnV0IGlzIGlnbm9yaW5nIA0Kd2hhdCB3ZSBoYXZlIGJlZW4gZGV2ZWxvcGluZyBzaW5jZSB0aG9z
ZSB3aGVyZSBwcm92aWRlZCB0byBlbGltaW5hdGUgDQppbnRlcndvcmtpbmcgd2l0aCBBU09OIChz
aG91bGRuJ3QgdGhhdCBiZSBvdXIgZmlyc3QgY29tbWVudCA/KSANCg0KIk91ciBjb21tZW50cyBh
cmUgc29saWNpdGVkDQpDb29rYm9vayBvYmplY3RpdmVzIHNlZW0gdW5jbGVhciAoaWdub3JlcyBH
TVBMUyB3b3JrIG9uIFVOSSwgRU5OSSwgQVNPTikiDQoNCm8pIHlvdSB3cm90ZSAiQ2FuIHdlIGhl
bHAgYnkgZGVzY3JpYmluZyBob3cgdG8gbWFwIE9JRiBVTkkgcGFyYW1ldGVycyB0byANCkdNUExT
IHNpZ25hbGxpbmc/IiBpIGRvbid0IHVuZGVyc3RhbmQgdGhlIHF1ZXN0aW9uLCB0aGUgZm9ybWVy
IGlzIGEgDQoicHJvZmlsZSIgdGhlIGxhdHRlciBhIHByb3RvY29sIC0gc2hvdWxkbid0IGJlIHRo
ZSBvdGhlciB3YXkgYXJvdW5kDQoNCm8pIG9wdGljYWwgdHJhbnNwb3J0IHBsYW5lIHdvcmsgLSBp
IGRvbid0IGNsZWFybHkgdW5kZXJzdGFuZCB3aGF0J3MgYWxsIA0KYWJvdXQgYnV0IHRvIHRoZSBx
dWVzdGlvbiANCg0KIuKAkyAgICAgIE5vIG1lbnRpb24gb2YgR0VMUy4gVGltZSB0byBsZXQgdGhl
bSBrbm93PyIgYW5zd2VyIGlzIHllcy4gdGhlIA0KcG9pbnQgaXMgdGhhdCBzdWNoIGV4Y2hhbmdl
IGluZm9ybWF0aXZlID8NCg0KbykgU2VuZCBhIGNvbXBsZXRlIGxpc3QgYW5kIGFzayBmb3IgaXQg
dG8gYmUgaW5jbHVkZWQ/DQoNCnllcw0KDQpvKSDigKIgICAgUmVjZW50IGxpYWlzb24gKGp1c3Qg
aW4pIHJlcXVlc3RzIHVzIHRvIGxpYWlzZSANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcnN2cC10
ZS1jYWxsLTA0LnR4dCDigJxiZWZvcmUgaXQgaXMgcHVibGlzaGVkIGFzIGFuIA0KUkZD4oCdIGFu
ZCBieSBBcHJpbCAybmQgDQrigJMgICAgICAgSS1EIGlzIHBhc3QgSUVURiBsYXN0IGNhbGwuIElz
IGl0IHRvbyBsYXRlPw0KDQp0aGF0J3Mgbm90IHRoZSBxdWVzdGlvbiwgdGhlIHBvaW50IGlzIFdI
WSA/IGJlY2F1c2UgdGhlIGFwcGxpY2FiaWxpdHkgSS1EIA0KaXMgbm90IHlldCByZXNwaW5lZCA/
IHdlIHNob3VsZCBhZGRyZXNzIHRoaXMgcG9pbnQgYnkgY29tbWl0dGluZyBjaGFydGVyIA0KbWls
ZXN0b25lcyBoZXJlDQoNCm8pIHJvdXRpbmcNCg0KIkFza3MgdXMgdG8gc3VwcGx5IGRldGFpbHMg
b2Ygb3VyIHJlYXNvbmluZyBpbiBzZWxlY3RpbmcgT1NQRiBsb29wIA0KcHJldmVudGlvbiBtZWNo
YW5pc21zIHJhdGhlciB0aGFuIGFwcGx5aW5nIElTSVMgbWVjaGFuaXNtcyB0byBPU1BGDQpXZSBj
b3VsZCBzdXBwbHkgdGhpcyByZWFzb25pbmcsIGJ1dCB0byB3aGF0IHB1cnBvc2U/DQpXZSBub3Rl
IHRoYXQgd2UgcHJldmlvdXNseSBhc2tlZCBpZiB0aGUgSVRVLVQgaGFkIGFueSB0ZWNobmljYWwg
aXNzdWVzIA0Kd2l0aCBvdXIgY2hvaWNlIGFuZCByZWNlaXZlZCBubyBhbnN3ZXIuIg0KDQppc24n
dCB0aGUgYW5zd2VyIG9idmlvdXMgPw0KDQoiQXNrcyBmb3IgZnVydGhlciBleHBsYW5hdGlvbiBv
ZiB3aHkgd2UgZGVjbGluZWQgdG8gY2hhbmdlIOKAnGFuIExpIG1heSBiZSANCmFkdmVydGlzZWQg
Ynkgb25seSBvbmUgUmkgYXQgYW55IHRpbWXigJ0gdG8g4oCcYSBURSBsaW5rIGlzIG9ubHkgYWR2
ZXJ0aXNlZCBieSANCm9uZSBSaSBhdCBhIHRpbWUu4oCdIg0KDQppJ2QgbGlrZSB0byByZS1zdGF0
ZSB0aGF0IHRoZSBSRkMgNDY1MiAoaW4gaXRzIGRyYWZ0IHZlcnNpb24pIG1haW50YWluZWQgDQph
biBvcGVuIGl0ZW0gb24gbXVsdGlwbGUgUmkgcGVyIExpIC0gbm8gYW5zd2VyLCBoZW5jZSBjbG9z
ZWQgdG8gcmUtb3BlbiANCnBscyBwcm92aWRlIHJlYXNvbmluZyAoaW50ZXJlc3QgYXJndW1lbnQg
aXMgYSBjb25zZXF1ZW5jZSBub3QgYSBjYXVzZSkNCg0KIlJlc3RhdGVzIHRoYXQgd2Ugc2hvdWxk
IHVzZSDigJxNVVNU4oCdIG5vdCDigJxvcHRpb25hbOKAnSBpbiBkZXNjcmliaW5nIHRoZSANCmlu
Y2x1c2lvbiBvZiB0aW1lc2xvdCBhY2NvdW50aW5nIGluZm9ybWF0aW9uIChzZWN0aW9uIDQuMikN
ClRoaXMgc2VlbXMgdG8gYmUgYSBtaXN1bmRlcnN0YW5kaW5nIG9mIGNvbnRleHQNCk5ldyByZXZp
c2lvbiBvZiBJLUQgY2xhcmlmaWVzIHRoZSB0ZXh0DQpXZSBjYW4gbGlhaXNlIGJhY2sgdG8gdGhh
bmsgdGhlbSBmb3IgcHJvbXB0aW5nIHVzIHRvIGNsYXJpZnkiDQoNCm9rDQoNCiJSZXF1ZXN0IGxp
YWlzb24gb2YgYW55IHdvcmsgb24gbXVsdGktbGF5ZXIgbmV0d29ya3MNCldlIHNob3VsZCBkbyB0
aGlzIGVzcGVjaWFsbHkgZm9yIHRoZSBNTE4gcmVxdWlyZW1lbnRzIGFuZCBldmFsdWF0aW9uIHRo
YXQgDQphcmUgc29vbiB0byBoYXZlIGxhc3QgY2FsbA0KVmVyeSBtYW55IG9mIG91ciBJLURzIGFu
ZCBzb21lIGluIFBDRSBhcmUgYXBwbGljYWJsZSB0byBtdWx0aS1sYXllciANCm5ldHdvcmtzLiBM
aWFpc2UgdGhlbSBhbGw/Ig0KDQphdCBsZWFzdCB0aG9zZSBvbiBjb250cm9sIHBsYW5lIGF0IGZv
ciB0aGUgbGF5ZXJzIHRoYXQgY29uY2VybiBJVFUgbWVhbmluZyANClNESCAmIE9USCwgZm9yIHRo
ZSBQQ0UgYXNrIHRvIFBDRSwgYnV0IHdoYXQgaXMgdGhlaXIgcmVhbCBjb25jZXJuID8NCg0KIlNl
dCByZXNwb25kLWJ5IGRhdGUgdG8gY29pbmNpZGUgd2l0aCBlbmQgb2YgV0cgbGFzdCBjYWxsPw0K
UmVxdWVzdCBleHBsYW5hdGlvbiBvZiBob3cgcmVkaXN0cmlidXRpb24gb2YgaW5mb3JtYXRpb24g
Y29udGludWVzIHdoZW4gYSANCnJlZGlzdHJpYnV0aW9uIHBvaW50IGZhaWxzDQpTaW1wbHkgc2Vu
ZCBhbiBleHBsYW5hdGlvbj8iDQoNCmRvbmUNCg0KbykgY2FsbCBpLWQNCg0Kbm8sIGkgdGhpbmsg
d2UncmUgZG9uZQ0KDQpub3RlIGkgb2JzZXJ2ZSB0aGF0IHRoZSBsaXN0IG9mIGRpc2N1c3Npb24g
cG9pbnRzIGlzIHF1aXRlIGxhcmdlIG1vc3Qgb2YgDQp0aG9zZSBhcmUgbm9uLWlzc3VlcyB3ZSBz
aG91bGQgYXNrIGZvciBzcGxpdHRpbmcgcmVhbCBjb25jZXJucyBmcm9tIA0KaW5mb3JtYXRpb25h
bCBhc3BlY3RzDQoNCnRoYW5rcywNCi1kLg0KDQoNCg0KDQoNCiJBZHJpYW4gRmFycmVsIiA8YWRy
aWFuQG9sZGRvZy5jby51az4NClNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0KMjAv
MDMvMjAwNyAxNjozOQ0KUGxlYXNlIHJlc3BvbmQgdG8gIkFkcmlhbiBGYXJyZWwiDQogDQogICAg
ICAgIFRvOiAgICAgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCiAgICAgICAgY2M6IA0KICAgICAgICBT
dWJqZWN0OiAgICAgICAgUHJvZ3Jlc3NpbmcgdGhlIGRpc2N1c3Npb24gb24gbGlhaXNvbiByZXNw
b25zZXMNCg0KDQpIaSwNCg0KV291bGQgYXBwcmVjaWF0ZSBpdCBpZiB5b3UgbG9va2VkIGF0IHRo
ZSB2YXJpb3VzIGxpYWlzb25zIGFuZCANCmNvcnJlc3BvbmRlbmNlIA0KYXQgd3d3Lm9sZGRvZy5j
by51ay9jY2FtcC5odG0gYW5kIHRoZSBzbGlkZXMgRGVib3JhaCBhbmQgSSB3cm90ZSBhdCANCmh0
dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3bWFyL3NsaWRlcy9jY2FtcC0xOS5wcHQN
Cg0KUGxlYXNlIGNvbW1lbnQgb24gYW55IGFzcGVjdCBvZiBhbnkgb2YgdGhlIGNvcnJlc3BvbmRl
bmNlIGFzIERlYm9yYWggYW5kIEkgDQoNCnRyeSB0byBwdXQgdG9nZXRoZXIgcmVzcG9uc2VzLiBX
b3VsZCBiZSBuaWNlIGlmIHlvdXIgY29tbWVudHMgd2VyZSBvbiB0aGUgDQpDQ0FNUCBsaXN0IHJh
dGhlciB0aGFuIGluIHByaXZhdGUuDQoNClRoYW5rcywNCkFkcmlhbiANCg0KDQoNCg0KDQo=



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Mar 2007 17:33:29 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Mach Chen <[e-mail]>, [e-mail]
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
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 <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=510; t=1174411889; x=1175275889; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20Re=3A=20My=20comments=20about=20draft-chen-ccamp-ospf-interas -te-extension-01.txt |Sender:=20 |To:=20zhangrenhai=2018605=20<[e-mail]>; bh=d9pyAIUsn8ieL3ee5IIgqwq4l92xjQePrK1bj9DVVmo=; b=a39piHjWa67S7demJJv/9kXxdYHa0qYW0W2H8EvhmdmiTTlSB7mlINm45K+2qz2HF2STb4PE EWSrOvAwRH04r2XooorzG0ZQGy7y/G0Clojo+jgpDnjwCNCp2dvhB/wh;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

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



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Mar 2007 16:33:46 +0000
Date: Wed, 21 Mar 2007 00:25:31 +0800
From: zhangrenhai 18605 <[e-mail]>
Subject: Re:My comments about draft-chen-ccamp-ospf-interas-te-extension-01.txt
To: JP Vasseur <[e-mail]>
Cc: Mach Chen <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Content-disposition: inline

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




Envelope-to: [e-mail]
Delivery-date: Tue, 20 Mar 2007 15:39:56 +0000
Message-ID: <00b401c76b05$edcfde20$ea138182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Progressing the discussion on liaison responses
Date: Tue, 20 Mar 2007 15:39:11 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Tue, 20 Mar 2007 15:37:31 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
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 <[e-mail]>, Zhang Renhai <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=253; t=1174404876; x=1175268876; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20My=20comments=20about=20draft-chen-ccamp-ospf-interas-te-exte nsion-01.txt |Sender:=20; bh=LCjxVUttc0Zj/EBkl9C4Ove5R/81ZVfCsEqLUhrHTJU=; b=dbWLZmy/QBW4MfDqDtpqszcr0nKLWug4cMLncb4KFN3S373Fej8LagD/mGBcElgoE+DYBrHE ftncjiY+sGCZJEdDt65Yd7vXeix7YoGwG9TGqrZMbDd087OpSFRHlbm6;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );

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.



Envelope-to: [e-mail]
Delivery-date: Mon, 19 Mar 2007 14:11:16 +0000
Message-ID: <047501c76a30$261f2be0$0400010a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit

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 





Envelope-to: [e-mail]
Delivery-date: Mon, 19 Mar 2007 14:11:08 +0000
Message-ID: <047401c76a30$25ef9060$0400010a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit

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 





Envelope-to: [e-mail]
Delivery-date: Mon, 19 Mar 2007 01:31:26 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
Date: Sun, 18 Mar 2007 21:28:42 -0400
Message-ID: <[e-mail]>
Thread-Topic: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
thread-index: AcdhGKiQbRcfK8vLRvqqzdcmiwKIGQIl0Sdg
From: "Zafar Ali \(zali\)" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jean Philippe Vasseur \(jvasseur\)" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4491; t=1174267731; x=1175131731; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20<[e-mail]> |Subject:=20RE=3A=20Next=20steps=20for=20draft-ietf-ccamp-mpls-graceful-s hutdown-01.txt.... |Sender:=20 |To:=20<[e-mail]>; bh=+Ar5Tpzogh8pf8e5GdXOrJcoN6VwmgNGnkzzHnhIKYw=; b=Id2sRJbR/3u8c7k3M69yD+Rdy6vG+hWvhmbnSE7ApK2AeKCD8oWPTXBxHp4L77Y6ctnSyOve 7Y5Uxei1R3OxETsPMhr3bQy6cC705d4JFbL+blApCoJU735dso1vEkMK;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; );

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: [e-mail]=20
> [mailto:[e-mail]]=20
> Sent: Wednesday, March 07, 2007 7:28 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); [e-mail];=20
> Brungard, Deborah A, ALABS; Jean Philippe Vasseur (jvasseur);=20
> [e-mail]
> 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\)" <[e-mail]>
> Sent by: [e-mail]
> 02/03/2007 00:41
> =20
>         To:     "Adrian Farrel" <[e-mail]>,=20
> "Brungard, Deborah=20
> A, ALABS" <[e-mail]>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[e-mail]>, "Jean Philippe Vasseur=20
> \(jvasseur\)"=20
> <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>
>         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: [e-mail]
Delivery-date: Sun, 18 Mar 2007 09:19:19 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Crankback Signaling Extensions for  MPLS and GMPLS RSVP-TE' to Proposed Standard 
Message-Id: <[e-mail]>
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.
   ===




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Mar 2007 16:27:18 +0000
Mime-Version: 1.0 (Apple Message framework v624)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: [e-mail]
From: OGAKI Kenichi <[e-mail]>
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




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Mar 2007 23:19:22 +0000
Message-ID: <008b01c76757$ff6e68b0$0400010a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Don't forget to send me your slides!
Date: Thu, 15 Mar 2007 23:12:48 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: [e-mail]
Delivery-date: Mon, 12 Mar 2007 21:24:08 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Routing extensions for discovery of  Multiprotocol (MPLS) Label Switch Router (LSR) Traffic  Engineering (TE) mesh membership' to Proposed Standard 
Message-Id: <[e-mail]>
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.




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Mar 2007 19:52:14 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt 
Message-Id: <[e-mail]>
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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Mar 2007 10:05:44 +0000
Date: Mon, 12 Mar 2007 18:03:12 +0800
From: "gyzhang" <[e-mail]>
To: "ccamp" <[e-mail]>
Subject: A new draft draft-xie-ccamp-lsp-dppm-00.txt -- brif background
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Message-Id: <[e-mail]>

SGkgYWxsLA0KDQpBIG5ldyBkcmFmdCBkcmFmdC14aWUtY2NhbXAtbHNwLWRwcG0tMDAudHh0IHdh
cyBwb3N0ZWQgcmVjZW50bHkgb24gSUVURiB3ZWJzaXRlDQpodHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC14aWUtY2NhbXAtbHNwLWRwcG0tMDAudHh0LiANCg0KVGhhbmtz
IHRvIHRoZSBjaGFpcm1hbiwgd2UgaGF2ZSBiZSBhbGxvY2F0ZWQgYSB0aW1lc2xvdCB0byBleHBs
YWluIGFuZCBkaXNjdXNzIHRoaXMgZHJhZnQgb24gdGhlIGluY29tbWluZyBQcmFndWUgTWVldGlu
Zy4gDQoNClRoZSBmb2xsb3dpbmcgYXJlIHNvbWUgYnJpZiBiYWNrZ3JvdW5kIG9mIHRoaXMgZHJh
ZnQuDQoNCk91ciBtb3RpdmF0aW9uIG9mIHdyaXRpbmcgdGhpcyBkcmFmdCBvcmlnaW5hdGVzIGZy
b20gb3VyIGludm9sdmVtZW50IGluDQpidWlsZGluZyBhbmQgdGVzdGluZyBhIEdNUExTIG5ldHdv
cmsgaW4gRWFzdGVybiBDaGluYSAobmFtZWQgM1ROZXQpLiANCk9uZSBtYWpvciBmZWF0dXJlIHRo
YXQgM1ROZXQgcHJvdmlkZXMgaXMgdGhlIGR5bmFtaWMgYW5kIGF1dG9tYXRlZA0KcHJvdmlzaW9u
aW5nIG9mIGVuZC10by1lbmQgRXRoZXJuZXQgY29ubmVjdGlvbnMgdG8gbWVkaWEgc2VydmVyIGFu
ZCBJUFRWDQpoZWFkLWVuZHMuIEEgZmluZWx5IHR1bmVkIGNvbm5lY3Rpb24gc2NoZWR1bGluZyBt
b2RlbCBpcyBpbmNvcnBvcmF0ZWQgaW50bw0KdGhlIHNlcnZpY2UgcGxhdGZvcm0gYW5kIGluIHRo
aXMgd2F5LCBjb250ZW50IGRpc3RyaWJ1dGlvbiBhbmQgc3RyZWFtaW5nDQpzZXJ2aWNlcyBhbGlr
ZSBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YgZHluYW1pYyBlbmQtdG8tZW5kIEV0aGVybmV0DQpjb25u
ZWN0aW9ucy4gVGhlIDNUTmV0IGNvbnNvcnRpdW0gaGFzIGRlZmluZWQgYSBzZXQgb2YgbWV0cmlj
cw0KY2hhcmFjdGVyaXppbmcgdGhlIHByb3Zpc2lvbmluZyBkZWxheSBhbmQgdmFyaWFuY2UsIHNv
IHRoYXQgdGhlIHNlcnZpY2UNCnJlcXVpcmVtZW50cyBhbmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxp
dHkgY2FuIGJlIG1hcHBlZCB0byBlYWNoIG90aGVyLiANCg0KQXMgdGhlIGludGVyZXN0IGZvciBk
eW5hbWljYWxseSBwcm92aXNpb25lZCBjb25uZWN0aW9ucyBhcmUgaW5jcmVhc2luZyBpbg0KdGhl
IGNvbW11bml0eSwgd2UgcHJvcG9zZSB0byBzdGFuZGFyZGl6ZSB0aG9zZSBtZXRyaWNzLCBhcyBo
YXMgYmVlbiBkb25lIGZvcg0KSVAuIA0KT3VyIHByb3Bvc2FsIHJlY2VpdmVkIHZlcnkgcG9zaXRp
dmUgcmVzcG9uc2VzIGluIHRoZSAzVE5ldCBjb25zb3J0aXVtLCBzbyB3ZQ0Kc3RhcnRlZCB0byBw
cmVwYXJlIHRoZSBkcmFmdCBpbiBTZXB0LiAyMDA2LiBJdCBoYXMgdW5kZXJnb25lIGEgc2VyaWVz
IG9mDQpyZXZpc2lvbnMgYmVmb3JlIHN1Ym1pdHRlZCB0byBJRVRGLCB0aGFua3MgdG8gdGhlIGNv
bnRyaWJ1dGlvbnMgb2YgYXV0aG9ycw0KZnJvbSB0ZXN0aW5nIGF1dGhvcml0aWVzLCB0ZXN0aW5n
IGVxdWlwbWVudCBhbmQgbmV0d29yayBkZXZpY2UgdmVuZG9ycy4NCg0KU29tZSBvZiB0aGVzZSBt
ZXRyaWNzIGhhcyBiZWVuIGFkb3B0ZWQgaW4gdGhlIEFTT04gdGVzdGluZyBzdGFuZGFyZCBvZiBD
aGluYSwgYW5kIHdpZGVseSB1c2VkIGluIHRoZSB0ZXN0aW5nIHByb2plY3RzIG9mIENoaW5hIENh
cnJpZXJzLg0KIA0KDQpUaGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQgaG9wZSB0byBnZXQgZmVlZGJh
Y2tzIGFuZCBzdWdnZXN0aW9ucyBmcm9tIHRoZSBncm91cC4NCg0KQmVzdCByZWdhcmRzLA0KDQog
ICBHdW95aW5nIFpoYW5nDQogICBDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFJl
c2VhcmNoLE1JSS4NCiAgIEJlaWppbmcgIDIwMDI0MA0KICAgQ04NCg0KICAgUGhvbmU6ICs4NiAx
MDY4MDk0MjcyDQogICBFbWFpbDogemhhbmdndW95aW5nQG1haWwucml0dC5jb20uY24NCg0KoaEy
MDA3LTAzLTEyDQo=




Envelope-to: [e-mail]
Delivery-date: Sat, 10 Mar 2007 21:29:04 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SSPni71BvW0FC/NxnBmqDr2VTHq6df1aOeFVYX92QVz1xPtQCTQN+XMz/p6KKaVmBd7fcwnxodtkPNwEuLn5h1tzo6K+flzQohcG/aqMnNDMwlNt50pt8kz6D0DOCfbyKTwBFHa82W0PnAd5Rlty/NZtxI+6oc7ZzNcXtxy0uQU=;
Date: Sat, 10 Mar 2007 13:26:23 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-611198405-1173561983=:91906"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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

[e-mail] 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:     [e-mail], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[e-mail]
        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

[e-mail] 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: [e-mail], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[e-mail]
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?

[e-mail] 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: [e-mail]
09/03/2007 20:29

To: "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail], "Brungard, Deborah A, ALABS" 
, [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf 


Of [e-mail]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [e-mail]; Brungard, Deborah A, ALABS; 
[e-mail]
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: [e-mail]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail], "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: [e-mail], "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.

[e-mail] 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: [e-mail], "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>[e-mail]</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 <[e-mail]><br>10/03/2007 14:10<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail], "Brungard, Deborah A, ALABS" <br><[e-mail]>, "Ong, Lyndon" <[e-mail]>, <br>[e-mail]<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>[e-mail] 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: [e-mail], "Brungard, Deborah A, ALABS" <br>, "Ong, Lyndon" , <br>[e-mail]<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>[e-mail] 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: [e-mail]<br>09/03/2007 20:29<br><br>To: "Ong, Lyndon" , Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [e-mail], "Brungard, Deborah A, ALABS" <br>, [e-mail]<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: [e-mail] [mailto:[e-mail]] On Behalf <br><br><br>Of [e-mail]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [e-mail]; Brungard, Deborah A, ALABS; <br>[e-mail]<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: [e-mail]<br>09/03/2007 16:05<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [e-mail], "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: [e-mail], "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>[e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sat, 10 Mar 2007 13:44:44 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 10 Mar 2007 14:44:01 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvciANCg0KdGhlIGZpcnN0IHNlbnRlbmNlIGlzIHRoZSBkaXNjb25uZWN0LCBwZXIgMzYzMCAN
Cg0KIlRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1hbmRhdG9yeSwgaS5l
LiwgbXVzdCBhcHBlYXIgDQpleGFjdGx5IG9uY2UuIg0KDQoiIFRoZSBMaW5rIElEIHN1Yi1UTFYg
aWRlbnRpZmllcyB0aGUgb3RoZXIgZW5kIG9mIHRoZSBsaW5rLiAgRm9yDQogIHBvaW50LXRvLXBv
aW50IGxpbmtzLCB0aGlzIGlzIHRoZSBSb3V0ZXIgSUQgb2YgdGhlIG5laWdoYm9yLiINCg0KDQp5
b3Ugd3JvdGUNCg0KIlRFIGxpbmtzIG11c3QgYmUgdW5pcWVseSBpZGVudGlmZWQgZWl0aGVyIGFz
IG51bWJlcmVkIG9yIHVubnVtYmVyZWQgDQooY29tYmluYXRpb24gb2YgVEVSdHJJRCBhbmQgTGlu
a0lEKS4iDQoNCnRoaXMgaXMgdG90YWxseSBpbmNvcnJlY3QsIHRoZXJlIGlzIGEgbG9jYWwvcmVt
b3RlIHN1Yi1UTFYgZGVmaW5lZCBmb3IgDQpudW1iZXJlZCBURSBsaW5rcw0KDQppbiBmYWN0IHdo
YXQgdGhlIHByZXNlbnQgZG9jdW1lbnQgZG9lcyBpcyB0byBkZWZpbmUgYSBzdWItVExWIHRvIGFs
bG93IA0KaWRlbnRpZmljYXRpb24gb2YgdW5udW1iZXJlZCBURSBsaW5rcyAoYXNzb2NpYXRlZCB0
byB0aGUgVEUgcm91dGVyIElEIA0KcmF0aGVyIHRoYW4gdGhlIFJvdXRlciBJRCkNCg0KDQp0aGFu
a3MsDQotZC4NCg0KDQogDQoNCg0KDQoNCklnb3IgQnJ5c2tpbiA8aV9icnlza2luQHlhaG9vLmNv
bT4NCjEwLzAzLzIwMDcgMTQ6MTANCiANCiAgICAgICAgVG86ICAgICBEaW1pdHJpIFBBUEFESU1J
VFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMDQogICAgICAgIGNjOiAgICAgY2NhbXBAb3BzLmlldGYu
b3JnLCAiQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMiIA0KPGRicnVuZ2FyZEBhdHQuY29tPiwg
Ik9uZywgTHluZG9uIiA8THlvbmdAQ2llbmEuY29tPiwgDQpvd25lci1jY2FtcEBvcHMuaWV0Zi5v
cmcNCiAgICAgICAgU3ViamVjdDogICAgICAgIFJFOiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQt
aWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3NwZg0KDQoNCkRpbWl0cmksDQoNCkJ1dCB3
aG8gc2FpZCB0aGF0IGxpbmtJRCBtdXN0IGJlIHVuaXF1ZSBwZXIgcm91dGVySUQ/IE9mIGNvdXJz
ZSwgbm90LiBJdCANCm11c3QgYmUgdW5pcXVlIHBlciBURSBSb3V0ZXIgSUQuIFRoZSBmYWN0IHRo
YXQgdGhlIHNhbWUgUkMgbWFuYWdlcyBzZXZlcmFsIA0KVEUgUlRScyBkb2VzIG5vdCBjaGFuZ2Ug
YSB0aGluZy4gVGhlIHBhdGhzIGFyZSBjb21wdXRlZCBvbiB0aGUgbmV0d29yayBURSANCmdyYXBo
LCBidWlsdCBvZiB2ZXJ0aWNlcyAoVEUgUlRScykgaW50ZXJjb25uZWN0ZWQgYnkgZWRnZXMgKFRF
IGxpbmtzKS4gVEUgDQpsaW5rcyBtdXN0IGJlIHVuaXFlbHkgaWRlbnRpZmVkIGVpdGhlciBhcyBu
dW1iZXJlZCBvciB1bm51bWJlcmVkIA0KKGNvbWJpbmF0aW9uIG9mIFRFUnRySUQgYW5kIExpbmtJ
RCkuIEhvdyB0aGUgbGlua3MgYXJlIGFkdmVydGlzZWQgLSBieSANCnNlcGFyYXRlIFJDcywgdGhl
IHNhbWUgUkMgb3IgdmlhIG5vIFJDIChzdGF0aWNhbGx5IGNvbmZpZ3VyZWQpIC0gaXMgb2Ygbm8g
DQppbXBvcnRhbmNlLg0KDQpJZ29yDQoNCkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLWx1
Y2VudC5iZSB3cm90ZToNCmlnb3INCg0Kbm90IGFuIGlzc3VlIG9mIFRFIHJvdXRlciBJRCB1bmlx
dWVuZXNzLCB3aXRob3V0IHRoaXMgYWRkaXRpb25hbCBzdWItVExWLCANCmFuIHVubnVtYmVyZWQg
bG9jYWwgaWQgbWF5IG5vdCBiZSB1bmlxdWUgcGVyIHJvdXRlcl9pZCwgaGVuY2UgdGhlIGFkZGl0
aW9uIA0KDQpvZiB0aGlzIHN1Yi1UTFYgKFRFIFJvdXRlciBJRCBiZWluZyB1bmlxdWUgcGVyIHJv
dXRlcl9pZCkgDQoNCi1kDQoNCg0KDQoNCg0KSWdvciBCcnlza2luIA0KMDkvMDMvMjAwNyAyMjoz
Ng0KDQpUbzogRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KY2M6IGNj
YW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTIiANCiwgIk9uZywg
THluZG9uIiAsIA0Kb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogVHdvIHF1
ZXN0aW9ucyBvbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLW9zcGYNCg0K
DQpEaW1pdHJpLA0KDQpJIGRvbid0IHNlZSBob3cgd2UgY2FuIG1hbmFnZSB0aGUgc2l0dWF0aW9u
IHdoZXJlIFRFTm9kZUlkcyBhcmUgbm90IA0KdW5pcXVlLiBBdCB0aGUgZW5kIG9mIHRoZSBkYXkg
d2UgbXVzdCBwcm9jZXNzIEVST3MvUlJPcyB0aGF0IGFyZSBidWlsZA0Kb2YgVEVOb2RlSUQvVEVM
aW5rSUQgcGFpcnMuIElmIFRFTGlua0lEIGhhcyBub2RlLXNjb3BlIGFuZCBURU5vZGVJRCBpcyBu
b3QgDQoNCnVuaXF1ZSwgaG93IHRoZW4gd2UgY2FuIGlkZW50aWZ5IHRoZSBzcGVjaWZpZWQgbGlu
az8gU28gd2hhdCBkbyB5b3UgDQpzdWdnZXN0IHdlIHB1dCBpbiBlYWNoIG9mIHRoZXNlIHR3byBm
aWVsZHM/DQoNCkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLWx1Y2VudC5iZSB3cm90ZToN
Cmlnb3IgDQoNCmJ1dCBpdCBkb2Vzbid0IHNvbHZlIHRoZSBpc3N1ZSAoYW5kIGludHJvZHVjZXMg
ZGlmZmVyZW50IHNldHRpbmcgYW5kIA0KcHJvY2Vzc2luZyBvZiB0aGUgbGluayBpZCB2YWx1ZSBm
cm9tIHJmYyAzNjMwKSBpbmRlZWQsIGluIEFTT04gUkMgY2FuIGJlIA0KYXNzb2NpYXRlZCB0byBt
dWx0aXBsZSAibm9kZXMiLCBlYWNoIG9mIHRoZXNlIG5vZGVzIGNhbiBoYXZlIG92ZXJsYXBwaW5n
IA0KaWQgc3BhY2VzICh0byBpZGVudGlmeSB0aGUgImxpbmtzIikgDQoNCmZvciB0aGF0IHJlYXNv
biB0aGUgc29sdXRpb24gaXMgdGhhdCBlYWNoIFRFIGxpbmsgKHRvcCBsZXZlbCkgVExWIGhhcyBh
IA0KbmV3IHN1Yi1UTFYgdGhhdCBhc3NvY2lhdGVzIHRoZSBsb2NhbCBhbmQgcmVtb3RlICJub2Rl
IGlkIiAodGhlIGZvcm1lciBhbmQgDQoNCg0KbGF0dGVyIHRha2VzIHRoZSBURSBSb3V0ZXIgSUQg
YXMgdmFsdWUpDQoNCml0IGlzIHRoZSBzdWJzdGFuY2Ugb2Ygd2hhdCBpIGhhdmUgYmVlbiBwb2lu
dGluZyB0byB5b3UgaW4gbXkgaW5pdGlhbCANCmUtbWFpbCAoc2VlIFNlY3Rpb24gNS4yIGJ1dCBh
bHNvIGluIFJGQyA0NjUyIFNlY3Rpb24gNS43OiAidGhlIHJvdXRpbmcgDQpwcm90b2NvbCBNVVNU
IGJlIGFibGUgdG8gZGlzYW1iaWd1YXRlIHRoZSBhZHZlcnRpc2VkIFRFIGxpbmtzIHNvIHRoYXQg
dGhleSANCg0KDQpjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb3JyZWN0IFRFIFJvdXRlciBJ
RC4iKQ0KDQotZC4NCg0KDQoNCg0KDQoNCg0KSWdvciBCcnlza2luIA0KU2VudCBieTogb3duZXIt
Y2NhbXBAb3BzLmlldGYub3JnDQowOS8wMy8yMDA3IDIwOjI5DQoNClRvOiAiT25nLCBMeW5kb24i
ICwgRGltaXRyaSANClBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMDQpjYzogY2NhbXBA
b3BzLmlldGYub3JnLCAiQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMiIA0KLCBvd25lci1jY2Ft
cEBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3NwZg0KDQoNCkx5bmRvbiwNCg0KTGV0IG1lIHRy
eSB0byBleHBsYWluIG15IHBvaW50LiANCg0KQmFzaWNhbGx5LCB3ZSBoYXZlIHR3byBzb2x1dGlv
bnMgdG8gYWRkcmVzcyB0aGUgc2l0dWF0aW9uIHdoZW4gdGhlIA0KcmVsYXRpb25zaGlwIGJldHdl
ZW4gYSByb3V0ZXIgY29udHJvbGxlciBhbmQgZGF0YSBwbGFuZSBzd2l0Y2hlcyAoVEUgbm9kZXMg
DQoNCg0Kb3IgVEUgcm91dGVycykgYXJlIDE6TiwgdGhhdCBpcywgd2hlbiBhIHNpbmdsZSBjb250
cm9sbGVyIG1hbmFnZXMgbXVsdGlwbGUgDQoNCg0KVEUgcm91dGVycy4NCg0KU29sdXRpb24gMSAo
c3VnZ2VzdGVkIGluIHRoZSBkcmFmdCk6DQoNCkVhY2ggVEUgTGluayBhZHZlcnRpc2luZyBpcyBl
eHRlbmRlZCB3aXRoIExvY2FsL1JlbW90ZSBURSBSb3V0ZXIgSURzIHBhaXIuIA0KDQoNCkluIHRo
aXMgY2FzZSwgd2hhdCBpcyBpbiB0aGUgTGlua0lEIHN1Yi1UTFYgaXMgbm90IGltcG9ydGFudCBy
ZWFsbHkuDQoNClNvbHV0aW9uIDIgKG1pbmUpDQoNClRoZSBSb3V0ZXIgQWRkcmVzcyBUTFYgaXMg
ZXh0ZW5kZWQgdG8gYWR2ZXJ0aXNlIGFsbCBURSBSb3V0ZXIgSURzIA0KY29udHJvbGxlZCBieSB0
aGUgYWR2ZXJ0aXNpbmcgY29udHJvbGxlciBhcyByb3V0YWJsZSBhZGRyZXNzZXMuIFRoZSBURSAN
CkxpbmsgVExWIGlzIGV4dGVuZGVkIHRvIGFkdmVydGlzZSB0aGUgbG9jYWwgVEUgUm91dGVyIElE
LiBIb3dldmVyLCB0aGVyZSANCmlzIG5vIG5lZWQgdG8gYWR2ZXJ0aXNlIHRoZSByZW1vdGUgVEUg
Um91dGVyIElELCBiZWNhdXNlIHRoaXMgaXMgdGhlIA0KZnVuY3Rpb24gb2YgdGhlIGV4aXN0aW5n
IExpbmtJRCBzdWItVExWLCB3aGljaCBpcyB0byBpZGVudGlmeSB0aGUgcmVtb3RlIA0KZW5kIG9m
IHRoZSBhZHZlcnRpc2VkIFRFIGxpbmsgw4PCosOi4oCawqzDouKCrMWTIHJlbW90ZSBURSBSb3V0
ZXIgSUQuDQoNCkJvdGggdGhlc2UgYXBwcm9hY2hlcyBzb2x2ZSB0aGUgcHJvYmxlbTsgaG93ZXZl
ciwgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIHRvIA0KDQoNCmFuc3dlciBpczoNCg0KRG8gd2UgbmVl
ZCB0aGUgVEUgUm91dGVyIElEcyB0byBiZSByb3V0YWJsZSBhZGRyZXNzZXM/DQoNClRoZSBhbnN3
ZXIgaXMgWUVTIGFjY29yZGluZyB0byBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFkZHJlc3Npbmct
MDUudHh0LiANCkZvciBleGFtcGxlLCBpZiB0aGUgbmV0d29yaw0KaXMgYnVpbHQgb2YgdW5udW1i
ZXJlZCBURSBsaW5rcywgdGhhbiBFUk8gc2lnbmFsZWQgaW4gUlNWUC1URSBQYXRoIHdpbGwgDQpj
b250YWluDQpwYXRoIGluIGEgZm9ybSBvZiBURV9SdHJJRC9pZkluZGV4IHBhaXJzLCBhbmQgaGF2
aW5nIFRFX1J0cklEIHJvdXRhYmxlIA0Kc29sdmVzIHRoZSBwcm9ibGVtIGhvdyB0byBzaWduYWwg
dGhlIFBhdGggbWVzc2FnZSBhbG9uZyB0aGUgcHJvdmlzaW9uZWQgDQpwYXRoLi4NCklmIHlvdSBh
Z3JlZSB3aXRoIHRoaXMsIHRoYW4geW91IHdpbGwgYWxzbyBhZ3JlZSB0aGF0IGFsbCBURSBSb3V0
ZXIgSURzIA0Kc2hvdWxkIGJlIGFkdmVydGlzZWQgd2l0aGluIFJvdXRlciBBZGRyZXNzIFRMVg0K
SG9wZSB0aGF0IHRoaXMgaGVscHMuDQoNCklnb3INCg0KDQoNCg0KIk9uZywgTHluZG9uIiB3cm90
ZToNCkhpIERpbWl0cmksDQoNClRoYXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgYWxzbywgSSBkb24n
dCBzZWUgYW55IGlzc3VlIHdpdGggdGhpcy4NCg0KQ2hlZXJzLA0KDQpMeW5kb24gDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21h
aWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiANCg0KDQpPZiBEaW1pdHJp
LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuYmUNClNlbnQ6IEZyaWRheSwgTWFyY2ggMDks
IDIwMDcgNzo1NiBBTQ0KVG86IElnb3IgQnJ5c2tpbg0KQ2M6IGNjYW1wQG9wcy5pZXRmLm9yZzsg
QnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlM7IA0Kb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQpT
dWJqZWN0OiBUd28gcXVlc3Rpb25zIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0
aW5nLW9zcGYgDQoNCmlnb3INCg0KdGhlIGRyYWZ0cyBzYXlzDQoNCiJOb3RlOiBUaGUgTGluayBJ
RCBzdWItVExWIHRoYXQgaWRlbnRpZmllcyB0aGUgb3RoZXIgZW5kIG9mIHRoZSBsaW5rIChpLmUu
IA0KDQoNCg0KUm91dGVyIElEIG9mIHRoZSBuZWlnaGJvciBmb3IgcG9pbnQtdG8tcG9pbnQgbGlu
a3MpIE1VU1QgYXBwZWFyIGV4YWN0bHkgDQpvbmNlIHBlciBMaW5rIFRMVi4gVGhpcyBzdWItVExW
IE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGRlZmluZWQgaW4gW1JGQzM2MzBdLiANCg0KDQoNCiIgDQoN
CndoaWNoIGlzIGV4YWN0bHkgd2hhdCB5b3UgYXJlIHNheWluZyAtIHdoZW4gaSBzYXkgIml0IGlk
ZW50aWZpZXMgdGhlIA0KcmVtb3RlIFJDIG5vdCB0aGUgcmVtb3RlIGRhdGEgcGxhbmUgIm5vZGUi
IGluIGNhc2UgdGhlIHJlbW90ZSBSQyBpcyANCmFzc29jaWF0ZSB0byBuIG5vZGVzIiByZWFkICJp
dCBpcyBzZXQgdG8gdGhlIHJvdXRlcl9pZCB0aGF0IGlkZW50aWZpZXMgdGhlIA0KDQoNCnJlbW90
ZSBSQy4uLiINCmluIGJyaWVmLCB3ZSBrZWVwIHRoZSBzZW1hbnRpYyBhbmQgYWRkIGEgZGlzY3Jp
bWluYXRvciAodGhhdCBkb2VzIG5vdCANCmFwcGx5IGluIGNhc2Ugb2YgY29sb2NhdGVkIDE6MSBM
U1IpIC0gdGhpcyBjbG9zZXMgdGhlIGZpcnN0IHBvaW50IC0NCg0KY29uY2VybmluZyB0aGUgc2Vj
b25kIHBvaW50LCBzaW5jZSB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IHRvIGhhdmUgbXVsdGlwbGUg
DQoNCg0KYXNzb2NpYXRpb25zIGluIGRpZmZlcmVudCBMU0FzIGkgZG9uJ3Qgd2hlcmUgdGhlIHBy
b2JsZW0gaXMgPw0KDQp0aGFua3MsDQotZC4NCg0KDQoNCg0KDQpJZ29yIEJyeXNraW4gDQpTZW50
IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCjA5LzAzLzIwMDcgMTY6MDUNCg0KVG86IERp
bWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCmNjOiBjY2FtcEBvcHMuaWV0
Zi5vcmcsICJCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUyIgDQoNClN1YmplY3Q6IFJlOiBUd28g
cXVlc3Rpb25zIG9uIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3Nw
ZiBkcmFmdA0KDQoNCkRpbWl0cmksDQoNCj4gSXMgdGhlIExpbmtJRCBpcyB0aGUgc2FtZSBhcyBS
ZW1vdGUgVEUgUm91dGVyIElEPyANCg0Kbm8NCg0KPiBMaW5rSUQgdW5hbWJpZ3Vvc2x5IGlkZW50
aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUgbm9kZSwNCg0Kbm8sIGl0IGlkZW50aWZpZXMgdGhlIHJl
bW90ZSBSQyBub3QgdGhlIHJlbW90ZSBkYXRhIHBsYW5lICJub2RlIiBpbiBjYXNlIA0KdGhlIHJl
bW90ZSBSQyBpcyBhc3NvY2lhdGUgdG8gbiAibm9kZXMiDQoNCklCPj4gTm8sIEkgZGlzYWdyZWUu
IFlvdSBzZWUgdGhhdCdzIHdoeSBpdCdzIHNvIGltcG9ydGFudCB0byBxdW90ZSB0aGUNClJGQ3Mv
ZHJhZnRzLCBiZWNhdXNlIHBlb3BsZSBvZnRlbiBpbnRlcnByZXQgdGhlbSBkaWZmZXJlbnRseS4N
Cg0KSW4gUkZDIDM2MzAgd2UgcmVhZDoNCiINCjIuNS4yLiBMaW5rIElEDQoNCg0KDQpUaGUgTGlu
ayBJRCBzdWItVExWIGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0aGUgbGluay4gRm9yDQoN
CnBvaW50LXRvLXBvaW50IGxpbmtzLCB0aGlzIGlzIHRoZSBSb3V0ZXIgSUQgb2YgdGhlIG5laWdo
Ym9yLg0KDQoiDQoNCk5vdGUgdGhhdCBpdCBkb2VzIG5vdCBzYXkgd2hldGhlciB0aGlzIGlzIHRo
ZSBhZHZlcnRpc2luZyBSb3V0ZXIgSUQgDQoNCihpZGVudGlmeWluZyBuZWlnaGJvciBSQykgb3Ig
VEUgUm91dGVyIElEIChpZGVudGlmeWluZyB0aGUNCm5laWdoYm9yIFRFIG5vZGUpLiBIb3dldmVy
LCBpdCBkb2VzIHNheSB0aGF0IGl0ICJpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgDQpvZiB0aGUg
bGluayIuIEJlY2F1c2UgYSBsaW5rIGlzIHRlcm1pbmF0ZWQgYnkgVEUgbm9kZXMgKGFuZCBub3Qg
DQphZHZlcnRpc2luZyByb3V0ZXJzKSBJIGNvbmNsdWRlIHRoYXQgTGlua0lEIGlkZW50aWZpZXMg
dGhlIHJlbW90ZSBURSBub2RlLg0KDQpGdXJ0aGVybW9yZSwgZWFybGllciBpbiBSRkMgMzYzMCB3
ZSByZWFkOg0KIg0KMi40LjEuIFJvdXRlciBBZGRyZXNzIFRMVg0KDQpUaGUgUm91dGVyIEFkZHJl
c3MgVExWIHNwZWNpZmllcyBhIHN0YWJsZSBJUCBhZGRyZXNzIG9mIHRoZQ0KYWR2ZXJ0aXNpbmcg
cm91dGVyIHRoYXQgaXMgYWx3YXlzIHJlYWNoYWJsZSBpZiB0aGVyZSBpcyBhbnkNCmNvbm5lY3Rp
dml0eSB0byBpdDsgdGhpcyBpcyB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYXMgYSAibG9vcGJhY2sN
CmFkZHJlc3MiLiBUaGUga2V5IGF0dHJpYnV0ZSBpcyB0aGF0IHRoZSBhZGRyZXNzIGRvZXMgbm90
IGJlY29tZQ0KdW51c2FibGUgaWYgYW4NCmludGVyZmFjZSBpcyBkb3duLiBJbiBvdGhlciBwcm90
b2NvbHMsIHRoaXMgaXMga25vd24NCmFzIHRoZSAicm91dGVyIElEIg0KDQpJIGludGVycHJldCB0
aGF0IHRoaXMgaXMgdGhlIHNhbWUgcm91dGVyIElEIGFzIGluIHRoZSB1cHBlciBxdW90ZS4gSXQg
aXMgDQphZHZlcnRpc2VkIGluIHRoZSBSb3V0ZXIgQWRkcmVzcyBUTFYsIHdoaWNoIGlzIHRoZSBv
bmx5IHdheSB0b2RheSB0byANCmFkdmVydGlzZSBURSBSb3V0ZXIgSUQuIEhlbmNlIHRoZSByb3V0
ZXIgSUQgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBSRkMgaXMgDQp0aGUgVEUgUm91dGVyIElELg0K
DQpUaGUgY29uY2x1c2lvbiAjMTogdGhlIFRFIExpbmsgVExWLCBhcyBpdCBpcyB0b2RheSwgYWx3
YXlzIGNvbnRhaW5zIHRoZSBJRCANCg0KDQoNCm9mIHRoZSByZW1vdGUgVEUgbm9kZS4gDQoNClRo
ZSBjb25jbHVzaW9uICMyOiB0aGVyZSBpcyBhIG5lZWQgdG8gYWR2ZXJ0aXNlIHNldmVyYWwgVEUg
Um91dGVyIElEcyANCnN1cHBvcnRlZCBieSB0aGUgc2FtZSBSQyAoYWR2ZXJ0aXNpbmcgcm91dGVy
KSwgd2hpY2gsIEkgdGhpbmssIHNob3VsZCBiZSANCnByb3Bvc2VkIGluIHlvdXIgZHJhZnQNCg0K
cHM6IHNlY29uZCBxdWVzdGlvbiBpcyB0cml2aWFsLCBtYXRoZW1hdGljYWwgdnMgbmV0d29ya2lu
ZyBmb3JtdWxhdGlvbiAobm8gDQoNCg0KDQoNCnJlYWwgZGlmZmVyZW5jZSkNCg0KSUI+PiBXZWxs
LCBpdCBjaGFuZ2VzIG9uZSBvZiB0aGUgZnVuZGFtZW50YWwgZGVmaW5pdGlvbnMgb2YgRy44MDgw
LCBhbmQgSSANCmFtIGFza2luZyB3aHkgaXMgdGhhdCBpbiB0aGUgZHJhZnQgd2hpY2ggaXMgc3Vw
cG9zZWQgdG8gZGVmaW5lIHdheXMgdG8gDQpzdXBwb3J0IEcuODA4MCANCg0KSWdvcg0KDQpwcHM6
IGlmIHlvdSB3YW50IHRvIHB1dCBndWlkZWxpbmVzIG9uIGUtbWFpbCByZXNwb25zZXMgcHJvYmFi
bHkgZGlyZWN0aW5nIA0KeW91ciBlLW1haWwgdG8gdGhlIEdFTiBBUkVBIHdvdWxkIGJlIG1vcmUg
c3VpdGFibGUgDQoNCmhvcGUgdGhpcyBoZWxwcywNCi1kLg0KDQoNCg0KDQpJZ29yIEJyeXNraW4g
DQowOS8wMy8yMDA3IDAwOjAzDQoNClRvOiBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRF
TEBBTENBVEVMDQpjYzogY2NhbXBAb3BzLmlldGYub3JnLCAiQnJ1bmdhcmQsIERlYm9yYWggQSwg
QUxBQlMiIA0KDQpTdWJqZWN0OiBSZTogVHdvIHF1ZXN0aW9ucyBvbiANCmRyYWZ0LWRpbWl0cmkt
Y2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLW9zcGYgZHJhZnQNCg0KDQpEaW1pdHJpLCBubywgaXQg
ZG9lcyBub3QgaGVscC4NCg0KWW91IGRpZG4ndCBhbnN3ZXIgdGhlIGZpcnN0IHF1ZXN0aW9uLCB3
aGljaCBpczoNCg0KSXMgdGhlIExpbmtJRCBpcyB0aGUgc2FtZSBhcyBSZW1vdGUgVEUgUm91dGVy
IElEPyBJZiBubywgd2hhdCBpcyB0aGUgDQpkaWZmZXJlbmNlPyBJZiB5ZXMsIHdoeSBkbyB5b3Ug
bmVlZCB0aGUgbGF0dGVyPyBCb3RoIHlvdXIgcG9pbnRlcnMgZXhwbGFpbiANCg0KDQoNCg0Kd2h5
IGRvIHlvdSBuZWVkIGFkdmVydGlzaW5nIG9mIHRoZSBsb2NhbCBURSBSb3V0ZXIgSUQgKGFkdmVy
dGlzaW5nIHJvdXRlciANCm1heSBjb3ZlciBtdWx0aXBsZSBkYXRhIHBsYW5lIG5vZGVzKSwgSG93
ZXZlciwgTGlua0lEIHVuYW1iaWd1b3NseSANCmlkZW50aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUg
bm9kZSwgYW5kIHRoZSBuZWVkIGZvciB0aGUgYWR2ZXJ0aXNpbmcgb2YgDQpSZW1vdGUgVEUgUm91
dGVyIElEIGlzIG5vdCBvYnZpb3VzDQoNCkJUVywgWW91IGRpZG4ndCBhbnN3ZXIgdGhlIHNlY29u
ZCBxdWVzdGlvbiBlaXRoZXIuDQoNCklnb3INCg0KUFMsIEkgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9y
IHRoZSB3b3JraW5nIGdyb3VwOiBMZXQgdXMgZGlzYWxsb3cgcmVzcG9uZGluZyANCnRvIHRoZSBj
b21tZW50cy9xdWVzdGlvbnMgYnkganVzdCBwb2ludGluZyB0byBSRkNzIG9yIGRyYWZ0cy4gSW4g
bXkgdmlldyANCml0IGlzIHF1aXRlIHVuZnJpZW5kbHkuIEl0IGlzIGFsd2F5cyBwb3NzaWJsZSB0
byBjdXQgYW5kIHBhc3RlIGEgcGllY2UgDQpmcm9tIHRoZSByZWxldmFudCBSRkMgb3IgZHJhZnQg
Y29uZmlybWluZyB0aGUgcG9pbnRzIHRoZSB3cml0ZXIgaXMgdHJ5aW5nIA0KdG8gbWFrZS4NCg0K
RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwtbHVjZW50LmJlIHdyb3RlOg0KaWdvcg0KDQoN
CnBscyB1c2UgdmVyc2lvbiAob3IgMDMgDQp3aGVuIGF2YWlsYWJsZSB0byBtYWtlIGNvbW1lbnRz
KQ0KDQppbiB0aGF0IHZlcnNpb24geW91IHdpbGwgc2VlIGluIFNlY3Rpb24gNS4yDQoNCiIgTm90
ZTogVGhlIExpbmsgSUQgc3ViLVRMViB0aGF0IGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0
aGUgbGluayANCihpLmUuIFJvdXRlciBJRCBvZiB0aGUgbmVpZ2hib3IgZm9yIHBvaW50LXRvLXBv
aW50IGxpbmtzKSBNVVNUIA0KYXBwZWFyIGV4YWN0bHkgb25jZSBwZXIgTGluayBUTFYuIFRoaXMg
c3ViLVRMViBNVVNUIGJlIHByb2Nlc3NlZCBhcyANCmRlZmluZWQgaW4gW1JGQzM2MzBdLiAiDQoN
Cm5vdyB3aHkgdGhpcyBzdWItVExWIDE3LCB3ZWxsIGZvciB0aGUgcmVhc29uIGV4cGxhaW5lZCBh
dCB0aGUgYmVnaW5uaW5nIG9mIA0KDQoNCg0KDQoNCnBhci41LjINCmJ1dCBhbHNvIGluIFJGQyA0
NjUyIFNlY3Rpb24gNS43DQoNCmhvcGUgdGhpcyBoZWxwcywNCi1kLg0KDQoNCg0KDQpJZ29yIEJy
eXNraW4gDQowOC8wMy8yMDA3IDIyOjExDQoNClRvOiBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUv
QUxDQVRFTEBBTENBVEVMDQpjYzogY2NhbXBAb3BzLmlldGYub3JnLCAiQnJ1bmdhcmQsIERlYm9y
YWggQSwgQUxBQlMiIA0KDQpTdWJqZWN0OiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQtZGltaXRy
aS1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3NwZiBkcmFmdA0KDQoNCkRpbWl0cmksDQpJIGhh
dmUgYSBjb3VwbGUgcXVlc3Rpb25zIHdydCB0aGUgDQpkcmFmdC1kaW1pdHJpLWNjYW1wLWdtcGxz
LWFzb24tcm91dGluZy1vc3BmIGRyYWZ0Lg0KSW4gNS4yIGEgVEUgTGluayBzdWItVExWIGlzIGlu
dHJvZHVjZWQgZm9yIHRoZSBwdXJwb3NlIG9mIGFkdmVydGlzaW5nIA0KbG9jYWwgYW5kIHJlbW90
ZSBURSBSb3V0ZXIgSUQ6DQoNCjAgMSAyIDMgDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg
NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQorLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgMTcgfCBM
ZW5ndGggfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rIA0KfCBMb2NhbCBURSBSb3V0ZXIgSWRlbnRpZmllciB8IA0KKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSsgDQp8IFJlbW90ZSBURSBSb3V0ZXIgSWRlbnRpZmllciB8IA0KKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQoNCkFs
dGhvdWdoIEkgZG8gdW5kZXJzdGFuZCB3aHkgdGhlcmUgaXMgYSBuZWVkIGZvciBhZHZlcnRpc2lu
ZyB0aGUgTG9jYWwgVEUgDQpSb3V0ZXIgSUQsIEkgZG9uw4PGksOG4oCZw4PigJrDgsKiw4PGksOC
wqInw4PigJrDgsKsw4PGksOCwqIiw4PigJrDgsKidCB1bmRlcnN0YW5kIHdoeSB0aGUgUmVtb3Rl
IFRlIA0KUm91dGVyIElEPyANCklzbsODxpLDhuKAmcOD4oCaw4LCosODxpLDgsKiJ8OD4oCaw4LC
rMODxpLDgsKiIsOD4oCaw4LConQgDQp0aGlzIGlzIA0KdGhlIHNhbWUNCmluZm9ybWF0aW9uIA0K
dGhhdCBpcyBjYXJyaWVkIGluIHRoZSBMaW5rIElEIHN1Yi1UTFY/DQpJbiA2LiB5b3Ugd3JpdGU6
DQoNCsODxpLDhuKAmcOD4oCaw4LCosODxpLDgsKiJ8OD4oCaw4LCrMODxpLDouKCrMKmIkEgUkEg
bWF5IGNvbnRhaW4gc21hbGxlciBSQXMgaW50ZXItY29ubmVjdGVkIGJ5IA0KbGlua3MuIA0KVGhl
IGxpbWl0IG9mIHRoZSBzdWJkaXZpc2lvbiByZXN1bHRzIGluDQphIFJBIHRoYXQgY29udGFpbnMg
dHdvIHN1Yi1uZXR3b3JrcyBpbnRlcmNvbm5lY3RlZCBieSBhIHNpbmdsZSANCmxpbmsuw4PGksOG
4oCZw4PigJrDgsKiw4PGksOCwqInw4PigJrDgsKsw4PGksOi4oKsxaHDg+KAmsOCwp0NCg0KSW4g
Ry44MDgwIEkgcmVhZDoNCsODxpLDhuKAmcOD4oCaw4LCosODxpLDgsKiJ8OD4oCaw4LCrMODxpLD
ouKCrMKmIi4uLi4gQSByb3V0aW5nIGFyZWEgaXMgZGVmaW5lZCBieSBhIHNldCBvZiANCnN1Ym5l
dHdvcmtzLCB0aGUgDQpTTlBQIA0KbGlua3MgDQoNCnRoYXQgaW50ZXJjb25uZWN0IHRoZW0sIGFu
ZCB0aGUgU05QUHMgcmVwcmVzZW50aW5nIHRoZSBlbmRzIG9mIHRoZSBTTlBQIA0KbGlua3MgZXhp
dGluZyB0aGF0IHJvdXRpbmcgYXJlYS4gQSByb3V0aW5nIGFyZWEgbWF5IGNvbnRhaW4gc21hbGxl
ciANCnJvdXRpbmcgYXJlYXMgaW50ZXJjb25uZWN0ZWQgYnkgU05QUCBsaW5rcy4gVGhlIGxpbWl0
IG9mIHN1YmRpdmlzaW9uIA0KcmVzdWx0cyBpbiBhIHJvdXRpbmcgYXJlYSB0aGF0IGNvbnRhaW5z
IF1vbmUgDQpzdWJuZXR3b3JrLsODxpLDhuKAmcOD4oCaw4LCosODxpLDgsKiJ8OD4oCaw4LCrMOD
xpLDouKCrMWhw4PigJrDgsKdDQoNCldoeSBpcyB0aGUgZGlzY3JlcGFuY3k/DQoNClRoYW5rcywN
Cklnb3INCg0KDQpbDQpTdWNrZXItcHVuY2ggc3BhbSB3aXRoIGF3YXJkLXdpbm5pbmcgcHJvdGVj
dGlvbi4NClRyeSB0aGUgZnJlZSBZYWhvbyEgTWFpbCBCZXRhLg0KDQoNCk5vdyB0aGF0J3Mgcm9v
bSBzZXJ2aWNlISBDaG9vc2UgZnJvbSBvdmVyIDE1MCwwMDAgaG90ZWxzIA0KaW4gNDUsMDAwIGRl
c3RpbmF0aW9ucyBvbiBZYWhvbyEgVHJhdmVsIHRvIGZpbmQgeW91ciBmaXQuDQoNCg0KDQpTdWNr
ZXItcHVuY2ggc3BhbSB3aXRoIGF3YXJkLXdpbm5pbmcgcHJvdGVjdGlvbi4NClRyeSB0aGUgZnJl
ZSBZYWhvbyEgTWFpbCBCZXRhLg0KDQoNCg0KR2V0IHlvdXIgb3duIHdlYiBhZGRyZXNzLg0KSGF2
ZSBhIEhVR0UgeWVhciB0aHJvdWdoIFlhaG9vISBTbWFsbCBCdXNpbmVzcy4NCg0KDQo4OjAwPyA4
OjI1PyA4OjQwPyBGaW5kIGEgZmxpY2sgaW4gbm8gdGltZQ0Kd2l0aCB0aGVZYWhvbyEgU2VhcmNo
IG1vdmllIHNob3d0aW1lIHNob3J0Y3V0Lg0KDQoNCiBEb24ndCBnZXQgc29ha2VkLiBUYWtlIGEg
cXVpY2sgcGVlayBhdCB0aGUgZm9yZWNhc3QgDQp3aXRoIHRoZVlhaG9vISBTZWFyY2ggd2VhdGhl
ciBzaG9ydGN1dC4NCg0K



Envelope-to: [e-mail]
Delivery-date: Sat, 10 Mar 2007 13:13:09 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OGGbQJpfmJg1bRGLPgjH0kSqw9kpguwlwq4NN1dM3VcSl/tFHId/abk5QUBEfHKdQu82Jo0P9ym2Y/bG1YCwg+FTyg/N3uk5UwZtdemmgVQ+uwo1uEYP8UPwD//AF2lS8TWfC+rEa99cZDOmw6ObCLvm/wWdqSNOoa1oRWzFik0=  ;
Message-ID: <[e-mail]>
Date: Sat, 10 Mar 2007 05:10:45 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-914139335-1173532245=:30300"
Content-Transfer-Encoding: 8bit

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

[e-mail] 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:     [e-mail], "Brungard, Deborah A, ALABS" 
, "Ong, Lyndon" , 
[e-mail]
        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?

[e-mail] 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: [e-mail]
09/03/2007 20:29

To: "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail], "Brungard, Deborah A, ALABS" 
, [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf 

Of [e-mail]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [e-mail]; Brungard, Deborah A, ALABS; 
[e-mail]
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: [e-mail]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail], "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: [e-mail], "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.

[e-mail] 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: [e-mail], "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>[e-mail]</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 <[e-mail]><br>09/03/2007 22:36<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail], "Brungard, Deborah A, ALABS" <br><[e-mail]>, "Ong, Lyndon" <[e-mail]>, <br>[e-mail]<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>[e-mail] 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: [e-mail]<br>09/03/2007 20:29<br><br>To: "Ong, Lyndon" , Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [e-mail], "Brungard, Deborah A, ALABS" <br>, [e-mail]<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: [e-mail]
 [mailto:[e-mail]] On Behalf <br><br>Of [e-mail]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [e-mail]; Brungard, Deborah A, ALABS; <br>[e-mail]<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: [e-mail]<br>09/03/2007 16:05<br><br>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [e-mail], "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: [e-mail], "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>[e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sat, 10 Mar 2007 02:12:07 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 10 Mar 2007 03:08:44 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvcg0KDQpub3QgYW4gaXNzdWUgb2YgVEUgcm91dGVyIElEIHVuaXF1ZW5lc3MsIHdpdGhvdXQg
dGhpcyBhZGRpdGlvbmFsIHN1Yi1UTFYsIA0KYW4gdW5udW1iZXJlZCBsb2NhbCBpZCBtYXkgbm90
IGJlIHVuaXF1ZSBwZXIgcm91dGVyX2lkLCBoZW5jZSB0aGUgYWRkaXRpb24gDQpvZiB0aGlzIHN1
Yi1UTFYgKFRFIFJvdXRlciBJRCBiZWluZyB1bmlxdWUgcGVyIHJvdXRlcl9pZCkgDQoNCi1kDQoN
Cg0KDQoNCg0KSWdvciBCcnlza2luIDxpX2JyeXNraW5AeWFob28uY29tPg0KMDkvMDMvMjAwNyAy
MjozNg0KIA0KICAgICAgICBUbzogICAgIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVM
QEFMQ0FURUwNCiAgICAgICAgY2M6ICAgICBjY2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVuZ2FyZCwg
RGVib3JhaCBBLCBBTEFCUyIgDQo8ZGJydW5nYXJkQGF0dC5jb20+LCAiT25nLCBMeW5kb24iIDxM
eW9uZ0BDaWVuYS5jb20+LCANCm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0KICAgICAgICBTdWJq
ZWN0OiAgICAgICAgUkU6IFR3byBxdWVzdGlvbnMgb24gDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxz
LWFzb24tcm91dGluZy1vc3BmDQoNCg0KRGltaXRyaSwNCg0KSSBkb24ndCBzZWUgaG93IHdlIGNh
biBtYW5hZ2UgdGhlIHNpdHVhdGlvbiB3aGVyZSBURU5vZGVJZHMgYXJlIG5vdCANCnVuaXF1ZS4g
QXQgdGhlIGVuZCBvZiB0aGUgZGF5IHdlIG11c3QgcHJvY2VzcyBFUk9zL1JST3MgdGhhdCBhcmUg
YnVpbGQNCm9mIFRFTm9kZUlEL1RFTGlua0lEIHBhaXJzLiBJZiBURUxpbmtJRCBoYXMgbm9kZS1z
Y29wZSBhbmQgVEVOb2RlSUQgaXMgbm90IA0KdW5pcXVlLCBob3cgdGhlbiB3ZSBjYW4gaWRlbnRp
ZnkgdGhlIHNwZWNpZmllZCBsaW5rPyBTbyB3aGF0IGRvIHlvdSANCnN1Z2dlc3Qgd2UgcHV0IGlu
IGVhY2ggb2YgdGhlc2UgdHdvIGZpZWxkcz8NCg0KRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0
ZWwtbHVjZW50LmJlIHdyb3RlOg0KaWdvciANCg0KYnV0IGl0IGRvZXNuJ3Qgc29sdmUgdGhlIGlz
c3VlIChhbmQgaW50cm9kdWNlcyBkaWZmZXJlbnQgc2V0dGluZyBhbmQgDQpwcm9jZXNzaW5nIG9m
IHRoZSBsaW5rIGlkIHZhbHVlIGZyb20gcmZjIDM2MzApIGluZGVlZCwgaW4gQVNPTiBSQyBjYW4g
YmUgDQphc3NvY2lhdGVkIHRvIG11bHRpcGxlICJub2RlcyIsIGVhY2ggb2YgdGhlc2Ugbm9kZXMg
Y2FuIGhhdmUgb3ZlcmxhcHBpbmcgDQppZCBzcGFjZXMgKHRvIGlkZW50aWZ5IHRoZSAibGlua3Mi
KSANCg0KZm9yIHRoYXQgcmVhc29uIHRoZSBzb2x1dGlvbiBpcyB0aGF0IGVhY2ggVEUgbGluayAo
dG9wIGxldmVsKSBUTFYgaGFzIGEgDQpuZXcgc3ViLVRMViB0aGF0IGFzc29jaWF0ZXMgdGhlIGxv
Y2FsIGFuZCByZW1vdGUgIm5vZGUgaWQiICh0aGUgZm9ybWVyIGFuZCANCg0KbGF0dGVyIHRha2Vz
IHRoZSBURSBSb3V0ZXIgSUQgYXMgdmFsdWUpDQoNCml0IGlzIHRoZSBzdWJzdGFuY2Ugb2Ygd2hh
dCBpIGhhdmUgYmVlbiBwb2ludGluZyB0byB5b3UgaW4gbXkgaW5pdGlhbCANCmUtbWFpbCAoc2Vl
IFNlY3Rpb24gNS4yIGJ1dCBhbHNvIGluIFJGQyA0NjUyIFNlY3Rpb24gNS43OiAidGhlIHJvdXRp
bmcgDQpwcm90b2NvbCBNVVNUIGJlIGFibGUgdG8gZGlzYW1iaWd1YXRlIHRoZSBhZHZlcnRpc2Vk
IFRFIGxpbmtzIHNvIHRoYXQgdGhleSANCg0KY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgY29y
cmVjdCBURSBSb3V0ZXIgSUQuIikNCg0KLWQuDQoNCg0KDQoNCg0KDQoNCklnb3IgQnJ5c2tpbiAN
ClNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0KMDkvMDMvMjAwNyAyMDoyOQ0KDQpU
bzogIk9uZywgTHluZG9uIiAsIERpbWl0cmkgDQpQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxD
QVRFTA0KY2M6IGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJT
IiANCiwgb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogVHdvIHF1ZXN0aW9u
cyBvbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLW9zcGYNCg0KDQpMeW5k
b24sDQoNCkxldCBtZSB0cnkgdG8gZXhwbGFpbiBteSBwb2ludC4gDQoNCkJhc2ljYWxseSwgd2Ug
aGF2ZSB0d28gc29sdXRpb25zIHRvIGFkZHJlc3MgdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSANCnJl
bGF0aW9uc2hpcCBiZXR3ZWVuIGEgcm91dGVyIGNvbnRyb2xsZXIgYW5kIGRhdGEgcGxhbmUgc3dp
dGNoZXMgKFRFIG5vZGVzIA0KDQpvciBURSByb3V0ZXJzKSBhcmUgMTpOLCB0aGF0IGlzLCB3aGVu
IGEgc2luZ2xlIGNvbnRyb2xsZXIgbWFuYWdlcyBtdWx0aXBsZSANCg0KVEUgcm91dGVycy4NCg0K
U29sdXRpb24gMSAoc3VnZ2VzdGVkIGluIHRoZSBkcmFmdCk6DQoNCkVhY2ggVEUgTGluayBhZHZl
cnRpc2luZyBpcyBleHRlbmRlZCB3aXRoIExvY2FsL1JlbW90ZSBURSBSb3V0ZXIgSURzIHBhaXIu
IA0KDQpJbiB0aGlzIGNhc2UsIHdoYXQgaXMgaW4gdGhlIExpbmtJRCBzdWItVExWIGlzIG5vdCBp
bXBvcnRhbnQgcmVhbGx5Lg0KDQpTb2x1dGlvbiAyIChtaW5lKQ0KDQpUaGUgUm91dGVyIEFkZHJl
c3MgVExWIGlzIGV4dGVuZGVkIHRvIGFkdmVydGlzZSBhbGwgVEUgUm91dGVyIElEcyANCmNvbnRy
b2xsZWQgYnkgdGhlIGFkdmVydGlzaW5nIGNvbnRyb2xsZXIgYXMgcm91dGFibGUgYWRkcmVzc2Vz
LiBUaGUgVEUgDQpMaW5rIFRMViBpcyBleHRlbmRlZCB0byBhZHZlcnRpc2UgdGhlIGxvY2FsIFRF
IFJvdXRlciBJRC4gSG93ZXZlciwgdGhlcmUgDQppcyBubyBuZWVkIHRvIGFkdmVydGlzZSB0aGUg
cmVtb3RlIFRFIFJvdXRlciBJRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSANCmZ1bmN0aW9uIG9mIHRo
ZSBleGlzdGluZyBMaW5rSUQgc3ViLVRMViwgd2hpY2ggaXMgdG8gaWRlbnRpZnkgdGhlIHJlbW90
ZSANCmVuZCBvZiB0aGUgYWR2ZXJ0aXNlZCBURSBsaW5rIMOi4oKs4oCcIHJlbW90ZSBURSBSb3V0
ZXIgSUQuDQoNCkJvdGggdGhlc2UgYXBwcm9hY2hlcyBzb2x2ZSB0aGUgcHJvYmxlbTsgaG93ZXZl
ciwgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIHRvIA0KDQphbnN3ZXIgaXM6DQoNCkRvIHdlIG5lZWQg
dGhlIFRFIFJvdXRlciBJRHMgdG8gYmUgcm91dGFibGUgYWRkcmVzc2VzPw0KDQpUaGUgYW5zd2Vy
IGlzIFlFUyBhY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hZGRyZXNzaW5nLTA1
LnR4dC4gDQpGb3IgZXhhbXBsZSwgaWYgdGhlIG5ldHdvcmsNCmlzIGJ1aWx0IG9mIHVubnVtYmVy
ZWQgVEUgbGlua3MsIHRoYW4gRVJPIHNpZ25hbGVkIGluIFJTVlAtVEUgUGF0aCB3aWxsIA0KY29u
dGFpbg0KcGF0aCBpbiBhIGZvcm0gb2YgVEVfUnRySUQvaWZJbmRleCBwYWlycywgYW5kIGhhdmlu
ZyBURV9SdHJJRCByb3V0YWJsZSANCnNvbHZlcyB0aGUgcHJvYmxlbSBob3cgdG8gc2lnbmFsIHRo
ZSBQYXRoIG1lc3NhZ2UgYWxvbmcgdGhlIHByb3Zpc2lvbmVkIA0KcGF0aC4uDQpJZiB5b3UgYWdy
ZWUgd2l0aCB0aGlzLCB0aGFuIHlvdSB3aWxsIGFsc28gYWdyZWUgdGhhdCBhbGwgVEUgUm91dGVy
IElEcyANCnNob3VsZCBiZSBhZHZlcnRpc2VkIHdpdGhpbiBSb3V0ZXIgQWRkcmVzcyBUTFYNCkhv
cGUgdGhhdCB0aGlzIGhlbHBzLg0KDQpJZ29yDQoNCg0KDQoNCiJPbmcsIEx5bmRvbiIgd3JvdGU6
DQpIaSBEaW1pdHJpLA0KDQpUaGF0IHdhcyBteSB1bmRlcnN0YW5kaW5nIGFsc28sIEkgZG9uJ3Qg
c2VlIGFueSBpc3N1ZSB3aXRoIHRoaXMuDQoNCkNoZWVycywNCg0KTHluZG9uIA0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWls
dG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgDQoNCk9mIERpbWl0cmkuUGFw
YWRpbWl0cmlvdUBhbGNhdGVsLWx1Y2VudC5iZQ0KU2VudDogRnJpZGF5LCBNYXJjaCAwOSwgMjAw
NyA3OjU2IEFNDQpUbzogSWdvciBCcnlza2luDQpDYzogY2NhbXBAb3BzLmlldGYub3JnOyBCcnVu
Z2FyZCwgRGVib3JhaCBBLCBBTEFCUzsgDQpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNClN1Ympl
Y3Q6IFR3byBxdWVzdGlvbnMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmct
b3NwZiANCg0KaWdvcg0KDQp0aGUgZHJhZnRzIHNheXMNCg0KIk5vdGU6IFRoZSBMaW5rIElEIHN1
Yi1UTFYgdGhhdCBpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgb2YgdGhlIGxpbmsgKGkuZS4gDQoN
Cg0KUm91dGVyIElEIG9mIHRoZSBuZWlnaGJvciBmb3IgcG9pbnQtdG8tcG9pbnQgbGlua3MpIE1V
U1QgYXBwZWFyIGV4YWN0bHkgDQpvbmNlIHBlciBMaW5rIFRMVi4gVGhpcyBzdWItVExWIE1VU1Qg
YmUgcHJvY2Vzc2VkIGFzIGRlZmluZWQgaW4gW1JGQzM2MzBdLiANCg0KDQoiIA0KDQp3aGljaCBp
cyBleGFjdGx5IHdoYXQgeW91IGFyZSBzYXlpbmcgLSB3aGVuIGkgc2F5ICJpdCBpZGVudGlmaWVz
IHRoZSANCnJlbW90ZSBSQyBub3QgdGhlIHJlbW90ZSBkYXRhIHBsYW5lICJub2RlIiBpbiBjYXNl
IHRoZSByZW1vdGUgUkMgaXMgDQphc3NvY2lhdGUgdG8gbiBub2RlcyIgcmVhZCAiaXQgaXMgc2V0
IHRvIHRoZSByb3V0ZXJfaWQgdGhhdCBpZGVudGlmaWVzIHRoZSANCg0KcmVtb3RlIFJDLi4uIg0K
aW4gYnJpZWYsIHdlIGtlZXAgdGhlIHNlbWFudGljIGFuZCBhZGQgYSBkaXNjcmltaW5hdG9yICh0
aGF0IGRvZXMgbm90IA0KYXBwbHkgaW4gY2FzZSBvZiBjb2xvY2F0ZWQgMToxIExTUikgLSB0aGlz
IGNsb3NlcyB0aGUgZmlyc3QgcG9pbnQgLQ0KDQpjb25jZXJuaW5nIHRoZSBzZWNvbmQgcG9pbnQs
IHNpbmNlIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdG8gaGF2ZSBtdWx0aXBsZSANCg0KYXNzb2Np
YXRpb25zIGluIGRpZmZlcmVudCBMU0FzIGkgZG9uJ3Qgd2hlcmUgdGhlIHByb2JsZW0gaXMgPw0K
DQp0aGFua3MsDQotZC4NCg0KDQoNCg0KDQpJZ29yIEJyeXNraW4gDQpTZW50IGJ5OiBvd25lci1j
Y2FtcEBvcHMuaWV0Zi5vcmcNCjA5LzAzLzIwMDcgMTY6MDUNCg0KVG86IERpbWl0cmkgUEFQQURJ
TUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCmNjOiBjY2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVu
Z2FyZCwgRGVib3JhaCBBLCBBTEFCUyIgDQoNClN1YmplY3Q6IFJlOiBUd28gcXVlc3Rpb25zIG9u
IA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3NwZiBkcmFmdA0KDQoN
CkRpbWl0cmksDQoNCj4gSXMgdGhlIExpbmtJRCBpcyB0aGUgc2FtZSBhcyBSZW1vdGUgVEUgUm91
dGVyIElEPyANCg0Kbm8NCg0KPiBMaW5rSUQgdW5hbWJpZ3Vvc2x5IGlkZW50aWZpZXMgcmVtb3Rl
IGRhdGEgcGxhbmUgbm9kZSwNCg0Kbm8sIGl0IGlkZW50aWZpZXMgdGhlIHJlbW90ZSBSQyBub3Qg
dGhlIHJlbW90ZSBkYXRhIHBsYW5lICJub2RlIiBpbiBjYXNlIA0KdGhlIHJlbW90ZSBSQyBpcyBh
c3NvY2lhdGUgdG8gbiAibm9kZXMiDQoNCklCPj4gTm8sIEkgZGlzYWdyZWUuIFlvdSBzZWUgdGhh
dCdzIHdoeSBpdCdzIHNvIGltcG9ydGFudCB0byBxdW90ZSB0aGUNClJGQ3MvZHJhZnRzLCBiZWNh
dXNlIHBlb3BsZSBvZnRlbiBpbnRlcnByZXQgdGhlbSBkaWZmZXJlbnRseS4NCg0KSW4gUkZDIDM2
MzAgd2UgcmVhZDoNCiINCjIuNS4yLiBMaW5rIElEDQoNCg0KDQpUaGUgTGluayBJRCBzdWItVExW
IGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0aGUgbGluay4gRm9yDQoNCnBvaW50LXRvLXBv
aW50IGxpbmtzLCB0aGlzIGlzIHRoZSBSb3V0ZXIgSUQgb2YgdGhlIG5laWdoYm9yLg0KDQoiDQoN
Ck5vdGUgdGhhdCBpdCBkb2VzIG5vdCBzYXkgd2hldGhlciB0aGlzIGlzIHRoZSBhZHZlcnRpc2lu
ZyBSb3V0ZXIgSUQgDQoNCihpZGVudGlmeWluZyBuZWlnaGJvciBSQykgb3IgVEUgUm91dGVyIElE
IChpZGVudGlmeWluZyB0aGUNCm5laWdoYm9yIFRFIG5vZGUpLiBIb3dldmVyLCBpdCBkb2VzIHNh
eSB0aGF0IGl0ICJpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgDQpvZiB0aGUgbGluayIuIEJlY2F1
c2UgYSBsaW5rIGlzIHRlcm1pbmF0ZWQgYnkgVEUgbm9kZXMgKGFuZCBub3QgDQphZHZlcnRpc2lu
ZyByb3V0ZXJzKSBJIGNvbmNsdWRlIHRoYXQgTGlua0lEIGlkZW50aWZpZXMgdGhlIHJlbW90ZSBU
RSBub2RlLg0KDQpGdXJ0aGVybW9yZSwgZWFybGllciBpbiBSRkMgMzYzMCB3ZSByZWFkOg0KIg0K
Mi40LjEuIFJvdXRlciBBZGRyZXNzIFRMVg0KDQpUaGUgUm91dGVyIEFkZHJlc3MgVExWIHNwZWNp
ZmllcyBhIHN0YWJsZSBJUCBhZGRyZXNzIG9mIHRoZQ0KYWR2ZXJ0aXNpbmcgcm91dGVyIHRoYXQg
aXMgYWx3YXlzIHJlYWNoYWJsZSBpZiB0aGVyZSBpcyBhbnkNCmNvbm5lY3Rpdml0eSB0byBpdDsg
dGhpcyBpcyB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYXMgYSAibG9vcGJhY2sNCmFkZHJlc3MiLiBU
aGUga2V5IGF0dHJpYnV0ZSBpcyB0aGF0IHRoZSBhZGRyZXNzIGRvZXMgbm90IGJlY29tZQ0KdW51
c2FibGUgaWYgYW4NCmludGVyZmFjZSBpcyBkb3duLiBJbiBvdGhlciBwcm90b2NvbHMsIHRoaXMg
aXMga25vd24NCmFzIHRoZSAicm91dGVyIElEIg0KDQpJIGludGVycHJldCB0aGF0IHRoaXMgaXMg
dGhlIHNhbWUgcm91dGVyIElEIGFzIGluIHRoZSB1cHBlciBxdW90ZS4gSXQgaXMgDQphZHZlcnRp
c2VkIGluIHRoZSBSb3V0ZXIgQWRkcmVzcyBUTFYsIHdoaWNoIGlzIHRoZSBvbmx5IHdheSB0b2Rh
eSB0byANCmFkdmVydGlzZSBURSBSb3V0ZXIgSUQuIEhlbmNlIHRoZSByb3V0ZXIgSUQgaW4gdGhl
IGNvbnRleHQgb2YgdGhpcyBSRkMgaXMgDQp0aGUgVEUgUm91dGVyIElELg0KDQpUaGUgY29uY2x1
c2lvbiAjMTogdGhlIFRFIExpbmsgVExWLCBhcyBpdCBpcyB0b2RheSwgYWx3YXlzIGNvbnRhaW5z
IHRoZSBJRCANCg0KDQpvZiB0aGUgcmVtb3RlIFRFIG5vZGUuIA0KDQpUaGUgY29uY2x1c2lvbiAj
MjogdGhlcmUgaXMgYSBuZWVkIHRvIGFkdmVydGlzZSBzZXZlcmFsIFRFIFJvdXRlciBJRHMgDQpz
dXBwb3J0ZWQgYnkgdGhlIHNhbWUgUkMgKGFkdmVydGlzaW5nIHJvdXRlciksIHdoaWNoLCBJIHRo
aW5rLCBzaG91bGQgYmUgDQpwcm9wb3NlZCBpbiB5b3VyIGRyYWZ0DQoNCnBzOiBzZWNvbmQgcXVl
c3Rpb24gaXMgdHJpdmlhbCwgbWF0aGVtYXRpY2FsIHZzIG5ldHdvcmtpbmcgZm9ybXVsYXRpb24g
KG5vIA0KDQoNCg0KcmVhbCBkaWZmZXJlbmNlKQ0KDQpJQj4+IFdlbGwsIGl0IGNoYW5nZXMgb25l
IG9mIHRoZSBmdW5kYW1lbnRhbCBkZWZpbml0aW9ucyBvZiBHLjgwODAsIGFuZCBJIA0KYW0gYXNr
aW5nIHdoeSBpcyB0aGF0IGluIHRoZSBkcmFmdCB3aGljaCBpcyBzdXBwb3NlZCB0byBkZWZpbmUg
d2F5cyB0byANCnN1cHBvcnQgRy44MDgwIA0KDQpJZ29yDQoNCnBwczogaWYgeW91IHdhbnQgdG8g
cHV0IGd1aWRlbGluZXMgb24gZS1tYWlsIHJlc3BvbnNlcyBwcm9iYWJseSBkaXJlY3RpbmcgDQp5
b3VyIGUtbWFpbCB0byB0aGUgR0VOIEFSRUEgd291bGQgYmUgbW9yZSBzdWl0YWJsZSANCg0KaG9w
ZSB0aGlzIGhlbHBzLA0KLWQuDQoNCg0KDQoNCklnb3IgQnJ5c2tpbiANCjA5LzAzLzIwMDcgMDA6
MDMNCg0KVG86IERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCmNjOiBj
Y2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUyIgDQoNClN1Ympl
Y3Q6IFJlOiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29u
LXJvdXRpbmctb3NwZiBkcmFmdA0KDQoNCkRpbWl0cmksIG5vLCBpdCBkb2VzIG5vdCBoZWxwLg0K
DQpZb3UgZGlkbid0IGFuc3dlciB0aGUgZmlyc3QgcXVlc3Rpb24sIHdoaWNoIGlzOg0KDQpJcyB0
aGUgTGlua0lEIGlzIHRoZSBzYW1lIGFzIFJlbW90ZSBURSBSb3V0ZXIgSUQ/IElmIG5vLCB3aGF0
IGlzIHRoZSANCmRpZmZlcmVuY2U/IElmIHllcywgd2h5IGRvIHlvdSBuZWVkIHRoZSBsYXR0ZXI/
IEJvdGggeW91ciBwb2ludGVycyBleHBsYWluIA0KDQoNCg0Kd2h5IGRvIHlvdSBuZWVkIGFkdmVy
dGlzaW5nIG9mIHRoZSBsb2NhbCBURSBSb3V0ZXIgSUQgKGFkdmVydGlzaW5nIHJvdXRlciANCm1h
eSBjb3ZlciBtdWx0aXBsZSBkYXRhIHBsYW5lIG5vZGVzKSwgSG93ZXZlciwgTGlua0lEIHVuYW1i
aWd1b3NseSANCmlkZW50aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUgbm9kZSwgYW5kIHRoZSBuZWVk
IGZvciB0aGUgYWR2ZXJ0aXNpbmcgb2YgDQpSZW1vdGUgVEUgUm91dGVyIElEIGlzIG5vdCBvYnZp
b3VzDQoNCkJUVywgWW91IGRpZG4ndCBhbnN3ZXIgdGhlIHNlY29uZCBxdWVzdGlvbiBlaXRoZXIu
DQoNCklnb3INCg0KUFMsIEkgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9yIHRoZSB3b3JraW5nIGdyb3Vw
OiBMZXQgdXMgZGlzYWxsb3cgcmVzcG9uZGluZyANCnRvIHRoZSBjb21tZW50cy9xdWVzdGlvbnMg
YnkganVzdCBwb2ludGluZyB0byBSRkNzIG9yIGRyYWZ0cy4gSW4gbXkgdmlldyANCml0IGlzIHF1
aXRlIHVuZnJpZW5kbHkuIEl0IGlzIGFsd2F5cyBwb3NzaWJsZSB0byBjdXQgYW5kIHBhc3RlIGEg
cGllY2UgDQpmcm9tIHRoZSByZWxldmFudCBSRkMgb3IgZHJhZnQgY29uZmlybWluZyB0aGUgcG9p
bnRzIHRoZSB3cml0ZXIgaXMgdHJ5aW5nIA0KdG8gbWFrZS4NCg0KRGltaXRyaS5QYXBhZGltaXRy
aW91QGFsY2F0ZWwtbHVjZW50LmJlIHdyb3RlOg0KaWdvcg0KDQoNCnBscyB1c2UgdmVyc2lvbiAo
b3IgMDMgDQp3aGVuIGF2YWlsYWJsZSB0byBtYWtlIGNvbW1lbnRzKQ0KDQppbiB0aGF0IHZlcnNp
b24geW91IHdpbGwgc2VlIGluIFNlY3Rpb24gNS4yDQoNCiIgTm90ZTogVGhlIExpbmsgSUQgc3Vi
LVRMViB0aGF0IGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0aGUgbGluayANCihpLmUuIFJv
dXRlciBJRCBvZiB0aGUgbmVpZ2hib3IgZm9yIHBvaW50LXRvLXBvaW50IGxpbmtzKSBNVVNUIA0K
YXBwZWFyIGV4YWN0bHkgb25jZSBwZXIgTGluayBUTFYuIFRoaXMgc3ViLVRMViBNVVNUIGJlIHBy
b2Nlc3NlZCBhcyANCmRlZmluZWQgaW4gW1JGQzM2MzBdLiAiDQoNCm5vdyB3aHkgdGhpcyBzdWIt
VExWIDE3LCB3ZWxsIGZvciB0aGUgcmVhc29uIGV4cGxhaW5lZCBhdCB0aGUgYmVnaW5uaW5nIG9m
IA0KDQoNCg0KDQpwYXIuNS4yDQpidXQgYWxzbyBpbiBSRkMgNDY1MiBTZWN0aW9uIDUuNw0KDQpo
b3BlIHRoaXMgaGVscHMsDQotZC4NCg0KDQoNCg0KSWdvciBCcnlza2luIA0KMDgvMDMvMjAwNyAy
MjoxMQ0KDQpUbzogRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KY2M6
IGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTIiANCg0KU3Vi
amVjdDogVHdvIHF1ZXN0aW9ucyBvbiANCmRyYWZ0LWRpbWl0cmktY2NhbXAtZ21wbHMtYXNvbi1y
b3V0aW5nLW9zcGYgZHJhZnQNCg0KDQpEaW1pdHJpLA0KSSBoYXZlIGEgY291cGxlIHF1ZXN0aW9u
cyB3cnQgdGhlIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3NwZiBk
cmFmdC4NCkluIDUuMiBhIFRFIExpbmsgc3ViLVRMViBpcyBpbnRyb2R1Y2VkIGZvciB0aGUgcHVy
cG9zZSBvZiBhZHZlcnRpc2luZyANCmxvY2FsIGFuZCByZW1vdGUgVEUgUm91dGVyIElEOg0KDQow
IDEgMiAzIA0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg
NCA1IDYgNyA4IDkgMCAxIA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IDE3IHwgTGVuZ3RoIHwgDQorLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN
CnwgTG9jYWwgVEUgUm91dGVyIElkZW50aWZpZXIgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KfCBSZW1vdGUgVEUg
Um91dGVyIElkZW50aWZpZXIgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KDQpBbHRob3VnaCBJIGRvIHVuZGVyc3Rh
bmQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWR2ZXJ0aXNpbmcgdGhlIExvY2FsIFRFIA0KUm91
dGVyIElELCBJIGRvbsODxpLDgsKiw4PCoifDgsKsw4PCoiLDgsKidCB1bmRlcnN0YW5kIHdoeSB0
aGUgUmVtb3RlIFRlIFJvdXRlciBJRD8gDQpJc27Dg8aSw4LCosODwqInw4LCrMODwqIiw4LConQg
DQp0aGlzIGlzIA0KdGhlIHNhbWUNCmluZm9ybWF0aW9uIA0KdGhhdCBpcyBjYXJyaWVkIGluIHRo
ZSBMaW5rIElEIHN1Yi1UTFY/DQpJbiA2LiB5b3Ugd3JpdGU6DQoNCsODxpLDgsKiw4PCoifDgsKs
w4PigKYiQSBSQSBtYXkgY29udGFpbiBzbWFsbGVyIFJBcyBpbnRlci1jb25uZWN0ZWQgYnkgbGlu
a3MuIA0KVGhlIGxpbWl0IG9mIHRoZSBzdWJkaXZpc2lvbiByZXN1bHRzIGluDQphIFJBIHRoYXQg
Y29udGFpbnMgdHdvIHN1Yi1uZXR3b3JrcyBpbnRlcmNvbm5lY3RlZCBieSBhIHNpbmdsZSANCmxp
bmsuw4PGksOCwqLDg8KiJ8OCwqzDg+KAmsOCwp0NCg0KSW4gRy44MDgwIEkgcmVhZDoNCsODxpLD
gsKiw4PCoifDgsKsw4PigKYiLi4uLiBBIHJvdXRpbmcgYXJlYSBpcyBkZWZpbmVkIGJ5IGEgc2V0
IG9mIHN1Ym5ldHdvcmtzLCB0aGUgDQpTTlBQIA0KbGlua3MgDQoNCnRoYXQgaW50ZXJjb25uZWN0
IHRoZW0sIGFuZCB0aGUgU05QUHMgcmVwcmVzZW50aW5nIHRoZSBlbmRzIG9mIHRoZSBTTlBQIA0K
bGlua3MgZXhpdGluZyB0aGF0IHJvdXRpbmcgYXJlYS4gQSByb3V0aW5nIGFyZWEgbWF5IGNvbnRh
aW4gc21hbGxlciANCnJvdXRpbmcgYXJlYXMgaW50ZXJjb25uZWN0ZWQgYnkgU05QUCBsaW5rcy4g
VGhlIGxpbWl0IG9mIHN1YmRpdmlzaW9uIA0KcmVzdWx0cyBpbiBhIHJvdXRpbmcgYXJlYSB0aGF0
IGNvbnRhaW5zIF1vbmUgc3VibmV0d29yay7Dg8aSw4LCosODwqInw4LCrMOD4oCaw4LCnQ0KDQpX
aHkgaXMgdGhlIGRpc2NyZXBhbmN5Pw0KDQpUaGFua3MsDQpJZ29yDQoNCg0KWw0KU3Vja2VyLXB1
bmNoIHNwYW0gd2l0aCBhd2FyZC13aW5uaW5nIHByb3RlY3Rpb24uDQpUcnkgdGhlIGZyZWUgWWFo
b28hIE1haWwgQmV0YS4NCg0KDQpOb3cgdGhhdCdzIHJvb20gc2VydmljZSEgQ2hvb3NlIGZyb20g
b3ZlciAxNTAsMDAwIGhvdGVscyANCmluIDQ1LDAwMCBkZXN0aW5hdGlvbnMgb24gWWFob28hIFRy
YXZlbCB0byBmaW5kIHlvdXIgZml0Lg0KDQoNCg0KU3Vja2VyLXB1bmNoIHNwYW0gd2l0aCBhd2Fy
ZC13aW5uaW5nIHByb3RlY3Rpb24uDQpUcnkgdGhlIGZyZWUgWWFob28hIE1haWwgQmV0YS4NCg0K
DQoNCkdldCB5b3VyIG93biB3ZWIgYWRkcmVzcy4NCkhhdmUgYSBIVUdFIHllYXIgdGhyb3VnaCBZ
YWhvbyEgU21hbGwgQnVzaW5lc3MuDQoNCg0KIDg6MDA/IDg6MjU/IDg6NDA/IEZpbmQgYSBmbGlj
ayBpbiBubyB0aW1lDQp3aXRoIHRoZVlhaG9vISBTZWFyY2ggbW92aWUgc2hvd3RpbWUgc2hvcnRj
dXQuDQoNCg==



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 21:37:50 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kZRQHi11Gpso93OkfkLA7HWigvJQks6KMUA+AJ6BiShBlPCytrjEowax+S51hSy+n0jv6VJAIV4TcGZija5K6h7SZx5o0r5s09LjtJxC9IKGAfLD7Z/8M7goLnZyX3RVY22TVnJXD1bR+5IhUZ9nmD/xdnHpgiIUbLwXG/I3pkI=;
Date: Fri, 9 Mar 2007 13:36:27 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1698436596-1173476187=:26675"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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

[e-mail] 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: [e-mail]
09/03/2007 20:29
 
        To:     "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail], "Brungard, Deborah A, ALABS" 
, [e-mail]
        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: [e-mail] [mailto:[e-mail]] On Behalf 
Of [e-mail]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [e-mail]; Brungard, Deborah A, ALABS; 
[e-mail]
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: [e-mail]
09/03/2007 16:05

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail], "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: [e-mail], "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.

[e-mail] 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: [e-mail], "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>[e-mail]</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 <[e-mail]><br>Sent by: [e-mail]<br>09/03/2007 20:29<br> <br>        To:     "Ong, Lyndon" <[e-mail]>, Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail], "Brungard, Deborah A, ALABS" <br><[e-mail]>, [e-mail]<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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf <br>Of [e-mail]<br>Sent: Friday, March 09, 2007 7:56 AM<br>To: Igor Bryskin<br>Cc: [e-mail]; Brungard, Deborah A, ALABS; <br>[e-mail]<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: [e-mail]<br>09/03/2007 16:05<br><br>To: Dimitri
 PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>cc: [e-mail], "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: [e-mail], "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>[e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 20:59:44 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Ong, Lyndon" <[e-mail]>, [e-mail]
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 9 Mar 2007 21:58:55 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvciANCg0KYnV0IGl0IGRvZXNuJ3Qgc29sdmUgdGhlIGlzc3VlIChhbmQgaW50cm9kdWNlcyBk
aWZmZXJlbnQgc2V0dGluZyBhbmQgDQpwcm9jZXNzaW5nIG9mIHRoZSBsaW5rIGlkIHZhbHVlIGZy
b20gcmZjIDM2MzApIGluZGVlZCwgaW4gQVNPTiBSQyBjYW4gYmUgDQphc3NvY2lhdGVkIHRvIG11
bHRpcGxlICJub2RlcyIsIGVhY2ggb2YgdGhlc2Ugbm9kZXMgY2FuIGhhdmUgb3ZlcmxhcHBpbmcg
DQppZCBzcGFjZXMgKHRvIGlkZW50aWZ5IHRoZSAibGlua3MiKSANCg0KZm9yIHRoYXQgcmVhc29u
IHRoZSBzb2x1dGlvbiBpcyB0aGF0IGVhY2ggVEUgbGluayAodG9wIGxldmVsKSBUTFYgaGFzIGEg
DQpuZXcgc3ViLVRMViB0aGF0IGFzc29jaWF0ZXMgdGhlIGxvY2FsIGFuZCByZW1vdGUgIm5vZGUg
aWQiICh0aGUgZm9ybWVyIGFuZCANCmxhdHRlciB0YWtlcyB0aGUgVEUgUm91dGVyIElEIGFzIHZh
bHVlKQ0KDQppdCBpcyB0aGUgc3Vic3RhbmNlIG9mIHdoYXQgaSBoYXZlIGJlZW4gcG9pbnRpbmcg
dG8geW91IGluIG15IGluaXRpYWwgDQplLW1haWwgKHNlZSBTZWN0aW9uIDUuMiBidXQgYWxzbyBp
biBSRkMgNDY1MiBTZWN0aW9uIDUuNzogInRoZSByb3V0aW5nIA0KcHJvdG9jb2wgTVVTVCBiZSBh
YmxlIHRvIGRpc2FtYmlndWF0ZSB0aGUgYWR2ZXJ0aXNlZCBURSBsaW5rcyBzbyB0aGF0IHRoZXkg
DQpjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb3JyZWN0IFRFIFJvdXRlciBJRC4iKQ0KDQot
ZC4NCg0KDQoNCg0KDQoNCg0KSWdvciBCcnlza2luIDxpX2JyeXNraW5AeWFob28uY29tPg0KU2Vu
dCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQowOS8wMy8yMDA3IDIwOjI5DQogDQogICAg
ICAgIFRvOiAgICAgIk9uZywgTHluZG9uIiA8THlvbmdAQ2llbmEuY29tPiwgRGltaXRyaSANClBB
UEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMDQogICAgICAgIGNjOiAgICAgY2NhbXBAb3Bz
LmlldGYub3JnLCAiQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMiIA0KPGRicnVuZ2FyZEBhdHQu
Y29tPiwgb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBS
RTogVHdvIHF1ZXN0aW9ucyBvbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5n
LW9zcGYNCg0KDQpMeW5kb24sDQogDQpMZXQgbWUgdHJ5IHRvIGV4cGxhaW4gbXkgcG9pbnQuIA0K
IA0KQmFzaWNhbGx5LCB3ZSBoYXZlIHR3byBzb2x1dGlvbnMgdG8gYWRkcmVzcyB0aGUgc2l0dWF0
aW9uIHdoZW4gdGhlIA0KcmVsYXRpb25zaGlwIGJldHdlZW4gYSByb3V0ZXIgY29udHJvbGxlciBh
bmQgZGF0YSBwbGFuZSBzd2l0Y2hlcyAoVEUgbm9kZXMgDQpvciBURSByb3V0ZXJzKSBhcmUgMTpO
LCB0aGF0IGlzLCB3aGVuIGEgc2luZ2xlIGNvbnRyb2xsZXIgbWFuYWdlcyBtdWx0aXBsZSANClRF
IHJvdXRlcnMuDQogDQpTb2x1dGlvbiAxIChzdWdnZXN0ZWQgaW4gdGhlIGRyYWZ0KToNCiANCkVh
Y2ggVEUgTGluayBhZHZlcnRpc2luZyBpcyBleHRlbmRlZCB3aXRoIExvY2FsL1JlbW90ZSBURSBS
b3V0ZXIgSURzIHBhaXIuIA0KSW4gdGhpcyBjYXNlLCB3aGF0IGlzIGluIHRoZSBMaW5rSUQgc3Vi
LVRMViBpcyBub3QgaW1wb3J0YW50IHJlYWxseS4NCiANClNvbHV0aW9uIDIgKG1pbmUpDQogDQpU
aGUgUm91dGVyIEFkZHJlc3MgVExWIGlzIGV4dGVuZGVkIHRvIGFkdmVydGlzZSBhbGwgVEUgUm91
dGVyIElEcyANCmNvbnRyb2xsZWQgYnkgdGhlIGFkdmVydGlzaW5nIGNvbnRyb2xsZXIgYXMgcm91
dGFibGUgYWRkcmVzc2VzLiBUaGUgVEUgDQpMaW5rIFRMViBpcyBleHRlbmRlZCB0byBhZHZlcnRp
c2UgdGhlIGxvY2FsIFRFIFJvdXRlciBJRC4gSG93ZXZlciwgdGhlcmUgDQppcyBubyBuZWVkIHRv
IGFkdmVydGlzZSB0aGUgcmVtb3RlIFRFIFJvdXRlciBJRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSAN
CmZ1bmN0aW9uIG9mIHRoZSBleGlzdGluZyBMaW5rSUQgc3ViLVRMViwgd2hpY2ggaXMgdG8gaWRl
bnRpZnkgdGhlIHJlbW90ZSANCmVuZCBvZiB0aGUgYWR2ZXJ0aXNlZCBURSBsaW5rIOKAkyByZW1v
dGUgVEUgUm91dGVyIElELg0KIA0KQm90aCB0aGVzZSBhcHByb2FjaGVzIHNvbHZlIHRoZSBwcm9i
bGVtOyBob3dldmVyLCBhbiBpbXBvcnRhbnQgcXVlc3Rpb24gdG8gDQphbnN3ZXIgaXM6DQogDQpE
byB3ZSBuZWVkIHRoZSBURSBSb3V0ZXIgSURzIHRvIGJlIHJvdXRhYmxlIGFkZHJlc3Nlcz8NCiAN
ClRoZSBhbnN3ZXIgaXMgWUVTIGFjY29yZGluZyB0byBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFk
ZHJlc3NpbmctMDUudHh0LiANCkZvciBleGFtcGxlLCBpZiB0aGUgbmV0d29yaw0KIGlzIGJ1aWx0
IG9mIHVubnVtYmVyZWQgVEUgbGlua3MsIHRoYW4gRVJPIHNpZ25hbGVkIGluIFJTVlAtVEUgUGF0
aCB3aWxsIA0KY29udGFpbg0KIHBhdGggaW4gYSBmb3JtIG9mIFRFX1J0cklEL2lmSW5kZXggcGFp
cnMsIGFuZCBoYXZpbmcgVEVfUnRySUQgcm91dGFibGUgDQpzb2x2ZXMgdGhlIHByb2JsZW0gaG93
IHRvIHNpZ25hbCB0aGUgUGF0aCBtZXNzYWdlIGFsb25nIHRoZSBwcm92aXNpb25lZCANCnBhdGgu
Lg0KSWYgeW91IGFncmVlIHdpdGggdGhpcywgdGhhbiB5b3Ugd2lsbCBhbHNvIGFncmVlIHRoYXQg
YWxsIFRFIFJvdXRlciBJRHMgDQpzaG91bGQgYmUgYWR2ZXJ0aXNlZCB3aXRoaW4gUm91dGVyIEFk
ZHJlc3MgVExWDQpIb3BlIHRoYXQgdGhpcyBoZWxwcy4NCiANCklnb3INCiANCiANCg0KDQoiT25n
LCBMeW5kb24iIDxMeW9uZ0BDaWVuYS5jb20+IHdyb3RlOg0KSGkgRGltaXRyaSwNCg0KVGhhdCB3
YXMgbXkgdW5kZXJzdGFuZGluZyBhbHNvLCBJIGRvbid0IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlz
Lg0KDQpDaGVlcnMsDQoNCkx5bmRvbiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRm
Lm9yZ10gT24gQmVoYWxmIA0KT2YgRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwtbHVjZW50
LmJlDQpTZW50OiBGcmlkYXksIE1hcmNoIDA5LCAyMDA3IDc6NTYgQU0NClRvOiBJZ29yIEJyeXNr
aW4NCkNjOiBjY2FtcEBvcHMuaWV0Zi5vcmc7IEJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTOyAN
Cm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0KU3ViamVjdDogVHdvIHF1ZXN0aW9ucyBvbiBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIA0KDQppZ29yDQoNCnRoZSBkcmFm
dHMgc2F5cw0KDQoiTm90ZTogVGhlIExpbmsgSUQgc3ViLVRMViB0aGF0IGlkZW50aWZpZXMgdGhl
IG90aGVyIGVuZCBvZiB0aGUgbGluayAoaS5lLiANCg0KUm91dGVyIElEIG9mIHRoZSBuZWlnaGJv
ciBmb3IgcG9pbnQtdG8tcG9pbnQgbGlua3MpIE1VU1QgYXBwZWFyIGV4YWN0bHkgDQpvbmNlIHBl
ciBMaW5rIFRMVi4gVGhpcyBzdWItVExWIE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGRlZmluZWQgaW4g
W1JGQzM2MzBdLiANCg0KIiANCg0Kd2hpY2ggaXMgZXhhY3RseSB3aGF0IHlvdSBhcmUgc2F5aW5n
IC0gd2hlbiBpIHNheSAiaXQgaWRlbnRpZmllcyB0aGUgDQpyZW1vdGUgUkMgbm90IHRoZSByZW1v
dGUgZGF0YSBwbGFuZSAibm9kZSIgaW4gY2FzZSB0aGUgcmVtb3RlIFJDIGlzIA0KYXNzb2NpYXRl
IHRvIG4gbm9kZXMiIHJlYWQgIml0IGlzIHNldCB0byB0aGUgcm91dGVyX2lkIHRoYXQgaWRlbnRp
ZmllcyB0aGUgDQpyZW1vdGUgUkMuLi4iDQppbiBicmllZiwgd2Uga2VlcCB0aGUgc2VtYW50aWMg
YW5kIGFkZCBhIGRpc2NyaW1pbmF0b3IgKHRoYXQgZG9lcyBub3QgDQphcHBseSBpbiBjYXNlIG9m
IGNvbG9jYXRlZCAxOjEgTFNSKSAtIHRoaXMgY2xvc2VzIHRoZSBmaXJzdCBwb2ludCAtDQoNCmNv
bmNlcm5pbmcgdGhlIHNlY29uZCBwb2ludCwgc2luY2UgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0
byBoYXZlIG11bHRpcGxlIA0KYXNzb2NpYXRpb25zIGluIGRpZmZlcmVudCBMU0FzIGkgZG9uJ3Qg
d2hlcmUgdGhlIHByb2JsZW0gaXMgPw0KDQp0aGFua3MsDQotZC4NCg0KDQoNCg0KDQpJZ29yIEJy
eXNraW4gDQpTZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCjA5LzAzLzIwMDcgMTY6
MDUNCg0KVG86IERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCmNjOiBj
Y2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUyIgDQoNClN1Ympl
Y3Q6IFJlOiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29u
LXJvdXRpbmctb3NwZiBkcmFmdA0KDQoNCkRpbWl0cmksDQoNCj4gSXMgdGhlIExpbmtJRCBpcyB0
aGUgc2FtZSBhcyBSZW1vdGUgVEUgUm91dGVyIElEPyANCg0Kbm8NCg0KPiBMaW5rSUQgdW5hbWJp
Z3Vvc2x5IGlkZW50aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUgbm9kZSwNCg0Kbm8sIGl0IGlkZW50
aWZpZXMgdGhlIHJlbW90ZSBSQyBub3QgdGhlIHJlbW90ZSBkYXRhIHBsYW5lICJub2RlIiBpbiBj
YXNlIA0KdGhlIHJlbW90ZSBSQyBpcyBhc3NvY2lhdGUgdG8gbiAibm9kZXMiDQoNCklCPj4gTm8s
IEkgZGlzYWdyZWUuIFlvdSBzZWUgdGhhdCdzIHdoeSBpdCdzIHNvIGltcG9ydGFudCB0byBxdW90
ZSB0aGUNClJGQ3MvZHJhZnRzLCBiZWNhdXNlIHBlb3BsZSBvZnRlbiBpbnRlcnByZXQgdGhlbSBk
aWZmZXJlbnRseS4NCg0KSW4gUkZDIDM2MzAgd2UgcmVhZDoNCiINCjIuNS4yLiBMaW5rIElEDQoN
Cg0KDQpUaGUgTGluayBJRCBzdWItVExWIGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0aGUg
bGluay4gRm9yDQoNCnBvaW50LXRvLXBvaW50IGxpbmtzLCB0aGlzIGlzIHRoZSBSb3V0ZXIgSUQg
b2YgdGhlIG5laWdoYm9yLg0KDQoiDQoNCk5vdGUgdGhhdCBpdCBkb2VzIG5vdCBzYXkgd2hldGhl
ciB0aGlzIGlzIHRoZSBhZHZlcnRpc2luZyBSb3V0ZXIgSUQgDQoNCihpZGVudGlmeWluZyBuZWln
aGJvciBSQykgb3IgVEUgUm91dGVyIElEIChpZGVudGlmeWluZyB0aGUNCm5laWdoYm9yIFRFIG5v
ZGUpLiBIb3dldmVyLCBpdCBkb2VzIHNheSB0aGF0IGl0ICJpZGVudGlmaWVzIHRoZSBvdGhlciBl
bmQgDQpvZiB0aGUgbGluayIuIEJlY2F1c2UgYSBsaW5rIGlzIHRlcm1pbmF0ZWQgYnkgVEUgbm9k
ZXMgKGFuZCBub3QgDQphZHZlcnRpc2luZyByb3V0ZXJzKSBJIGNvbmNsdWRlIHRoYXQgTGlua0lE
IGlkZW50aWZpZXMgdGhlIHJlbW90ZSBURSBub2RlLg0KDQpGdXJ0aGVybW9yZSwgZWFybGllciBp
biBSRkMgMzYzMCB3ZSByZWFkOg0KIg0KMi40LjEuIFJvdXRlciBBZGRyZXNzIFRMVg0KDQpUaGUg
Um91dGVyIEFkZHJlc3MgVExWIHNwZWNpZmllcyBhIHN0YWJsZSBJUCBhZGRyZXNzIG9mIHRoZQ0K
YWR2ZXJ0aXNpbmcgcm91dGVyIHRoYXQgaXMgYWx3YXlzIHJlYWNoYWJsZSBpZiB0aGVyZSBpcyBh
bnkNCmNvbm5lY3Rpdml0eSB0byBpdDsgdGhpcyBpcyB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYXMg
YSAibG9vcGJhY2sNCmFkZHJlc3MiLiBUaGUga2V5IGF0dHJpYnV0ZSBpcyB0aGF0IHRoZSBhZGRy
ZXNzIGRvZXMgbm90IGJlY29tZQ0KdW51c2FibGUgaWYgYW4NCmludGVyZmFjZSBpcyBkb3duLiBJ
biBvdGhlciBwcm90b2NvbHMsIHRoaXMgaXMga25vd24NCmFzIHRoZSAicm91dGVyIElEIg0KDQpJ
IGludGVycHJldCB0aGF0IHRoaXMgaXMgdGhlIHNhbWUgcm91dGVyIElEIGFzIGluIHRoZSB1cHBl
ciBxdW90ZS4gSXQgaXMgDQphZHZlcnRpc2VkIGluIHRoZSBSb3V0ZXIgQWRkcmVzcyBUTFYsIHdo
aWNoIGlzIHRoZSBvbmx5IHdheSB0b2RheSB0byANCmFkdmVydGlzZSBURSBSb3V0ZXIgSUQuIEhl
bmNlIHRoZSByb3V0ZXIgSUQgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBSRkMgaXMgDQp0aGUgVEUg
Um91dGVyIElELg0KDQpUaGUgY29uY2x1c2lvbiAjMTogdGhlIFRFIExpbmsgVExWLCBhcyBpdCBp
cyB0b2RheSwgYWx3YXlzIGNvbnRhaW5zIHRoZSBJRCANCg0Kb2YgdGhlIHJlbW90ZSBURSBub2Rl
LiANCg0KVGhlIGNvbmNsdXNpb24gIzI6IHRoZXJlIGlzIGEgbmVlZCB0byBhZHZlcnRpc2Ugc2V2
ZXJhbCBURSBSb3V0ZXIgSURzIA0Kc3VwcG9ydGVkIGJ5IHRoZSBzYW1lIFJDIChhZHZlcnRpc2lu
ZyByb3V0ZXIpLCB3aGljaCwgSSB0aGluaywgc2hvdWxkIGJlIA0KcHJvcG9zZWQgaW4geW91ciBk
cmFmdA0KDQpwczogc2Vjb25kIHF1ZXN0aW9uIGlzIHRyaXZpYWwsIG1hdGhlbWF0aWNhbCB2cyBu
ZXR3b3JraW5nIGZvcm11bGF0aW9uIChubyANCg0KDQpyZWFsIGRpZmZlcmVuY2UpDQoNCklCPj4g
V2VsbCwgaXQgY2hhbmdlcyBvbmUgb2YgdGhlIGZ1bmRhbWVudGFsIGRlZmluaXRpb25zIG9mIEcu
ODA4MCwgYW5kIEkgDQphbSBhc2tpbmcgd2h5IGlzIHRoYXQgaW4gdGhlIGRyYWZ0IHdoaWNoIGlz
IHN1cHBvc2VkIHRvIGRlZmluZSB3YXlzIHRvIA0Kc3VwcG9ydCBHLjgwODAgDQoNCklnb3INCg0K
cHBzOiBpZiB5b3Ugd2FudCB0byBwdXQgZ3VpZGVsaW5lcyBvbiBlLW1haWwgcmVzcG9uc2VzIHBy
b2JhYmx5IGRpcmVjdGluZyANCnlvdXIgZS1tYWlsIHRvIHRoZSBHRU4gQVJFQSB3b3VsZCBiZSBt
b3JlIHN1aXRhYmxlIA0KDQpob3BlIHRoaXMgaGVscHMsDQotZC4NCg0KDQoNCg0KSWdvciBCcnlz
a2luIA0KMDkvMDMvMjAwNyAwMDowMw0KDQpUbzogRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FM
Q0FURUxAQUxDQVRFTA0KY2M6IGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFo
IEEsIEFMQUJTIiANCg0KU3ViamVjdDogUmU6IFR3byBxdWVzdGlvbnMgb24gDQpkcmFmdC1kaW1p
dHJpLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRyYWZ0DQoNCg0KRGltaXRyaSwgbm8s
IGl0IGRvZXMgbm90IGhlbHAuDQoNCllvdSBkaWRuJ3QgYW5zd2VyIHRoZSBmaXJzdCBxdWVzdGlv
biwgd2hpY2ggaXM6DQoNCklzIHRoZSBMaW5rSUQgaXMgdGhlIHNhbWUgYXMgUmVtb3RlIFRFIFJv
dXRlciBJRD8gSWYgbm8sIHdoYXQgaXMgdGhlIA0KZGlmZmVyZW5jZT8gSWYgeWVzLCB3aHkgZG8g
eW91IG5lZWQgdGhlIGxhdHRlcj8gQm90aCB5b3VyIHBvaW50ZXJzIGV4cGxhaW4gDQoNCg0Kd2h5
IGRvIHlvdSBuZWVkIGFkdmVydGlzaW5nIG9mIHRoZSBsb2NhbCBURSBSb3V0ZXIgSUQgKGFkdmVy
dGlzaW5nIHJvdXRlciANCm1heSBjb3ZlciBtdWx0aXBsZSBkYXRhIHBsYW5lIG5vZGVzKSwgSG93
ZXZlciwgTGlua0lEIHVuYW1iaWd1b3NseSANCmlkZW50aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUg
bm9kZSwgYW5kIHRoZSBuZWVkIGZvciB0aGUgYWR2ZXJ0aXNpbmcgb2YgDQpSZW1vdGUgVEUgUm91
dGVyIElEIGlzIG5vdCBvYnZpb3VzDQoNCkJUVywgWW91IGRpZG4ndCBhbnN3ZXIgdGhlIHNlY29u
ZCBxdWVzdGlvbiBlaXRoZXIuDQoNCklnb3INCg0KUFMsIEkgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9y
IHRoZSB3b3JraW5nIGdyb3VwOiBMZXQgdXMgZGlzYWxsb3cgcmVzcG9uZGluZyANCnRvIHRoZSBj
b21tZW50cy9xdWVzdGlvbnMgYnkganVzdCBwb2ludGluZyB0byBSRkNzIG9yIGRyYWZ0cy4gSW4g
bXkgdmlldyANCml0IGlzIHF1aXRlIHVuZnJpZW5kbHkuIEl0IGlzIGFsd2F5cyBwb3NzaWJsZSB0
byBjdXQgYW5kIHBhc3RlIGEgcGllY2UgDQpmcm9tIHRoZSByZWxldmFudCBSRkMgb3IgZHJhZnQg
Y29uZmlybWluZyB0aGUgcG9pbnRzIHRoZSB3cml0ZXIgaXMgdHJ5aW5nIA0KdG8gbWFrZS4NCg0K
RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwtbHVjZW50LmJlIHdyb3RlOg0KaWdvcg0KDQoN
CnBscyB1c2UgdmVyc2lvbiAob3IgMDMgDQp3aGVuIGF2YWlsYWJsZSB0byBtYWtlIGNvbW1lbnRz
KQ0KDQppbiB0aGF0IHZlcnNpb24geW91IHdpbGwgc2VlIGluIFNlY3Rpb24gNS4yDQoNCiIgTm90
ZTogVGhlIExpbmsgSUQgc3ViLVRMViB0aGF0IGlkZW50aWZpZXMgdGhlIG90aGVyIGVuZCBvZiB0
aGUgbGluayANCihpLmUuIFJvdXRlciBJRCBvZiB0aGUgbmVpZ2hib3IgZm9yIHBvaW50LXRvLXBv
aW50IGxpbmtzKSBNVVNUIA0KYXBwZWFyIGV4YWN0bHkgb25jZSBwZXIgTGluayBUTFYuIFRoaXMg
c3ViLVRMViBNVVNUIGJlIHByb2Nlc3NlZCBhcyANCmRlZmluZWQgaW4gW1JGQzM2MzBdLiAiDQoN
Cm5vdyB3aHkgdGhpcyBzdWItVExWIDE3LCB3ZWxsIGZvciB0aGUgcmVhc29uIGV4cGxhaW5lZCBh
dCB0aGUgYmVnaW5uaW5nIG9mIA0KDQoNCg0KcGFyLjUuMg0KYnV0IGFsc28gaW4gUkZDIDQ2NTIg
U2VjdGlvbiA1LjcNCg0KaG9wZSB0aGlzIGhlbHBzLA0KLWQuDQoNCg0KDQoNCklnb3IgQnJ5c2tp
biANCjA4LzAzLzIwMDcgMjI6MTENCg0KVG86IERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENB
VEVMQEFMQ0FURUwNCmNjOiBjY2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVuZ2FyZCwgRGVib3JhaCBB
LCBBTEFCUyIgDQoNClN1YmplY3Q6IFR3byBxdWVzdGlvbnMgb24gDQpkcmFmdC1kaW1pdHJpLWNj
YW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRyYWZ0DQoNCg0KRGltaXRyaSwNCkkgaGF2ZSBh
IGNvdXBsZSBxdWVzdGlvbnMgd3J0IHRoZSANCmRyYWZ0LWRpbWl0cmktY2NhbXAtZ21wbHMtYXNv
bi1yb3V0aW5nLW9zcGYgZHJhZnQuDQpJbiA1LjIgYSBURSBMaW5rIHN1Yi1UTFYgaXMgaW50cm9k
dWNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYWR2ZXJ0aXNpbmcgDQpsb2NhbCBhbmQgcmVtb3RlIFRF
IFJvdXRlciBJRDoNCg0KMCAxIDIgMyANCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg
NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCistKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KfCAxNyB8IExlbmd0
aCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSsgDQp8IExvY2FsIFRFIFJvdXRlciBJZGVudGlmaWVyIHwgDQorLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
KyANCnwgUmVtb3RlIFRFIFJvdXRlciBJZGVudGlmaWVyIHwgDQorLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCg0KQWx0aG91
Z2ggSSBkbyB1bmRlcnN0YW5kIHdoeSB0aGVyZSBpcyBhIG5lZWQgZm9yIGFkdmVydGlzaW5nIHRo
ZSBMb2NhbCBURSANClJvdXRlciBJRCwgSSBkb27Dg8Kiw6InwqzDoiLConQgdW5kZXJzdGFuZCB3
aHkgdGhlIFJlbW90ZSBUZSBSb3V0ZXIgSUQ/IA0KSXNuw4PCosOiJ8Ksw6IiwqJ0IA0KdGhpcyBp
cyANCnRoZSBzYW1lDQppbmZvcm1hdGlvbiANCnRoYXQgaXMgY2FycmllZCBpbiB0aGUgTGluayBJ
RCBzdWItVExWPw0KSW4gNi4geW91IHdyaXRlOg0KDQrDg8Kiw6InwqzDhSJBIFJBIG1heSBjb250
YWluIHNtYWxsZXIgUkFzIGludGVyLWNvbm5lY3RlZCBieSBsaW5rcy4gDQpUaGUgbGltaXQgb2Yg
dGhlIHN1YmRpdmlzaW9uIHJlc3VsdHMgaW4NCmEgUkEgdGhhdCBjb250YWlucyB0d28gc3ViLW5l
dHdvcmtzIGludGVyY29ubmVjdGVkIGJ5IGEgc2luZ2xlIA0KbGluay7Dg8Kiw6InwqzDgsKdDQoN
CkluIEcuODA4MCBJIHJlYWQ6DQrDg8Kiw6InwqzDhSIuLi4uIEEgcm91dGluZyBhcmVhIGlzIGRl
ZmluZWQgYnkgYSBzZXQgb2Ygc3VibmV0d29ya3MsIHRoZSBTTlBQIA0KbGlua3MgDQoNCnRoYXQg
aW50ZXJjb25uZWN0IHRoZW0sIGFuZCB0aGUgU05QUHMgcmVwcmVzZW50aW5nIHRoZSBlbmRzIG9m
IHRoZSBTTlBQIA0KbGlua3MgZXhpdGluZyB0aGF0IHJvdXRpbmcgYXJlYS4gQSByb3V0aW5nIGFy
ZWEgbWF5IGNvbnRhaW4gc21hbGxlciANCnJvdXRpbmcgYXJlYXMgaW50ZXJjb25uZWN0ZWQgYnkg
U05QUCBsaW5rcy4gVGhlIGxpbWl0IG9mIHN1YmRpdmlzaW9uIA0KcmVzdWx0cyBpbiBhIHJvdXRp
bmcgYXJlYSB0aGF0IGNvbnRhaW5zIF1vbmUgc3VibmV0d29yay7Dg8Kiw6InwqzDgsKdDQoNCldo
eSBpcyB0aGUgZGlzY3JlcGFuY3k/DQoNClRoYW5rcywNCklnb3INCg0KDQpbDQpTdWNrZXItcHVu
Y2ggc3BhbSB3aXRoIGF3YXJkLXdpbm5pbmcgcHJvdGVjdGlvbi4NClRyeSB0aGUgZnJlZSBZYWhv
byEgTWFpbCBCZXRhLg0KDQoNCk5vdyB0aGF0J3Mgcm9vbSBzZXJ2aWNlISBDaG9vc2UgZnJvbSBv
dmVyIDE1MCwwMDAgaG90ZWxzIA0KaW4gNDUsMDAwIGRlc3RpbmF0aW9ucyBvbiBZYWhvbyEgVHJh
dmVsIHRvIGZpbmQgeW91ciBmaXQuDQoNCg0KDQpTdWNrZXItcHVuY2ggc3BhbSB3aXRoIGF3YXJk
LXdpbm5pbmcgcHJvdGVjdGlvbi4NClRyeSB0aGUgZnJlZSBZYWhvbyEgTWFpbCBCZXRhLg0KDQoN
CiANCiBHZXQgeW91ciBvd24gd2ViIGFkZHJlc3MuDQpIYXZlIGEgSFVHRSB5ZWFyIHRocm91Z2gg
WWFob28hIFNtYWxsIEJ1c2luZXNzLg0KDQo=



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 20:48:16 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, [e-mail]
Subject: RE: New communication from the OIF
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 9 Mar 2007 21:46:24 +0100
Content-Type: text/plain; charset="US-ASCII"

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" <[e-mail]>
09/03/2007 19:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[e-mail]>, 
<[e-mail]>, "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, 
"MEURIC Julien RD-CORE-LAN" <[e-mail]>, 
<[e-mail]>
        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: [e-mail]
[mailto:[e-mail]] 
Sent: Wednesday, March 07, 2007 4:27 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; BRUNGARD, DEBORAH A, ATTLABS;
MEURIC Julien RD-CORE-LAN; [e-mail]
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" <[e-mail]>
Sent by: [e-mail]
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, 
"Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" 
<[e-mail]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>
        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:[e-mail]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail], 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





Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 19:30:48 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lH59bw17hSOdsoDVeP/CH+0UZxQ22Ym/rxH7bWhHdw/NaVrjZmMAK4Tothr91TMI3Z2y1/IdxO3BTtlUnvoqEEzSQp6k84X+pcOt5K/GZ7T/jOJXitzLEUBzwToSqoHQJdUbp1vg24s6CFCqrj/GbOlrrtkrLGtj7gP0v0MYpOM=;
Date: Fri, 9 Mar 2007 11:29:17 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
To: "Ong, Lyndon" <[e-mail]>, [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1600286524-1173468557=:45458"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

--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" <[e-mail]> wrote:
  Hi Dimitri,
 
 That was my understanding also, I don't see any issue with this.
 
 Cheers,
 
 Lyndon 
 
 -----Original Message-----
 From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
 Sent: Friday, March 09, 2007 7:56 AM
 To: Igor Bryskin
 Cc: [e-mail]; Brungard, Deborah A, ALABS; [e-mail]
 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: [e-mail]
 09/03/2007 16:05
 
 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
 cc: [e-mail], "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: [e-mail], "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.
 
 [e-mail] 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: [e-mail], "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;[e-mail]&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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]<br> Sent: Friday, March 09, 2007 7:56 AM<br> To: <st1:PersonName w:st="on">Igor Bryskin</st1:PersonName><br> Cc: [e-mail]; Brungard, Deborah A, ALABS; [e-mail]<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> <[e-mail]>Sent by: [e-mail]<br> 09/03/2007 16:05<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [e-mail], "Brungard, Deborah A, ALABS" <br> <br> <[e-mail]>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: [e-mail], "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> [e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 18:29:57 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New communication from the OIF
Date: Fri, 9 Mar 2007 13:29:03 -0500
Message-ID: <[e-mail]>
Thread-Topic: New communication from the OIF
thread-index: AcdhGJs8Q55rjPcBQRqgAiexB0313AAwUGQg
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>

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: [e-mail]
[mailto:[e-mail]]=20
Sent: Wednesday, March 07, 2007 4:27 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [e-mail]; BRUNGARD, DEBORAH A, ATTLABS;
MEURIC Julien RD-CORE-LAN; [e-mail]
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" <[e-mail]>
Sent by: [e-mail]
08/03/2007 00:28
=20
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>,=20
"Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN"=20
<[e-mail]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>
        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:[e-mail]]=20
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail], 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



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 18:29:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
Date: Fri, 9 Mar 2007 13:22:23 -0500
Message-ID: <[e-mail]>
Thread-Topic: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
thread-index: AcdiZJayIrbSAqAIRcuA2I0DinCWSgAEzKwg
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>

Hi Dimitri,

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

Cheers,

Lyndon=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On =
Behalf Of [e-mail]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [e-mail]; Brungard, Deborah A, ALABS; =
[e-mail]
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 <[e-mail]>
Sent by: [e-mail]
09/03/2007 16:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail], "Brungard, Deborah A, ALABS"=20
<[e-mail]>
        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: [e-mail], "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.

[e-mail] 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: [e-mail], "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.



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 18:14:28 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xAvc16ICVSJxTcxRnwZ2xwHf17WAB5aKMWWHM8DP90bD303K8yaM7cJMxnG1GCM8s3edHi1Oh18Nx5vVL0dKHNsYLUoh4D1lP8BwUxsoQYjxdObhJpwRezrLvRfrfEySiJP7KrIG2rOMH5IH+4+o1Q26TTLdzTlkCazyzL+Lrhs=  ;
Message-ID: <[e-mail]>
Date: Fri, 9 Mar 2007 10:13:19 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
To: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-635280490-1173463999=:55319"
Content-Transfer-Encoding: 8bit

--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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [e-mail]; BRUNGARD, DEBORAH A, ATTLABS; [e-mail]
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: [e-mail]
09/03/2007 16:05
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail], "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: [e-mail], "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.

[e-mail] 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: [e-mail], "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;[e-mail]&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: [e-mail] [mailto:[e-mail]] <br>Sent: Friday, March 09, 2007 10:56 AM<br>To: Igor Bryskin<br>Cc: [e-mail]; BRUNGARD, DEBORAH A, ATTLABS; [e-mail]<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
 <[e-mail]><br>Sent by: [e-mail]<br>09/03/2007 16:05<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail], "Brungard, Deborah A, ALABS" <br><[e-mail]><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: [e-mail], "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>[e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 17:35:12 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
Date: Fri, 9 Mar 2007 11:33:42 -0600
Message-ID: <[e-mail]>
Thread-Topic: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
Thread-Index: AcdiY4pW+jwPHP13TKWVfZ98DTSzMQABfzOw
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

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: [e-mail] =
[mailto:[e-mail]]=20
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [e-mail]; BRUNGARD, DEBORAH A, ATTLABS; =
[e-mail]
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 <[e-mail]>
Sent by: [e-mail]
09/03/2007 16:05
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail], "Brungard, Deborah A, ALABS"=20
<[e-mail]>
        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: [e-mail], "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.

[e-mail] 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: [e-mail], "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.




Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 15:57:19 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf  
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 9 Mar 2007 16:56:29 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvcg0KDQp0aGUgZHJhZnRzIHNheXMNCg0KIk5vdGU6IFRoZSBMaW5rIElEIHN1Yi1UTFYgdGhh
dCBpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgb2YgdGhlIGxpbmsgKGkuZS4gDQpSb3V0ZXIgSUQg
b2YgdGhlIG5laWdoYm9yIGZvciBwb2ludC10by1wb2ludCBsaW5rcykgTVVTVCBhcHBlYXIgZXhh
Y3RseSANCm9uY2UgcGVyIExpbmsgVExWLiBUaGlzIHN1Yi1UTFYgTVVTVCBiZSBwcm9jZXNzZWQg
YXMgZGVmaW5lZCBpbiBbUkZDMzYzMF0uIA0KIiANCg0Kd2hpY2ggaXMgZXhhY3RseSB3aGF0IHlv
dSBhcmUgc2F5aW5nIC0gd2hlbiBpIHNheSAiaXQgaWRlbnRpZmllcyB0aGUgDQpyZW1vdGUgUkMg
bm90IHRoZSByZW1vdGUgZGF0YSBwbGFuZSAibm9kZSIgaW4gY2FzZSB0aGUgcmVtb3RlIFJDIGlz
IA0KYXNzb2NpYXRlIHRvIG4gbm9kZXMiIHJlYWQgIml0IGlzIHNldCB0byB0aGUgcm91dGVyX2lk
IHRoYXQgaWRlbnRpZmllcyB0aGUgDQpyZW1vdGUgUkMuLi4iDQppbiBicmllZiwgd2Uga2VlcCB0
aGUgc2VtYW50aWMgYW5kIGFkZCBhIGRpc2NyaW1pbmF0b3IgKHRoYXQgZG9lcyBub3QgDQphcHBs
eSBpbiBjYXNlIG9mIGNvbG9jYXRlZCAxOjEgTFNSKSAtIHRoaXMgY2xvc2VzIHRoZSBmaXJzdCBw
b2ludCAtDQoNCmNvbmNlcm5pbmcgdGhlIHNlY29uZCBwb2ludCwgc2luY2UgdGhlcmUgaXMgYSBw
b3NzaWJpbGl0eSB0byBoYXZlIG11bHRpcGxlIA0KPFJvdXRlcl9JRCwgVEUgUm91dGVyX0lEPiBh
c3NvY2lhdGlvbnMgaW4gZGlmZmVyZW50IExTQXMgaSBkb24ndCB3aGVyZSB0aGUgDQpwcm9ibGVt
IGlzID8NCg0KdGhhbmtzLA0KLWQuDQoNCg0KDQoNCg0KSWdvciBCcnlza2luIDxpX2JyeXNraW5A
eWFob28uY29tPg0KU2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnDQowOS8wMy8yMDA3
IDE2OjA1DQogDQogICAgICAgIFRvOiAgICAgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FU
RUxAQUxDQVRFTA0KICAgICAgICBjYzogICAgIGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJk
LCBEZWJvcmFoIEEsIEFMQUJTIiANCjxkYnJ1bmdhcmRAYXR0LmNvbT4NCiAgICAgICAgU3ViamVj
dDogICAgICAgIFJlOiBUd28gcXVlc3Rpb25zIG9uIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBs
cy1hc29uLXJvdXRpbmctb3NwZiBkcmFmdA0KDQoNCkRpbWl0cmksDQoNCj4gSXMgdGhlIExpbmtJ
RCBpcyB0aGUgc2FtZSBhcyBSZW1vdGUgVEUgUm91dGVyIElEPyANCg0Kbm8NCg0KPiBMaW5rSUQg
dW5hbWJpZ3Vvc2x5IGlkZW50aWZpZXMgcmVtb3RlIGRhdGEgcGxhbmUgbm9kZSwNCg0Kbm8sIGl0
IGlkZW50aWZpZXMgdGhlIHJlbW90ZSBSQyBub3QgdGhlIHJlbW90ZSBkYXRhIHBsYW5lICJub2Rl
IiBpbiBjYXNlIA0KdGhlIHJlbW90ZSBSQyBpcyBhc3NvY2lhdGUgdG8gbiAibm9kZXMiDQoNCklC
Pj4gTm8sIEkgZGlzYWdyZWUuIFlvdSBzZWUgdGhhdCdzIHdoeSBpdCdzIHNvIGltcG9ydGFudCB0
byBxdW90ZSB0aGUgDQpSRkNzL2RyYWZ0cywgYmVjYXVzZSBwZW9wbGUgb2Z0ZW4gaW50ZXJwcmV0
IHRoZW0gZGlmZmVyZW50bHkuDQoNCkluIFJGQyAzNjMwIHdlIHJlYWQ6DQoiDQoyLjUuMi4gIExp
bmsgSUQNCg0KDQoNCiAgIFRoZSBMaW5rIElEIHN1Yi1UTFYgaWRlbnRpZmllcyB0aGUgb3RoZXIg
ZW5kIG9mIHRoZSBsaW5rLiAgRm9yDQoNCiAgIHBvaW50LXRvLXBvaW50IGxpbmtzLCB0aGlzIGlz
IHRoZSBSb3V0ZXIgSUQgb2YgdGhlIG5laWdoYm9yLg0KDQoiDQoNCk5vdGUgdGhhdCBpdCBkb2Vz
IG5vdCBzYXkgd2hldGhlciB0aGlzIGlzIHRoZSBhZHZlcnRpc2luZyBSb3V0ZXIgSUQgDQoNCihp
ZGVudGlmeWluZyBuZWlnaGJvciBSQykgb3IgVEUgUm91dGVyIElEIChpZGVudGlmeWluZyB0aGUN
CiBuZWlnaGJvciBURSBub2RlKS4gSG93ZXZlciwgaXQgZG9lcyBzYXkgdGhhdCBpdCDigJxpZGVu
dGlmaWVzIHRoZSBvdGhlciBlbmQgDQpvZiB0aGUgbGlua+KAnS4gQmVjYXVzZSBhIGxpbmsgaXMg
dGVybWluYXRlZCBieSBURSBub2RlcyAoYW5kIG5vdCANCmFkdmVydGlzaW5nIHJvdXRlcnMpIEkg
Y29uY2x1ZGUgdGhhdCBMaW5rSUQgaWRlbnRpZmllcyB0aGUgcmVtb3RlIFRFIG5vZGUuDQogDQpG
dXJ0aGVybW9yZSwgZWFybGllciBpbiBSRkMgMzYzMCB3ZSByZWFkOg0K4oCcDQoyLjQuMS4gIFJv
dXRlciBBZGRyZXNzIFRMVg0KIA0KICAgVGhlIFJvdXRlciBBZGRyZXNzIFRMViBzcGVjaWZpZXMg
YSBzdGFibGUgSVAgYWRkcmVzcyBvZiB0aGUNCiAgIGFkdmVydGlzaW5nIHJvdXRlciB0aGF0IGlz
IGFsd2F5cyByZWFjaGFibGUgaWYgdGhlcmUgaXMgYW55DQogICBjb25uZWN0aXZpdHkgdG8gaXQ7
IHRoaXMgaXMgdHlwaWNhbGx5IGltcGxlbWVudGVkIGFzIGEgImxvb3BiYWNrDQogICBhZGRyZXNz
Ii4gIFRoZSBrZXkgYXR0cmlidXRlIGlzIHRoYXQgdGhlIGFkZHJlc3MgZG9lcyBub3QgYmVjb21l
DQogICB1bnVzYWJsZSBpZiBhbg0KIGludGVyZmFjZSBpcyBkb3duLiAgSW4gb3RoZXIgcHJvdG9j
b2xzLCB0aGlzIGlzIGtub3duDQogICBhcyB0aGUgInJvdXRlciBJRCINCiANCkkgaW50ZXJwcmV0
IHRoYXQgdGhpcyBpcyB0aGUgc2FtZSByb3V0ZXIgSUQgYXMgaW4gdGhlIHVwcGVyIHF1b3RlLiBJ
dCBpcyANCmFkdmVydGlzZWQgaW4gdGhlIFJvdXRlciBBZGRyZXNzIFRMViwgd2hpY2ggaXMgdGhl
IG9ubHkgd2F5IHRvZGF5IHRvIA0KYWR2ZXJ0aXNlIFRFIFJvdXRlciBJRC4gSGVuY2UgdGhlIHJv
dXRlciBJRCBpbiB0aGUgY29udGV4dCBvZiB0aGlzIFJGQyBpcyANCnRoZSBURSBSb3V0ZXIgSUQu
DQogDQpUaGUgY29uY2x1c2lvbiAjMTogdGhlIFRFIExpbmsgVExWLCBhcyBpdCBpcyB0b2RheSwg
YWx3YXlzIGNvbnRhaW5zIHRoZSBJRCANCm9mIHRoZSByZW1vdGUgVEUgbm9kZS4gDQogDQpUaGUg
Y29uY2x1c2lvbiAjMjogdGhlcmUgaXMgYSBuZWVkIHRvIGFkdmVydGlzZSBzZXZlcmFsIFRFIFJv
dXRlciBJRHMgDQpzdXBwb3J0ZWQgYnkgdGhlIHNhbWUgUkMgKGFkdmVydGlzaW5nIHJvdXRlciks
IHdoaWNoLCBJIHRoaW5rLCBzaG91bGQgYmUgDQpwcm9wb3NlZCBpbiB5b3VyIGRyYWZ0DQogDQpw
czogc2Vjb25kIHF1ZXN0aW9uIGlzIHRyaXZpYWwsIG1hdGhlbWF0aWNhbCB2cyBuZXR3b3JraW5n
IGZvcm11bGF0aW9uIChubyANCg0KcmVhbCBkaWZmZXJlbmNlKQ0KIA0KSUI+PiBXZWxsLCBpdCBj
aGFuZ2VzIG9uZSBvZiB0aGUgZnVuZGFtZW50YWwgZGVmaW5pdGlvbnMgb2YgRy44MDgwLCBhbmQg
SSANCmFtIGFza2luZyB3aHkgaXMgdGhhdCBpbiB0aGUgZHJhZnQgd2hpY2ggaXMgc3VwcG9zZWQg
dG8gZGVmaW5lIHdheXMgdG8gDQpzdXBwb3J0IEcuODA4MCANCiANCklnb3INCg0KcHBzOiBpZiB5
b3Ugd2FudCB0byBwdXQgZ3VpZGVsaW5lcyBvbiBlLW1haWwgcmVzcG9uc2VzIHByb2JhYmx5IGRp
cmVjdGluZyANCnlvdXIgZS1tYWlsIHRvIHRoZSBHRU4gQVJFQSB3b3VsZCBiZSBtb3JlIHN1aXRh
YmxlIA0KDQpob3BlIHRoaXMgaGVscHMsDQotZC4NCg0KDQoNCg0KSWdvciBCcnlza2luIA0KMDkv
MDMvMjAwNyAwMDowMw0KDQpUbzogRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxD
QVRFTA0KY2M6IGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJT
IiANCg0KU3ViamVjdDogUmU6IFR3byBxdWVzdGlvbnMgb24gDQpkcmFmdC1kaW1pdHJpLWNjYW1w
LWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRyYWZ0DQoNCg0KRGltaXRyaSwgbm8sIGl0IGRvZXMg
bm90IGhlbHAuDQoNCllvdSBkaWRuJ3QgYW5zd2VyIHRoZSBmaXJzdCBxdWVzdGlvbiwgd2hpY2gg
aXM6DQoNCklzIHRoZSBMaW5rSUQgaXMgdGhlIHNhbWUgYXMgUmVtb3RlIFRFIFJvdXRlciBJRD8g
SWYgbm8sIHdoYXQgaXMgdGhlIA0KZGlmZmVyZW5jZT8gSWYgeWVzLCB3aHkgZG8geW91IG5lZWQg
dGhlIGxhdHRlcj8gQm90aCB5b3VyIHBvaW50ZXJzIGV4cGxhaW4gDQoNCndoeSBkbyB5b3UgbmVl
ZCBhZHZlcnRpc2luZyBvZiB0aGUgbG9jYWwgVEUgUm91dGVyIElEIChhZHZlcnRpc2luZyByb3V0
ZXIgDQptYXkgY292ZXIgbXVsdGlwbGUgZGF0YSBwbGFuZSBub2RlcyksIEhvd2V2ZXIsIExpbmtJ
RCB1bmFtYmlndW9zbHkgDQppZGVudGlmaWVzIHJlbW90ZSBkYXRhIHBsYW5lIG5vZGUsIGFuZCB0
aGUgbmVlZCBmb3IgdGhlIGFkdmVydGlzaW5nIG9mIA0KUmVtb3RlIFRFIFJvdXRlciBJRCBpcyBu
b3Qgb2J2aW91cw0KDQpCVFcsIFlvdSBkaWRuJ3QgYW5zd2VyIHRoZSBzZWNvbmQgcXVlc3Rpb24g
ZWl0aGVyLg0KDQpJZ29yDQoNClBTLCBJIGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGUgd29ya2lu
ZyBncm91cDogTGV0IHVzIGRpc2FsbG93IHJlc3BvbmRpbmcgDQp0byB0aGUgY29tbWVudHMvcXVl
c3Rpb25zIGJ5IGp1c3QgcG9pbnRpbmcgdG8gUkZDcyBvciBkcmFmdHMuIEluIG15IHZpZXcgDQpp
dCBpcyBxdWl0ZSB1bmZyaWVuZGx5LiBJdCBpcyBhbHdheXMgcG9zc2libGUgdG8gY3V0IGFuZCBw
YXN0ZSBhIHBpZWNlIA0KZnJvbSB0aGUgcmVsZXZhbnQgUkZDIG9yIGRyYWZ0IGNvbmZpcm1pbmcg
dGhlIHBvaW50cyB0aGUgd3JpdGVyIGlzIHRyeWluZyANCnRvIG1ha2UuDQoNCkRpbWl0cmkuUGFw
YWRpbWl0cmlvdUBhbGNhdGVsLWx1Y2VudC5iZSB3cm90ZToNCmlnb3INCg0KDQpwbHMgdXNlIHZl
cnNpb24gKG9yIDAzIA0Kd2hlbiBhdmFpbGFibGUgdG8gbWFrZSBjb21tZW50cykNCg0KaW4gdGhh
dCB2ZXJzaW9uIHlvdSB3aWxsIHNlZSBpbiBTZWN0aW9uIDUuMg0KDQoiIE5vdGU6IFRoZSBMaW5r
IElEIHN1Yi1UTFYgdGhhdCBpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgb2YgdGhlIGxpbmsgDQoo
aS5lLiBSb3V0ZXIgSUQgb2YgdGhlIG5laWdoYm9yIGZvciBwb2ludC10by1wb2ludCBsaW5rcykg
TVVTVCANCmFwcGVhciBleGFjdGx5IG9uY2UgcGVyIExpbmsgVExWLiBUaGlzIHN1Yi1UTFYgTVVT
VCBiZSBwcm9jZXNzZWQgYXMgDQpkZWZpbmVkIGluIFtSRkMzNjMwXS4gIg0KDQpub3cgd2h5IHRo
aXMgc3ViLVRMViAxNywgd2VsbCBmb3IgdGhlIHJlYXNvbiBleHBsYWluZWQgYXQgdGhlIGJlZ2lu
bmluZyBvZiANCg0KDQpwYXIuNS4yDQpidXQgYWxzbyBpbiBSRkMgNDY1MiBTZWN0aW9uIDUuNw0K
DQpob3BlIHRoaXMgaGVscHMsDQotZC4NCg0KDQoNCg0KSWdvciBCcnlza2luIA0KMDgvMDMvMjAw
NyAyMjoxMQ0KDQpUbzogRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0K
Y2M6IGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTIiANCg0K
U3ViamVjdDogVHdvIHF1ZXN0aW9ucyBvbiANCmRyYWZ0LWRpbWl0cmktY2NhbXAtZ21wbHMtYXNv
bi1yb3V0aW5nLW9zcGYgZHJhZnQNCg0KDQpEaW1pdHJpLA0KSSBoYXZlIGEgY291cGxlIHF1ZXN0
aW9ucyB3cnQgdGhlIA0KZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctb3Nw
ZiBkcmFmdC4NCkluIDUuMiBhIFRFIExpbmsgc3ViLVRMViBpcyBpbnRyb2R1Y2VkIGZvciB0aGUg
cHVycG9zZSBvZiBhZHZlcnRpc2luZyANCmxvY2FsIGFuZCByZW1vdGUgVEUgUm91dGVyIElEOg0K
DQowIDEgMiAzIA0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy
IDMgNCA1IDYgNyA4IDkgMCAxIA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IDE3IHwgTGVuZ3RoIHwgDQorLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
KyANCnwgTG9jYWwgVEUgUm91dGVyIElkZW50aWZpZXIgfCANCistKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KfCBSZW1vdGUg
VEUgUm91dGVyIElkZW50aWZpZXIgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KDQpBbHRob3VnaCBJIGRvIHVuZGVy
c3RhbmQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWR2ZXJ0aXNpbmcgdGhlIExvY2FsIFRFIA0K
Um91dGVyIElELCBJIGRvbsODwqLDouKAmsKsw6LigJ7ConQgdW5kZXJzdGFuZCB3aHkgdGhlIFJl
bW90ZSBUZSBSb3V0ZXIgSUQ/IA0KSXNuw4PCosOi4oCawqzDouKAnsKidCANCnRoaXMgaXMgDQp0
aGUgc2FtZQ0KaW5mb3JtYXRpb24gDQp0aGF0IGlzIGNhcnJpZWQgaW4gdGhlIExpbmsgSUQgc3Vi
LVRMVj8NCkluIDYuIHlvdSB3cml0ZToNCg0Kw4PCosOi4oCawqzDheKAnEEgUkEgbWF5IGNvbnRh
aW4gc21hbGxlciBSQXMgaW50ZXItY29ubmVjdGVkIGJ5IGxpbmtzLiANClRoZSBsaW1pdCBvZiB0
aGUgc3ViZGl2aXNpb24gcmVzdWx0cyBpbg0KYSBSQSB0aGF0IGNvbnRhaW5zIHR3byBzdWItbmV0
d29ya3MgaW50ZXJjb25uZWN0ZWQgYnkgYSBzaW5nbGUgDQpsaW5rLsODwqLDouKAmsKsw4LCnQ0K
DQpJbiBHLjgwODAgSSByZWFkOg0Kw4PCosOi4oCawqzDheKAnC4uLi4gQSByb3V0aW5nIGFyZWEg
aXMgZGVmaW5lZCBieSBhIHNldCBvZiBzdWJuZXR3b3JrcywgdGhlIFNOUFAgDQpsaW5rcyANCg0K
dGhhdCBpbnRlcmNvbm5lY3QgdGhlbSwgYW5kIHRoZSBTTlBQcyByZXByZXNlbnRpbmcgdGhlIGVu
ZHMgb2YgdGhlIFNOUFAgDQpsaW5rcyBleGl0aW5nIHRoYXQgcm91dGluZyBhcmVhLiBBIHJvdXRp
bmcgYXJlYSBtYXkgY29udGFpbiBzbWFsbGVyIA0Kcm91dGluZyBhcmVhcyBpbnRlcmNvbm5lY3Rl
ZCBieSBTTlBQIGxpbmtzLiBUaGUgbGltaXQgb2Ygc3ViZGl2aXNpb24gDQpyZXN1bHRzIGluIGEg
cm91dGluZyBhcmVhIHRoYXQgY29udGFpbnMgXW9uZSBzdWJuZXR3b3JrLsODwqLDouKAmsKsw4LC
nQ0KDQpXaHkgaXMgdGhlIGRpc2NyZXBhbmN5Pw0KDQpUaGFua3MsDQpJZ29yDQoNCg0KWw0KU3Vj
a2VyLXB1bmNoIHNwYW0gd2l0aCBhd2FyZC13aW5uaW5nIHByb3RlY3Rpb24uDQpUcnkgdGhlIGZy
ZWUgWWFob28hIE1haWwgQmV0YS4NCg0KDQpOb3cgdGhhdCdzIHJvb20gc2VydmljZSEgQ2hvb3Nl
IGZyb20gb3ZlciAxNTAsMDAwIGhvdGVscyANCmluIDQ1LDAwMCBkZXN0aW5hdGlvbnMgb24gWWFo
b28hIFRyYXZlbCB0byBmaW5kIHlvdXIgZml0Lg0KDQoNCiANCiBTdWNrZXItcHVuY2ggc3BhbSB3
aXRoIGF3YXJkLXdpbm5pbmcgcHJvdGVjdGlvbi4NClRyeSB0aGUgZnJlZSBZYWhvbyEgTWFpbCBC
ZXRhLg0KDQo=



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 15:07:33 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y9KUu5NBZ5aqMZp+atovJzV27nS9W9Sq82gqbwp4aD2TAMmUR5S8zlNo1yEv0Ari6qe2ZgD4Bymcm1pX0vbeXdqw9hGO8GVVsRKv9ZwsMv4n9TST96AyB0H4cBP3Yf56+OX5EygEHdzzI1/G9z+sf0jmrrZuMQUTYXsckfCYD8s=  ;
Message-ID: <[e-mail]>
Date: Fri, 9 Mar 2007 07:05:02 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-421440143-1173452702=:92923"
Content-Transfer-Encoding: 8bit

--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: [e-mail], "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.
 
 [e-mail] 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: [e-mail], "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> <[e-mail]>09/03/2007 00:03<br> <br> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br> cc: [e-mail], "Brungard, Deborah A, ALABS" <br> <br> <[e-mail]>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> [e-mail] 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: [e-mail], "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></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Mar 2007 06:54:30 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: Acdh2m3ujezg3B6pRb6aq4HognxrVgAMF+3Q
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Dimitri,
=20
> [e-mail]
> 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 <[e-mail]>
> Sent by: [e-mail]
> 07/03/2007 15:34
> =20
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,=20
> Adrian Farrel=20
> <[e-mail]>
>         cc:     "Attila Takacs \(IJ/ETH\)"=20
> <[e-mail]>,=20
> [e-mail], Don Fedyk <[e-mail]>,=20
> [e-mail], "Pandian, Vijay"=20
> <[e-mail]>
>         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
> [e-mail] 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: [e-mail]
> 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: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [e-mail]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 23:35:13 +0000
To: Igor Bryskin <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>, [e-mail], "Pandian, Vijay" <[e-mail]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 9 Mar 2007 00:34:13 +0100
Content-Type: text/plain; charset="US-ASCII"

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 <[e-mail]>
Sent by: [e-mail]
07/03/2007 15:34
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[e-mail]>
        cc:     "Attila Takacs \(IJ/ETH\)" <[e-mail]>, 
[e-mail], Don Fedyk <[e-mail]>, 
[e-mail], "Pandian, Vijay" <[e-mail]>
        Subject:        Re: What is this fate sharing thing? [Was: 
Questions on draft-takacs-asym-bw-lsp-00.txt]


Dimitri.

See in-line.

[e-mail] 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: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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.




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 23:10:53 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 9 Mar 2007 00:10:24 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvciwNCg0KPiBJcyB0aGUgTGlua0lEIGlzIHRoZSBzYW1lIGFzIFJlbW90ZSBURSBSb3V0ZXIg
SUQ/IA0KDQpubw0KDQo+IExpbmtJRCB1bmFtYmlndW9zbHkgaWRlbnRpZmllcyByZW1vdGUgZGF0
YSBwbGFuZSBub2RlLA0KDQpubywgaXQgaWRlbnRpZmllcyB0aGUgcmVtb3RlIFJDIG5vdCB0aGUg
cmVtb3RlIGRhdGEgcGxhbmUgIm5vZGUiIGluIGNhc2UgDQp0aGUgcmVtb3RlIFJDIGlzIGFzc29j
aWF0ZSB0byBuICJub2RlcyINCg0KDQpwczogc2Vjb25kIHF1ZXN0aW9uIGlzIHRyaXZpYWwsIG1h
dGhlbWF0aWNhbCB2cyBuZXR3b3JraW5nIGZvcm11bGF0aW9uIChubyANCnJlYWwgZGlmZmVyZW5j
ZSkNCg0KcHBzOiBpZiB5b3Ugd2FudCB0byBwdXQgZ3VpZGVsaW5lcyBvbiBlLW1haWwgcmVzcG9u
c2VzIHByb2JhYmx5IGRpcmVjdGluZyANCnlvdXIgZS1tYWlsIHRvIHRoZSBHRU4gQVJFQSB3b3Vs
ZCBiZSBtb3JlIHN1aXRhYmxlIA0KDQpob3BlIHRoaXMgaGVscHMsDQotZC4NCg0KDQoNCg0KSWdv
ciBCcnlza2luIDxpX2JyeXNraW5AeWFob28uY29tPg0KMDkvMDMvMjAwNyAwMDowMw0KIA0KICAg
ICAgICBUbzogICAgIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCiAg
ICAgICAgY2M6ICAgICBjY2FtcEBvcHMuaWV0Zi5vcmcsICJCcnVuZ2FyZCwgRGVib3JhaCBBLCBB
TEFCUyIgDQo8ZGJydW5nYXJkQGF0dC5jb20+DQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSZTog
VHdvIHF1ZXN0aW9ucyBvbiANCmRyYWZ0LWRpbWl0cmktY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5n
LW9zcGYgZHJhZnQNCg0KDQpEaW1pdHJpLCBubywgaXQgZG9lcyBub3QgaGVscC4NCg0KWW91IGRp
ZG4ndCBhbnN3ZXIgdGhlIGZpcnN0IHF1ZXN0aW9uLCB3aGljaCBpczoNCg0KSXMgdGhlIExpbmtJ
RCBpcyB0aGUgc2FtZSBhcyBSZW1vdGUgVEUgUm91dGVyIElEPyBJZiBubywgd2hhdCBpcyB0aGUg
DQpkaWZmZXJlbmNlPyBJZiB5ZXMsIHdoeSBkbyB5b3UgbmVlZCB0aGUgbGF0dGVyPyBCb3RoIHlv
dXIgcG9pbnRlcnMgZXhwbGFpbiANCndoeSBkbyB5b3UgbmVlZCBhZHZlcnRpc2luZyBvZiB0aGUg
bG9jYWwgVEUgUm91dGVyIElEIChhZHZlcnRpc2luZyByb3V0ZXIgDQptYXkgY292ZXIgbXVsdGlw
bGUgZGF0YSBwbGFuZSBub2RlcyksIEhvd2V2ZXIsIExpbmtJRCB1bmFtYmlndW9zbHkgDQppZGVu
dGlmaWVzIHJlbW90ZSBkYXRhIHBsYW5lIG5vZGUsIGFuZCB0aGUgbmVlZCBmb3IgdGhlIGFkdmVy
dGlzaW5nIG9mIA0KUmVtb3RlIFRFIFJvdXRlciBJRCBpcyBub3Qgb2J2aW91cw0KDQpCVFcsIFlv
dSBkaWRuJ3QgYW5zd2VyIHRoZSBzZWNvbmQgcXVlc3Rpb24gZWl0aGVyLg0KDQpJZ29yDQoNClBT
LCBJIGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGUgd29ya2luZyBncm91cDogTGV0IHVzIGRpc2Fs
bG93IHJlc3BvbmRpbmcgDQp0byB0aGUgY29tbWVudHMvcXVlc3Rpb25zIGJ5IGp1c3QgcG9pbnRp
bmcgdG8gUkZDcyBvciBkcmFmdHMuIEluIG15IHZpZXcgDQppdCBpcyBxdWl0ZSB1bmZyaWVuZGx5
LiBJdCBpcyBhbHdheXMgcG9zc2libGUgdG8gY3V0IGFuZCBwYXN0ZSBhIHBpZWNlIA0KZnJvbSB0
aGUgcmVsZXZhbnQgUkZDIG9yIGRyYWZ0IGNvbmZpcm1pbmcgdGhlIHBvaW50cyB0aGUgd3JpdGVy
IGlzIHRyeWluZyANCnRvIG1ha2UuDQoNCkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLWx1
Y2VudC5iZSB3cm90ZToNCmlnb3INCg0KDQpwbHMgdXNlIHZlcnNpb24gKG9yIDAzIA0Kd2hlbiBh
dmFpbGFibGUgdG8gbWFrZSBjb21tZW50cykNCg0KaW4gdGhhdCB2ZXJzaW9uIHlvdSB3aWxsIHNl
ZSBpbiBTZWN0aW9uIDUuMg0KDQoiIE5vdGU6IFRoZSBMaW5rIElEIHN1Yi1UTFYgdGhhdCBpZGVu
dGlmaWVzIHRoZSBvdGhlciBlbmQgb2YgdGhlIGxpbmsgDQooaS5lLiBSb3V0ZXIgSUQgb2YgdGhl
IG5laWdoYm9yIGZvciBwb2ludC10by1wb2ludCBsaW5rcykgTVVTVCANCmFwcGVhciBleGFjdGx5
IG9uY2UgcGVyIExpbmsgVExWLiBUaGlzIHN1Yi1UTFYgTVVTVCBiZSBwcm9jZXNzZWQgYXMgDQpk
ZWZpbmVkIGluIFtSRkMzNjMwXS4gIg0KDQpub3cgd2h5IHRoaXMgc3ViLVRMViAxNywgd2VsbCBm
b3IgdGhlIHJlYXNvbiBleHBsYWluZWQgYXQgdGhlIGJlZ2lubmluZyBvZiANCg0KcGFyLjUuMg0K
YnV0IGFsc28gaW4gUkZDIDQ2NTIgU2VjdGlvbiA1LjcNCg0KaG9wZSB0aGlzIGhlbHBzLA0KLWQu
DQoNCg0KDQoNCklnb3IgQnJ5c2tpbiANCjA4LzAzLzIwMDcgMjI6MTENCg0KVG86IERpbWl0cmkg
UEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCmNjOiBjY2FtcEBvcHMuaWV0Zi5vcmcs
ICJCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUyIgDQoNClN1YmplY3Q6IFR3byBxdWVzdGlvbnMg
b24gDQpkcmFmdC1kaW1pdHJpLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRyYWZ0DQoN
Cg0KRGltaXRyaSwNCkkgaGF2ZSBhIGNvdXBsZSBxdWVzdGlvbnMgd3J0IHRoZSANCmRyYWZ0LWRp
bWl0cmktY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLW9zcGYgZHJhZnQuDQpJbiA1LjIgYSBURSBM
aW5rIHN1Yi1UTFYgaXMgaW50cm9kdWNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYWR2ZXJ0aXNpbmcg
DQpsb2NhbCBhbmQgcmVtb3RlIFRFIFJvdXRlciBJRDoNCg0KMCAxIDIgMyANCjAgMSAyIDMgNCA1
IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCist
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rIA0KfCAxNyB8IExlbmd0aCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IExvY2FsIFRFIFJvdXRlciBJ
ZGVudGlmaWVyIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgUmVtb3RlIFRFIFJvdXRlciBJZGVudGlmaWVyIHwg
DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKyANCg0KQWx0aG91Z2ggSSBkbyB1bmRlcnN0YW5kIHdoeSB0aGVyZSBpcyBhIG5l
ZWQgZm9yIGFkdmVydGlzaW5nIHRoZSBMb2NhbCBURSANClJvdXRlciBJRCwgSSBkb27DouKCrOKE
onQgdW5kZXJzdGFuZCB3aHkgdGhlIFJlbW90ZSBUZSBSb3V0ZXIgSUQ/IElzbsOi4oKs4oSidCAN
CnRoaXMgaXMgDQp0aGUgc2FtZQ0KaW5mb3JtYXRpb24gDQp0aGF0IGlzIGNhcnJpZWQgaW4gdGhl
IExpbmsgSUQgc3ViLVRMVj8NCkluIDYuIHlvdSB3cml0ZToNCg0Kw6LigqzFk0EgUkEgbWF5IGNv
bnRhaW4gc21hbGxlciBSQXMgaW50ZXItY29ubmVjdGVkIGJ5IGxpbmtzLiANClRoZSBsaW1pdCBv
ZiB0aGUgc3ViZGl2aXNpb24gcmVzdWx0cyBpbg0KYSBSQSB0aGF0IGNvbnRhaW5zIHR3byBzdWIt
bmV0d29ya3MgaW50ZXJjb25uZWN0ZWQgYnkgYSBzaW5nbGUgbGluay7DouKCrMKdDQoNCkluIEcu
ODA4MCBJIHJlYWQ6DQrDouKCrMWTLi4uLiBBIHJvdXRpbmcgYXJlYSBpcyBkZWZpbmVkIGJ5IGEg
c2V0IG9mIHN1Ym5ldHdvcmtzLCB0aGUgU05QUCBsaW5rcyANCg0KdGhhdCBpbnRlcmNvbm5lY3Qg
dGhlbSwgYW5kIHRoZSBTTlBQcyByZXByZXNlbnRpbmcgdGhlIGVuZHMgb2YgdGhlIFNOUFAgDQps
aW5rcyBleGl0aW5nIHRoYXQgcm91dGluZyBhcmVhLiBBIHJvdXRpbmcgYXJlYSBtYXkgY29udGFp
biBzbWFsbGVyIA0Kcm91dGluZyBhcmVhcyBpbnRlcmNvbm5lY3RlZCBieSBTTlBQIGxpbmtzLiBU
aGUgbGltaXQgb2Ygc3ViZGl2aXNpb24gDQpyZXN1bHRzIGluIGEgcm91dGluZyBhcmVhIHRoYXQg
Y29udGFpbnMgXW9uZSBzdWJuZXR3b3JrLsOi4oKswp0NCg0KV2h5IGlzIHRoZSBkaXNjcmVwYW5j
eT8NCg0KVGhhbmtzLA0KSWdvcg0KDQoNClsNClN1Y2tlci1wdW5jaCBzcGFtIHdpdGggYXdhcmQt
d2lubmluZyBwcm90ZWN0aW9uLg0KVHJ5IHRoZSBmcmVlIFlhaG9vISBNYWlsIEJldGEuDQoNCg0K
IE5vdyB0aGF0J3Mgcm9vbSBzZXJ2aWNlISBDaG9vc2UgZnJvbSBvdmVyIDE1MCwwMDAgaG90ZWxz
IA0KaW4gNDUsMDAwIGRlc3RpbmF0aW9ucyBvbiBZYWhvbyEgVHJhdmVsIHRvIGZpbmQgeW91ciBm
aXQuDQoNCg==



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 23:05:29 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KlPL/d6aZVXn4+8A5//pQokMsWqC3Md2tAuzsYKTvzd7xWe34hdQyiseJLj/Hee3TkttTOzJgibrucoubdBpz7cedH5juXPczi5EUbRiqmqJFr1o3Xy1Z6J8j5FDgNTaxleNRnzN6ontg9CMSzeEbAeT7YoGkSO5XZScyxRyTKk=;
Date: Thu, 8 Mar 2007 15:03:06 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-889844309-1173394986=:23655"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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

[e-mail] 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:     [e-mail], "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>[e-mail]</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 <[e-mail]><br>08/03/2007 22:11<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail], "Brungard, Deborah A, ALABS" <br><[e-mail]><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></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 21:24:03 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 8 Mar 2007 22:23:21 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvcg0KDQoNCnBscyB1c2UgdmVyc2lvbiA8ZHJhZnQtZGltaXRyaS1jY2FtcC1nbXBscy1hc29u
LXJvdXRpbmctb3NwZi0wMj4gKG9yIDAzIA0Kd2hlbiBhdmFpbGFibGUgdG8gbWFrZSBjb21tZW50
cykNCg0KaW4gdGhhdCB2ZXJzaW9uIHlvdSB3aWxsIHNlZSBpbiBTZWN0aW9uIDUuMg0KDQoiIE5v
dGU6IFRoZSBMaW5rIElEIHN1Yi1UTFYgdGhhdCBpZGVudGlmaWVzIHRoZSBvdGhlciBlbmQgb2Yg
dGhlIGxpbmsgDQogICAoaS5lLiBSb3V0ZXIgSUQgb2YgdGhlIG5laWdoYm9yIGZvciBwb2ludC10
by1wb2ludCBsaW5rcykgTVVTVCANCiAgIGFwcGVhciBleGFjdGx5IG9uY2UgcGVyIExpbmsgVExW
LiBUaGlzIHN1Yi1UTFYgTVVTVCBiZSBwcm9jZXNzZWQgYXMgDQogICBkZWZpbmVkIGluIFtSRkMz
NjMwXS4gIg0KDQpub3cgd2h5IHRoaXMgc3ViLVRMViAxNywgd2VsbCBmb3IgdGhlIHJlYXNvbiBl
eHBsYWluZWQgYXQgdGhlIGJlZ2lubmluZyBvZiANCnBhci41LjINCmJ1dCBhbHNvIGluIFJGQyA0
NjUyIFNlY3Rpb24gNS43DQoNCmhvcGUgdGhpcyBoZWxwcywNCi1kLg0KDQoNCg0KDQpJZ29yIEJy
eXNraW4gPGlfYnJ5c2tpbkB5YWhvby5jb20+DQowOC8wMy8yMDA3IDIyOjExDQogDQogICAgICAg
IFRvOiAgICAgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KICAgICAg
ICBjYzogICAgIGNjYW1wQG9wcy5pZXRmLm9yZywgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJT
IiANCjxkYnJ1bmdhcmRAYXR0LmNvbT4NCiAgICAgICAgU3ViamVjdDogICAgICAgIFR3byBxdWVz
dGlvbnMgb24gDQpkcmFmdC1kaW1pdHJpLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRy
YWZ0DQoNCg0KRGltaXRyaSwNCiBJIGhhdmUgYSBjb3VwbGUgcXVlc3Rpb25zIHdydCB0aGUgDQpk
cmFmdC1kaW1pdHJpLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1vc3BmIGRyYWZ0Lg0KSW4gNS4y
IGEgVEUgTGluayBzdWItVExWIGlzIGludHJvZHVjZWQgZm9yIHRoZSBwdXJwb3NlIG9mIGFkdmVy
dGlzaW5nIA0KbG9jYWwgYW5kIHJlbW90ZSBURSBSb3V0ZXIgSUQ6DQogDQogIDAgICAgICAgICAg
ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgDQogICAg
IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg
OCA5IDAgMSANCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICB8ICAgICAgICAgICAgICAxNyAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfCANCiAgICArLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAg
ICB8ICAgICAgICAgICAgICAgICBMb2NhbCBURSBSb3V0ZXIgSWRlbnRpZmllciAgICAgICAgICAg
ICAgICAgICAgfCANCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICB8ICAgICAgICAgICAgICAgIFJlbW90ZSBU
RSBSb3V0ZXIgSWRlbnRpZmllciAgICAgICAgICAgICAgICAgICAgfCANCiAgICArLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN
CiANCkFsdGhvdWdoIEkgZG8gdW5kZXJzdGFuZCB3aHkgdGhlcmUgaXMgYSBuZWVkIGZvciBhZHZl
cnRpc2luZyB0aGUgTG9jYWwgVEUgDQpSb3V0ZXIgSUQsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdo
eSB0aGUgUmVtb3RlIFRlIFJvdXRlciBJRD8gSXNu4oCZdCB0aGlzIGlzIA0KdGhlIHNhbWUNCiBp
bmZvcm1hdGlvbiANCnRoYXQgaXMgY2FycmllZCBpbiB0aGUgTGluayBJRCBzdWItVExWPw0KSW4g
Ni4geW91IHdyaXRlOg0KIA0K4oCcQSBSQSBtYXkgY29udGFpbiBzbWFsbGVyIFJBcyBpbnRlci1j
b25uZWN0ZWQgYnkgbGlua3MuIA0KVGhlIGxpbWl0IG9mIHRoZSBzdWJkaXZpc2lvbiByZXN1bHRz
IGluDQogYSBSQSB0aGF0IGNvbnRhaW5zIHR3byBzdWItbmV0d29ya3MgaW50ZXJjb25uZWN0ZWQg
YnkgYSBzaW5nbGUgbGluay7igJ0NCiANCkluIEcuODA4MCBJIHJlYWQ6DQrigJwuLi4uIEEgcm91
dGluZyBhcmVhIGlzIGRlZmluZWQgYnkgYSBzZXQgb2Ygc3VibmV0d29ya3MsIHRoZSBTTlBQIGxp
bmtzIA0KdGhhdCBpbnRlcmNvbm5lY3QgdGhlbSwgYW5kIHRoZSBTTlBQcyByZXByZXNlbnRpbmcg
dGhlIGVuZHMgb2YgdGhlIFNOUFAgDQpsaW5rcyBleGl0aW5nIHRoYXQgcm91dGluZyBhcmVhLiBB
IHJvdXRpbmcgYXJlYSBtYXkgY29udGFpbiBzbWFsbGVyIA0Kcm91dGluZyBhcmVhcyBpbnRlcmNv
bm5lY3RlZCBieSBTTlBQIGxpbmtzLiBUaGUgbGltaXQgb2Ygc3ViZGl2aXNpb24gDQpyZXN1bHRz
IGluIGEgcm91dGluZyBhcmVhIHRoYXQgY29udGFpbnMgXW9uZSBzdWJuZXR3b3JrLuKAnQ0KIA0K
V2h5IGlzIHRoZSBkaXNjcmVwYW5jeT8NCiANClRoYW5rcywNCklnb3INCiANCg0KIFsNCiBTdWNr
ZXItcHVuY2ggc3BhbSB3aXRoIGF3YXJkLXdpbm5pbmcgcHJvdGVjdGlvbi4NClRyeSB0aGUgZnJl
ZSBZYWhvbyEgTWFpbCBCZXRhLg0KDQo=



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 21:13:11 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uTB8zconthTdTG9yhRIgW4n6Y4B0UPdVDs+FRxL9heWjQCTGyslebTm4e/xp9pSXk4vE7j5TqyMDDGblh4XWg6IUU2iMrz/yjgWfRGZguXiEn7y1GuTxVDKFd+PqULlSvVnNNZI00H1UDQUVl1549iafTnbQkH1QCRROd11pOas=;
Date: Thu, 8 Mar 2007 13:11:42 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: [e-mail]
Cc: [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-988701227-1173388302=:36530"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 16:55:10 +0000
Message-ID: <183701c761a2$25815e60$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Draft agenda posted
Date: Thu, 8 Mar 2007 16:52:15 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 07:06:35 +0000
Date: Thu, 08 Mar 2007 15:02:47 +0800
From: Dan Li <[e-mail]>
Subject: draft-li-ccamp-multinodes-gr-proc-01.txt
To: ccamp <[e-mail]>
Cc: "Deborah A. Brungard" <[e-mail]>, "Farrel, Adrian" <[e-mail]>, Arun Satyanarayana <[e-mail]>
Message-id: <013901c7614f$c7852190$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_UK/Vf7JRXnoLgeHKF5kHnQ)"

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: [phone]
Fax: [phone]
***************************************************************************************
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: [phone]<BR>Fax: 
[phone]<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)--



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 00:28:31 +0000
To: "Zafar Ali \(zali\)" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Jean Philippe Vasseur \(jvasseur\)" <[e-mail]>, [e-mail]
Subject: Re: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 8 Mar 2007 01:28:05 +0100
Content-Type: text/plain; charset="US-ASCII"

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\)" <[e-mail]>
Sent by: [e-mail]
02/03/2007 00:41
 
        To:     "Adrian Farrel" <[e-mail]>, "Brungard, Deborah 
A, ALABS" <[e-mail]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>, "Jean Philippe Vasseur \(jvasseur\)" 
<[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>
        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  




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Mar 2007 00:28:23 +0000
To: "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, [e-mail]
Subject: RE: New communication from the OIF
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 8 Mar 2007 01:26:33 +0100
Content-Type: text/plain; charset="US-ASCII"

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" <[e-mail]>
Sent by: [e-mail]
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, 
"Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" 
<[e-mail]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>
        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:[e-mail]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail], 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






Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 23:32:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 18:28:50 -0500
Message-ID: <[e-mail]>
Thread-Topic: New communication from the OIF
thread-index: AcdfgSy3iro7QChERHuia03wJ72qIAA9iLAgACDGFbAABHKngA==
From: "Ong, Lyndon" <[e-mail]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail], 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



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 22:29:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 16:28:11 -0600
Message-ID: <[e-mail]>
Thread-Topic: New communication from the OIF
Thread-Index: AcdfgSy3iro7QChERHuia03wJ72qIAA9iLAgACDGFbA=
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail],
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






Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 20:52:32 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-01.txt 
Message-Id: <[e-mail]>
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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 17:46:36 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: AcdgOKamNpQzXbsWS/WkAJ3lHwtNaQAAJ0NQ
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Pandian, Vijay" <[e-mail]>

Hi Dimitri=20

Inline [DF]

> -----Original Message-----
> From: [e-mail]=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



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 16:38:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New communication from the OIF
Date: Wed, 7 Mar 2007 11:35:41 -0500
Message-ID: <[e-mail]>
Thread-Topic: New communication from the OIF
thread-index: AcdfgSy3iro7QChERHuia03wJ72qIAA9iLAg
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [e-mail]
Cc: [e-mail]
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail],
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





Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 15:51:36 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-02.txt 
Message-Id: <[e-mail]>
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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 14:37:03 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sxAsnJPxy/+rLw4NhUjpKWfcFY6Q1XRBACHcQTFTuhcnXokcNJmua+RHo5UeEC16RZQhkoH3i0Na8glB1cosocVTTuS9rNC2cgNgXX0DDA+Ju651k2JpWWWeRlTRQUmx/3yvB9Rha+xDKBiABVPcHeyO1myAy49S2RNEzJrwyoc=  ;
Message-ID: <[e-mail]>
Date: Wed, 7 Mar 2007 06:34:18 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
To: [e-mail], Adrian Farrel <[e-mail]>
Cc: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>, [e-mail], "Pandian, Vijay" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1027318012-1173278058=:50727"
Content-Transfer-Encoding: 8bit

--0-1027318012-1173278058=:50727
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri.

See in-line.

[e-mail] 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: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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>[e-mail]</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" <[e-mail]><br>Sent by: [e-mail]<br>06/03/2007 12:05<br>Please respond to "Adrian Farrel"<br> <br>        To:     "Attila Takacs \(IJ/ETH\)" <[e-mail]>, <br>"Pandian, Vijay" <[e-mail]>, "Don Fedyk" <br><[e-mail]><br>        cc:     <[e-mail]><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)" <[e-mail]><br>To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk" <br><[e-mail]><br>Cc: <[e-mail]><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: [e-mail] [mailto:[e-mail]] On<br>Behalf Of Pandian, Vijay<br>Sent: Tuesday, March 06, 2007 1:36 AM<br>To: Don Fedyk<br>Cc: [e-mail]<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:[e-mail]]<br>Sent: Monday, March 05, 2007 6:41 PM<br>To: Pandian, Vijay; [e-mail]<br>Subject: RE: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay<br><br><br>________________________________<br><br>From: [e-mail]<br>[mailto:[e-mail]] On Behalf Of Pandian, Vijay<br>Sent: Monday, March 05, 2007 2:07 PM<br>To: [e-mail]<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></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Mar 2007 07:08:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: AcdgOrXzDGo9dUQKSM6uNncoP+RWcQAAk8CgAA/xJ9A=
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Drake, John E
> Sent: 06 March 2007 22:24
> To: [e-mail]; Adrian Farrel
> Cc: [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]]=20
> > Sent: Tuesday, March 06, 2007 1:45 PM
> > To: Adrian Farrel
> > Cc: Attila Takacs (IJ/ETH); [e-mail]; Don Fedyk;=20
> > [e-mail]; 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" <[e-mail]>
> > Sent by: [e-mail]
> > 06/03/2007 12:05
> > Please respond to "Adrian Farrel"
> > =20
> >         To:     "Attila Takacs \(IJ/ETH\)"=20
> > <[e-mail]>,
> > "Pandian, Vijay" <[e-mail]>, "Don Fedyk"=20
> > <[e-mail]>
> >         cc:     <[e-mail]>
> >         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
> > ----- Original Message -----
> > From: "Attila Takacs (IJ/ETH)" <[e-mail]>
> > To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk"
> > <[e-mail]>
> > Cc: <[e-mail]>
> > 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: [e-mail] [mailto:[e-mail]] On=20
> > Behalf Of Pandian, Vijay
> > Sent: Tuesday, March 06, 2007 1:36 AM
> > To: Don Fedyk
> > Cc: [e-mail]
> > 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:[e-mail]]
> > Sent: Monday, March 05, 2007 6:41 PM
> > To: Pandian, Vijay; [e-mail]
> > Subject: RE: Questions on
> > draft-takacs-asym-bw-lsp-00.txt
> >=20
> >=20
> > Hi Vijay
> >=20
> >=20
> > ________________________________
> >=20
> > From: [e-mail] [mailto:[e-mail]] On=20
> > Behalf Of Pandian, Vijay
> > Sent: Monday, March 05, 2007 2:07 PM
> > To: [e-mail]
> > 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



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 22:25:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: AcdgOrXzDGo9dUQKSM6uNncoP+RWcQAAk8Cg
From: "Drake, John E" <[e-mail]>
To: <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

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: [e-mail]=20
> [mailto:[e-mail]]=20
> Sent: Tuesday, March 06, 2007 1:45 PM
> To: Adrian Farrel
> Cc: Attila Takacs (IJ/ETH); [e-mail]; Don Fedyk;=20
> [e-mail]; 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" <[e-mail]>
> Sent by: [e-mail]
> 06/03/2007 12:05
> Please respond to "Adrian Farrel"
> =20
>         To:     "Attila Takacs \(IJ/ETH\)"=20
> <[e-mail]>,=20
> "Pandian, Vijay" <[e-mail]>, "Don Fedyk"=20
> <[e-mail]>
>         cc:     <[e-mail]>
>         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
> ----- Original Message -----
> From: "Attila Takacs (IJ/ETH)" <[e-mail]>
> To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk"=20
> <[e-mail]>
> Cc: <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [e-mail]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 21:46:14 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, [e-mail], "Don Fedyk" <[e-mail]>, [e-mail], "Pandian, Vijay" <[e-mail]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 6 Mar 2007 22:44:40 +0100
Content-Type: text/plain; charset="US-ASCII"

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" <[e-mail]>
Sent by: [e-mail]
06/03/2007 12:05
Please respond to "Adrian Farrel"
 
        To:     "Attila Takacs \(IJ/ETH\)" <[e-mail]>, 
"Pandian, Vijay" <[e-mail]>, "Don Fedyk" 
<[e-mail]>
        cc:     <[e-mail]>
        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)" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk" 
<[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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









Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 19:49:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76028.60F99471"
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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
thread-index: AcdgB2D9Ae1SUgPlTI+XvANRWuNJWwAF8lHA
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
	Sent: Tuesday, March 06, 2007 4:52 PM
	To: Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don
Fedyk
	Cc: [e-mail]
	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 <[e-mail]> 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: [e-mail]
[mailto:[e-mail]] On
		Behalf Of Pandian, Vijay
		Sent: Tuesday, March 06, 2007 1:36 AM
		To: Don Fedyk
		Cc: [e-mail]
		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:[e-mail]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [e-mail]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay
	=09
	=09
		________________________________
	=09
		From: [e-mail]
		[mailto:[e-mail]] On Behalf Of Pandian,
Vijay
		Sent: Monday, March 05, 2007 2:07 PM
		To: [e-mail]
		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:[e-mail]] <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> [e-mail]<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;[e-mail]&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)" <[e-mail]><BR>To: =
"Pandian,=20
    Vijay" <[e-mail]>; "Don Fedyk"=20
    <BR><[e-mail]><BR>Cc: <[e-mail]><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
    [e-mail] [mailto:[e-mail]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [e-mail]<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:[e-mail]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[e-mail]<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
    [e-mail]<BR>[mailto:[e-mail]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [e-mail]<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></[e-mail]></[e-mail]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 17:39:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76016.148731CC"
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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: AcdgB1+pVqrAz8IKQMiWxO1Rz8IXUgAAH5qw
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=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 <[e-mail]> 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: [e-mail]
[mailto:[e-mail]] On
		Behalf Of Pandian, Vijay
		Sent: Tuesday, March 06, 2007 1:36 AM
		To: Don Fedyk
		Cc: [e-mail]
		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:[e-mail]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [e-mail]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay
	=09
	=09
		________________________________
	=09
		From: [e-mail]
		[mailto:[e-mail]] On Behalf Of Pandian,
Vijay
		Sent: Monday, March 05, 2007 2:07 PM
		To: [e-mail]
		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:[e-mail]] <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;[e-mail]&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)" <[e-mail]><BR>To: =
"Pandian,=20
    Vijay" <[e-mail]>; "Don Fedyk"=20
    <BR><[e-mail]><BR>Cc: <[e-mail]><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
    [e-mail] [mailto:[e-mail]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [e-mail]<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:[e-mail]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[e-mail]<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
    [e-mail]<BR>[mailto:[e-mail]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [e-mail]<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></[e-mail]></[e-mail]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 17:14:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76012.B3D0B7AD"
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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: AcdgB5MvNSkzhD01QDKkO201diGMVgACL7FA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Igor Bryskin
Sent: 06 March 2007 15:52
To: Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [e-mail]
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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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
  [e-mail] [mailto:[e-mail]] <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
  [e-mail]<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;[e-mail]&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)" <[e-mail]><BR>To: =
"Pandian,=20
    Vijay" <[e-mail]>; "Don Fedyk"=20
    <BR><[e-mail]><BR>Cc: <[e-mail]><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
    [e-mail] [mailto:[e-mail]] =
On<BR>Behalf Of=20
    Pandian, Vijay<BR>Sent: Tuesday, March 06, 2007 1:36 AM<BR>To: Don=20
    Fedyk<BR>Cc: [e-mail]<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:[e-mail]]<BR>Sent: =
Monday,=20
    March 05, 2007 6:41 PM<BR>To: Pandian, Vijay; =
[e-mail]<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
    [e-mail]<BR>[mailto:[e-mail]] On =
Behalf Of=20
    Pandian, Vijay<BR>Sent: Monday, March 05, 2007 2:07 PM<BR>To:=20
    [e-mail]<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></[e-mail]></[e-mail]></VIJAY.PANDIAN@SYCAMOR=
ENET.COM></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 15:56:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: Acdf32hi2ZbJp61YSn6x64KVRZdvKwAGSKBw
From: "Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>
Cc: <[e-mail]>

Hi Adrian


In an Ethernet bridging context I'll try to add what I know.=20

> -----Original Message----- From: Adrian Farrel
> [mailto:[e-mail]] Sent: Tuesday, March 06, 2007
> 6:05 AM To: Attila Takacs (IJ/ETH); Pandian, Vijay; Fedyk,
> Don (BL60:1A00) Cc: [e-mail] 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
> Adrian
>=20
<snip>



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 15:53:01 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=53Xw/HaGi3X0IvhTmSpycQvoD41ozge98JXBJ2TTta0zU6EPBVKNbzNe4E/oDlvKdjaGuHXRzLAMBnSAa1yOr80pCXILSuxjm8UF5LnCrJe5Bar92q0gsieTmYr8U0YdzcUngoze0ni5I+eCCHIOU2bzJyUS2xWdjyYf3RiMcWI=;
Date: Tue, 6 Mar 2007 07:51:53 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
To: Adrian Farrel <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, Don Fedyk <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-509371772-1173196313=:8128"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

--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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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;[e-mail]&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)" <[e-mail]><br>To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk" <br><[e-mail]><br>Cc: <[e-mail]><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: [e-mail] [mailto:[e-mail]] On<br>Behalf Of Pandian, Vijay<br>Sent: Tuesday, March 06, 2007 1:36 AM<br>To: Don Fedyk<br>Cc: [e-mail]<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:[e-mail]]<br>Sent: Monday, March 05, 2007 6:41 PM<br>To: Pandian, Vijay; [e-mail]<br>Subject: RE: Questions on<br>draft-takacs-asym-bw-lsp-00.txt<br><br><br>Hi Vijay<br><br><br>________________________________<br><br>From: [e-mail]<br>[mailto:[e-mail]] On Behalf Of Pandian, Vijay<br>Sent: Monday, March 05, 2007 2:07 PM<br>To: [e-mail]<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></[e-mail]></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 14:41:10 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FFD.6668A822"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 15:41:00 +0100
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQwAAV27PAAFRNYMAAA99uQAAcoNAAAAKEv8A==
From: "Diego Caviglia \(GA/ERI\)" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
Sent: marted=EC 6 marzo 2007 15.36
To: Diego Caviglia (GA/ERI); Attila Takacs (IJ/ETH); Don Fedyk
Cc: [e-mail]
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:[e-mail]]
	Sent: Tuesday, March 06, 2007 6:30 AM
	To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
	Cc: [e-mail]
	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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Attila Takacs (IJ/ETH)
	Sent: marted=EC 6 marzo 2007 11.35
	To: Pandian, Vijay; Don Fedyk
	Cc: [e-mail]
	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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
	Sent: Tuesday, March 06, 2007 1:36 AM
	To: Don Fedyk
	Cc: [e-mail]
	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:[e-mail]]
			Sent: Monday, March 05, 2007 6:41 PM
			To: Pandian, Vijay; [e-mail]
			Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

			Hi Vijay

				=20

			=09
________________________________


				From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
				Sent: Monday, March 05, 2007 2:07 PM
				To: [e-mail]
				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:[e-mail]] <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> =
[e-mail]<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:[e-mail]]<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> =
[e-mail]<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'> =
[e-mail]
[mailto:[e-mail]] <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> =
[e-mail]<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'>
[e-mail] [mailto:[e-mail]] <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> =
[e-mail]<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:[e-mail]]<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;
[e-mail]<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'> [e-mail]
[mailto:[e-mail]] <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> =
[e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 14:36:17 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FFC.B542D7E0"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 09:35:38 -0500
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQwAAV27PAAFRNYMAAA99uQAAcoNAA=
From: "Pandian, Vijay" <[e-mail]>
To: "Diego Caviglia \(GA/ERI\)" <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]
Sent: Tuesday, March 06, 2007 6:30 AM
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Attila Takacs (IJ/ETH)
Sent: marted=EC 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

=20


  _____ =20


From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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:[e-mail]]<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> [e-mail]<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
  [e-mail] [mailto:[e-mail]] <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
  [e-mail]<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
  [e-mail] [mailto:[e-mail]] <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> =
[e-mail]<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:[e-mail]]<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
      [e-mail]<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
        [e-mail] [mailto:[e-mail]] =
<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> =
[e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 11:45:14 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FE4.D1CD0D9C"
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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Thread-Index: Acdf4JWp/jby+ZTyRFu1PwDQ0CiX5QAAjl+w
From: "Diego Caviglia \(GA/ERI\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel
Sent: marted=EC 6 marzo 2007 12.05
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [e-mail]
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)" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk"=20
<[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]<=
/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: [e-mail]<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;[e-mail]&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;[e-mail]&gt;; &quot;Don Fedyk&quot; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&lt;[e-mail]&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">Cc: &lt;[e-mail]&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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]<=
/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: [e-mail]</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:[e-mail]">mailto:[e-mail]</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; [e-mail]</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: [e-mail]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">[<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]<=
/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: [e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 11:35:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: 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
Message-ID: <[e-mail]>
Thread-Topic: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
thread-index: Acdf32NH1b2srmy3TdmNji7nUQvlfgAAQ2Cw
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

Hi Adrian,

Please see inline.
Regards,
Attila=20

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]=20
> Sent: Tuesday, March 06, 2007 12:05 PM
> To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
> Cc: [e-mail]
> 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)" <[e-mail]>
> To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk"=20
> <[e-mail]>
> Cc: <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; [e-mail]
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
>=20
>=20
> Hi Vijay
>=20
>=20
> ________________________________
>=20
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 11:29:49 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FE2.AA8D5950"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 12:29:39 +0100
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQwAAV27PAAFRNYMAAA99uQ
From: "Diego Caviglia \(GA/ERI\)" <[e-mail]>
To: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Attila Takacs (IJ/ETH)
Sent: marted=EC 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [e-mail]
		Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

			=20

		=09
________________________________


			From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
			Sent: Monday, March 05, 2007 2:07 PM
			To: [e-mail]
			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'>
[e-mail] [mailto:[e-mail]] <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> =
[e-mail]<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'>
[e-mail] [mailto:[e-mail]] <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> =
[e-mail]<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:[e-mail]]<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; =
[e-mail]<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'>
[e-mail] [mailto:[e-mail]] <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> =
[e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 11:06:44 +0000
Message-ID: <0f3801c75fdf$5ba7fc70$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Attila Takacs \(IJ/ETH\)" <[e-mail]>, "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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)" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>; "Don Fedyk" 
<[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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






Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 10:35:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75FDB.13B4FBE9"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 11:34:53 +0100
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
thread-index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQwAAV27PAAFRNYMA==
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [e-mail]
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:[e-mail]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [e-mail]
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
	=09
	=09
		Hi Vijay


________________________________

			From: [e-mail]
[mailto:[e-mail]] On Behalf Of Pandian, Vijay
			Sent: Monday, March 05, 2007 2:07 PM
			To: [e-mail]
			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> [e-mail]=20
[mailto:[e-mail]] <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> [e-mail]<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:[e-mail]]<BR><B>Sent:</B> Monday, March 05, 2007 =
6:41=20
    PM<BR><B>To:</B> Pandian, Vijay; =
[e-mail]<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> [e-mail] =

      [mailto:[e-mail]] <B>On Behalf Of </B>Pandian,=20
      Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B> =

      [e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 10:25:37 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Tue, 6 Mar 2007 11:24:56 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
thread-index: AcdeZg5sE8LUFdARSAao4Q9VfGEU0AAlrdQgAArQDHAAAr2rMAABX0QQACeADKA=
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia \(GA/ERI\)" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>

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: [e-mail]=20
> [mailto:[e-mail]] 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
> [e-mail]; [e-mail]
> Cc: [e-mail]; 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:[e-mail]]=20
>=20
> Julien,
>=20
> Please, see in-line.
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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: [e-mail]=20
> [mailto:[e-mail]] 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: [e-mail]=20
> [mailto:[e-mail]] 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
> [e-mail] 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



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 09:49:15 +0000
Message-ID: <0eea01c75fd4$5e1cce00$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Non-member submission from [mike shand <[e-mail]>]   
Date: Tue, 6 Mar 2007 09:45:36 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> To: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
> From: mike shand <[e-mail]>
> Subject: RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt
>  from ISIS WG
> Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>,
>        "les Ginsberg \(ginsberg\)" <[e-mail]>
>
> 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 : [e-mail]
>> > [mailto:[e-mail]] De la part de Adrian Farrel
>> > Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10
>> > =C0 : [e-mail]
>> > Objet : Review comments on
>> > draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
>> >
>> >
>> > ----- Original Message -----
>> > From: "mike shand" <[e-mail]>
>> > To: "Adrian Farrel" <[e-mail]>
>> > Cc: <[e-mail]>; "'Jean Philippe Vasseur'" <[e-mail]>
>> > 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





Envelope-to: [e-mail]
Delivery-date: Tue, 06 Mar 2007 00:36:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F87.7793B3D3"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 19:36:23 -0500
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQwAAV27PA=
From: "Pandian, Vijay" <[e-mail]>
To: "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [e-mail]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt


Hi Vijay


  _____ =20

From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [e-mail]
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:[e-mail]]<BR><B>Sent:</B> Monday, March 05, 2007 =
6:41=20
  PM<BR><B>To:</B> Pandian, Vijay; [e-mail]<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> [e-mail]=20
    [mailto:[e-mail]] <B>On Behalf Of </B>Pandian,=20
    Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B>=20
    [e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 23:46:54 +0000
Message-ID: <0ea701c75f80$81b872f0$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: New communication from the OIF
Date: Mon, 5 Mar 2007 23:46:21 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"

        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,
[e-mail],
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







Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 23:43:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F7F.CA22882C"
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 18:41:24 -0500
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMAAFjIQw
From: "Don Fedyk" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, <[e-mail]>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Pandian, Vijay
	Sent: Monday, March 05, 2007 2:07 PM
	To: [e-mail]
	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> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Pandian,=20
  Vijay<BR><B>Sent:</B> Monday, March 05, 2007 2:07 PM<BR><B>To:</B>=20
  [e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 20:42:24 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F66.B1D5D5C6"
Subject: New Draft : LMP Graceful Restart Procedure
Date: Mon, 5 Mar 2007 14:41:47 -0600
Message-ID: <[e-mail]>
Thread-Topic: New Draft : LMP Graceful Restart Procedure
Thread-Index: AcdfZrGgCpz5C1WVSpaNn47XQOd2sg==
From: "Bardalai, Snigdho" <[e-mail]>
To: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 20:20:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt 
Date: Mon, 5 Mar 2007 14:19:28 -0600
Message-ID: <[e-mail]>
Thread-Topic: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt 
Thread-Index: AcdVMQhQaQPVOm4ASwG6m01z+u5DGAKMk3IA
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Tuesday, February 20, 2007 3:50 PM
To: [e-mail]
Cc: [e-mail]
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
[e-mail] 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:
	[e-mail].
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.



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 20:13:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Date: Mon, 5 Mar 2007 14:12:35 -0600
Message-ID: <[e-mail]>
Thread-Topic: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Thread-Index: AcdcQ2A5HC1vhlvXT9qiSetEzGkauwDHs39w
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Thursday, March 01, 2007 3:50 PM
To: [e-mail]
Cc: [e-mail]
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
[e-mail] 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:
	[e-mail].
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.



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 20:09:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt 
Date: Mon, 5 Mar 2007 14:07:40 -0600
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt 
Thread-Index: AcdcXHewSpG5V5DISvameliNvsPlzgDBNCxg
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Thursday, March 01, 2007 6:50 PM
To: [e-mail]
Cc: [e-mail]
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
[e-mail] 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:
	[e-mail].
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.



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 19:07:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F59.785482B8"
Subject: Questions on draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 14:07:07 -0500
Message-ID: <[e-mail]>
Thread-Topic: Questions on draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdfWXhdZgmxmErtRe6bByz18y7HMA==
From: "Pandian, Vijay" <[e-mail]>
To: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 17:45:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New communication from the OIF
Date: Mon, 5 Mar 2007 18:44:26 +0100
Message-ID: <[e-mail]>
Thread-Topic: New communication from the OIF
Thread-Index: AcdbayDcbBgWFH/GQxaKwCwVQ0JJpwDxAncA
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]

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" <[e-mail]>
Sent by: [e-mail]
28/02/2007 16:16
Please respond to "Adrian Farrel"
=20
        To:     <[e-mail]>
        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, [e-mail] and Deborah Brungard,=20
[e-mail],
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



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 16:51:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 17:49:56 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdeZg5sE8LUFdARSAao4Q9VfGEU0AAlrdQgAArQDHAAAr2rMAABX0QQ
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Diego Caviglia \(GA/ERI\)" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>

Hi Igor.

Please, find my answers in-line.

Regards,

Julien


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20

Julien,

Please, see in-line.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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.

[e-mail] 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




Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 15:21:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F39.ABCBCF8C"
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 10:19:29 -0500
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdeZMgb6Cari5bkRdmTBI6xZ1tGZgAx/4Bg
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
	Sent: Sunday, March 04, 2007 8:56 AM
	To: [e-mail]; Adrian Farrel
	Cc: [e-mail]; 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
	[e-mail] 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:[e-mail]] <BR><B>Sent:</B> Sunday, March 04, 2007 =
8:56=20
  AM<BR><B>To:</B> [e-mail]; Adrian=20
  Farrel<BR><B>Cc:</B> [e-mail]; 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>[e-mail]</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" <[e-mail]><BR>04/03/2007 00:35<BR>Please respond =
to=20
    "Adrian Farrel"<BR><BR>To: "Igor Bryskin" <[e-mail]>, =
Dimitri=20
    <BR>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<BR>cc: <[e-mail]>, =
"Don=20
    Fedyk" <[e-mail]><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></[e-mail]></[e-mail]></I_BRYSKIN=
@YAHOO.COM></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 14:07:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 15:03:47 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdeZg5sE8LUFdARSAao4Q9VfGEU0AAlrdQgAArQDHA=
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia \(GA/ERI\)" <[e-mail]>, "Igor Bryskin" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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.

[e-mail] 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



Envelope-to: [e-mail]
Delivery-date: Mon, 05 Mar 2007 08:13:22 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75EFD.DB337606"
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Mon, 5 Mar 2007 09:11:48 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdeZg5sE8LUFdARSAao4Q9VfGEU0AAlrdQg
From: "Diego Caviglia \(GA/ERI\)" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Igor Bryskin
Sent: domenica 4 marzo 2007 14.56
To: [e-mail]; Adrian Farrel
Cc: [e-mail]; 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.

[e-mail] 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'>
[e-mail] [mailto:[e-mail]] <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>
[e-mail]; Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]; =
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>
<[e-mail]>04/03/2007 00:35<br>
Please respond to &quot;Adrian Farrel&quot;<br>
<br>
To: &quot;Igor Bryskin&quot; <[e-mail]>, Dimitri <br>
PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>
cc: <[e-mail]>, &quot;Don Fedyk&quot; <br>
<[e-mail]>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>

</[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sun, 04 Mar 2007 22:08:41 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Sun, 4 Mar 2007 23:06:05 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcddKXr+hyXSYOGqRZ6AohT1OJWGHwBesfpA
From: "Attila Takacs \(IJ/ETH\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Don Fedyk" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi all,

Please see inline.
Regards,
Attila=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Saturday, March 03, 2007 1:11 AM
> To: Don Fedyk; [e-mail]
> Cc: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Sun, 04 Mar 2007 18:11:03 +0000
Message-ID: <0b5001c75e88$1b65ad40$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Agenda slots for CCAMP in Prague
Date: Sun, 4 Mar 2007 17:32:26 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Sun, 04 Mar 2007 13:57:53 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=x0WCWyUT3SdJuabkPnOPOQmwhFSwf0RFMtCR83UssTx1NlOJrBiXeXOG6mJwJjzv2uChHUXXD3dNFu9PE0ce4Mu8Dt9NetB67nc/v1VHSZyaSzKtBDTWnKTsGWKuy88StOjfT0OAJydVRWmlcAKiiX9umf3eIzVhJ2RwJjMCueE=;
Date: Sun, 4 Mar 2007 05:55:30 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [e-mail], Adrian Farrel <[e-mail]>
Cc: [e-mail], Don Fedyk <[e-mail]>, Igor Bryskin <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2031406607-1173016530=:18484"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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

[e-mail] 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>[e-mail]</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> "Adrian Farrel" <[e-mail]><br>04/03/2007 00:35<br>Please respond to "Adrian Farrel"<br> <br>        To:     "Igor Bryskin" <[e-mail]>, Dimitri <br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     <[e-mail]>, "Don Fedyk" <[e-mail]><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></[e-mail]></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sun, 04 Mar 2007 00:26:55 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Don Fedyk" <[e-mail]>, "Igor Bryskin" <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 4 Mar 2007 01:25:43 +0100
Content-Type: text/plain; charset="US-ASCII"

"Adrian Farrel" <[e-mail]>
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" <[e-mail]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>, "Don Fedyk" <[e-mail]>
        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 







Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 23:44:12 +0000
Message-ID: <0a6301c75ded$919b12c0$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Don Fedyk" <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit

> 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 





Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 22:44:39 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=f3JxSsQ3xZFDiYAKEgVQOELPknGVNe10SB9FcoDhzUQwPjNWBhXgKsazUhVAa6nk9YtaXv4fEccUWJLWP9YGa/sAxT1YGfZXjiyV29QsV8hi+RXpncL31fhVZ9oH7W5o4LepBE12pAwzAuvE2qnSQCK+6CWYwjsRM4ap9pqIlYE=;
Date: Sat, 3 Mar 2007 14:43:54 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [e-mail]
Cc: Adrian Farrel <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1671932405-1172961834=:61415"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

--0-1671932405-1172961834=:61415
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dimitri, see in-line

[e-mail] 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 , [e-mail], 
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

[e-mail] 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: [e-mail]
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>[e-mail]</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 <[e-mail]><br>03/03/2007 21:03<br> <br>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     Adrian Farrel <[e-mail]>, [e-mail], <br>Don Fedyk <[e-mail]><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>[e-mail] 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: [e-mail]<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></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 21:54:01 +0000
To: Igor Bryskin <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 3 Mar 2007 22:52:14 +0100
Content-Type: text/plain; charset="KOI8-R"
Content-Transfer-Encoding: base64

aWdvcg0KDQoiSWYgeW91IG5lZWQgdG8gcmUtcm91dGUgYm90aCBMU1BzLCB0aGFuIHJlY292ZXJ5
IG9mIGEgYmktZGlyZWN0aW9uYWwgTFNQIA0Kd2lsbCBiZSB0d2ljZSBmYXN0ZXIgdGhhbiByZWNv
dmVyeSBvZiB0d28gdW5pZGlyZWN0aW9uYWwgTFNQcy4iDQoNCnRoYXQgaXMgY2xlYXJseSBub3Qg
dGhlIGNhc2UuIHRoZXJlIGlzIG5vIHNlcXVlbnRpYWwgb3BlcmF0aW9uKHMpIGluIGNhc2UgDQpv
ZiB1bmlkaXJlY3Rpb25hbCBMU1BzLCByZWNvdmVyeSB0aW1lIGRpZmYgZGVwZW5kcyBvbiB0aGUg
ZmFpbHVyZSBsb2NhdGlvbiANCmFuZCBub3RpZi4gcHJvcGFnYXRpb24sIGF0IGJlc3QgdGhleSB3
b3VsZCBiZSBlcXVhbCwgb3RoZXJ3aXNlIHlvdSBtYXkgDQpoYXZlIGEgc2xpZ2h0IGRpZmZlcmVu
Y2UgKGluIGZhdm9yIG9mIGJpLWRpciBMU1AsIGJ1dCByZW1lbWJlciB0aGF0IHRoZSANCm1ham9y
IHJlYXNvbmluZyBiZWhpbmQgYmktZGlyIExTUCBoYXMgYWx3YXlzIGJlZW4gdG8gZmFjaWxpdGF0
ZSANCnRpbWVzbG90L2xhbWJkYSBzZWxlY3Rpb24pLg0KDQp0aGUgcmVhbCBwcm9ibGVtIG9mIGFz
eW0gTFNQcy4gY29tcGFyZWQgd2l0aCBzeW0gYmlkaXIgTFNQIHdoZXJlIGl0IGlzIA0KYXNzdW1l
ZCB0aGF0IGJ3IGNvbnRyb2wgaXMgc3ltLiAod2hpY2ggaXMsIGF0IHRoZSBlbmQsIHRoZSBvbmx5
IHJlYXNvbiBmb3IgDQptYWtpbmcgdGhpcyBjYXNlIHNlbnNpYmxlKSB0aGUgcmVzdWx0IGhlcmUg
d2l0aCBhc3ltIGJ3IExTUCBpcyB0aGF0IHRoZSANCmNvbnRyb2wgb2YgYm90aCBkaXJlY3Rpb24v
ZGF0YSBwYXRocyBpcyBjb25jZW50cmF0ZWQgYXQgdGhlIGhlYWQtZW5kLCBpbiANCmNhc2UgdGhl
IHRhaWwtZW5kIGRlc2lyZXMgaW5jcmVhc2luZyB0aGUgdXBzdHJlYW0gYncuDQoNCi1kLg0KDQoN
Cg0KDQoNCg0KSWdvciBCcnlza2luIDxpX2JyeXNraW5AeWFob28uY29tPg0KMDMvMDMvMjAwNyAy
MTowMw0KIA0KICAgICAgICBUbzogICAgIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVM
QEFMQ0FURUwNCiAgICAgICAgY2M6ICAgICBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNv
LnVrPiwgY2NhbXBAb3BzLmlldGYub3JnLCANCkRvbiBGZWR5ayA8ZHdmZWR5a0Bub3J0ZWwuY29t
Pg0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUmU6IEktRCBBQ1RJT046ZHJhZnQtdGFrYWNzLWFz
eW0tYnctbHNwLTAwLnR4dA0KDQoNCkRpbWl0cmksDQoNClN1cHBvc2UgYSBsaW5rIGNhcnJ5aW5n
IGEgYmktZGlyZWN0aW9uYWwgc2VydmljZSBpbiBvbmUgZGlyZWN0aW9uIGZhaWxzIA0KYW5kIHlv
dSBuZWVkIHRvIHBlcmZvcm0gZTJlIHJlY292ZXJ5LiBTdXBwb3NlIHRoZSBzZXJ2aWNlIGlzIG1h
cHBlZCBvbiAyIA0KdW5pZGlyZWN0aW9uYWwgcmVjaXByb2NhbCBMU1BzLiBJZiB5b3UgcmUtcm91
dGUganVzdCBvbmUgTFNQIHlvdSB3aWxsIA0KbG9vc2UgZmF0ZSBzaGFyaW5nLiBJZiB5b3UgbmVl
ZCB0byByZS1yb3V0ZSBib3RoIExTUHMsIHRoYW4gcmVjb3Zlcnkgb2YgYSANCmJpLWRpcmVjdGlv
bmFsIExTUCB3aWxsIGJlIHR3aWNlIGZhc3RlciB0aGFuIHJlY292ZXJ5IG9mIHR3byANCnVuaWRp
cmVjdGlvbmFsIExTUHMuDQpJZiBmYXRlIHNoYXJpbmcgaXMgYSAiTVVTVCIsIEkgc2F5IHdpdGgg
cmVjaXByb2NhbCBMU1BzICB5b3UgZG9uJ3QgaGF2ZSANCmV4dHJhIGZsZXhpYmlsaXR5ICwgYnV0
IHlvdSBkbyBoYXZlIGV4dHJhIGNvbXBsZXhpdHkuDQoNCklnb3INCg0KRGltaXRyaS5QYXBhZGlt
aXRyaW91QGFsY2F0ZWwtbHVjZW50LmJlIHdyb3RlOg0KaWdvcg0KDQoNCjEuIHRyZWF0aW5nIHRo
ZSBMU1BzIGluZGVwZW5kZW50bHkgaXMgYW4gYWRkZWQgdmFsdWUgKGluIHRlcm1zIG9mIA0KZmxl
eGliaWxpdHkpLCB0aGUgc29sZSByZWFzb24gZm9yIGRlcGFydGluZyBpbiBjYXNlIG9mIGJpLWRp
cmVjdGlvbmFsIExTUCANCndhcyAobG9vayBhdCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBp
biAyMDAwKSBkdWUgdG8gYSkga2VlcGluZyANCmVzdGFibGlzaG1lbnQgb2YgZGF0YSBwYXRoIGlu
ZGVwZW5kZW50IHdvdWxkIGhhdmUgbGVkIHRvIGxhbWJkYSBMU1BzIHdpdGggDQpkaWZmZXJlbnQg
d2F2ZWxlbmd0aCBpbiB1cCBhbmQgZG93bnN0cmVhbSBkaXJlY3Rpb24gb3ZlciBkaWZmZXJlbnQg
cGF0aHMgDQpiKSBpbXByb3ZlIHNldHVwIGFuZCByZWNvdmVyeSB0aW1lIA0KDQpub3csIHRoZSBj
b25kaXRpb25zIGFyZSB0b3RhbGx5IGRpZmZlcmVudCwgcmVhc29uIHdoeSBleHBsaWNpdGluZyB0
aGVzZSBpcyANCg0KZGUtZmFjdG8gcmVxdWlyZWQgaW4gYWRkaXRpb24gdG8gdGhlIGNsYWltICJp
IGhhdmUgYSBjbGVhciByZXF1aXJlbWVudCANCmZvciIgdGhhdCBraW5kIG9mIHNlcnZpY2UNCg0K
DQoyLiBhdCB0aGUgZW5kLCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB5b3UgbmVlZCB0byBoYXZl
IGZvciB0aGUgdW5kZXJseWluZyANCg0KZGF0YSBwYXRocyANCg0KYSkgYSBzaWduYWxlZCBhc3Nv
Y2lhdGlvbiBvbiBlYWNoIGludGVybWVkaWF0ZSBub2RlIA0KDQpiKSBhIHNpZ25hbGVkIGFzc29j
aWF0aW9uIGF0IHRoZSBlbmQtcG9pbnRzDQoNCmMpIG5vIHNpZ25hbGVkIGFzc29jaWF0aW9uDQoN
Cg0KMy4gaWYgYSkgaXMgc2VsZWN0ZWQgdGhlcmUgaXMgbm8gb3RoZXIgY2hvaWNlIHRoYW4gYW4g
dXBzdHJlYW0gZmxvd3NwZWMgaW4gDQoNCnRoZSBQYXRoIG1zZyBhbmQgYSB1cHN0cmVhbSB0c3Bl
YyBpbiB0aGUgUmVzdiBtZXNzYWdlDQoNCnRoZSByZWFzb24gaXMgdWx0cmEtY2xlYXIsIGlmIHlv
dSB1c2UgYW4gdXBzdHJlYW0gdHNwZWMgYXMgdGhpcyBkcmFmdCANCnByb3Bvc2VzIGl0IGlzIGVx
dWl2YWxlbnQgdG8gdGhlIGRlc3QuIChzb3VyY2UgUngpIHRlbGxpbmcgdG8gdGhlIHNvdXJjZSAN
CihEZXN0IFR4KSB3aGF0IGFyZSB0cmFmZmljIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgZGF0YSBm
bG93IHRoYXQgdGhlIA0KInNlbmRlciIgKD0gRGVzdCBUeCkgd2lsbCBnZW5lcmF0ZSBoZW5jZSBq
dXN0IHRlbGxpbmcgd2hhdCB0aGUgbGF0dGVyIA0Ka25vd3M7IGhlbmNlIHJlc3VsdGluZyBpbiBy
ZXF1aXJpbmcgdG8gc2VuZCBiYWNrIG92ZXIgdGhlIFJlc3YgdGhlIGFkYXB0ZWQgDQoNCnVwc3Ry
ZWFtIHRzcGVjLCBhbmQgYSB0aGlyZCBleGNoYW5nZSBpbiB0aGUgZm9ybSBvZiBhbiB1cHN0cmVh
bSBmbG93c3BlYyANCihvayB0b3RhbGx5IGlycmVhbGlzdGljIGFuZCBjb21wbGV0ZWx5IG9wcG9z
ZWQgdG8gdGhlIHNpbXBsZSBhbmQgDQppbmV4cGVuc2l2ZSBtZXRob2QgeW91IGFyZSBsb29raW5n
IGF0KQ0KDQpub3RlIHRoYXQgYW55IG1ldGhvZCBjcmVhdGVzIGZvciBwcm92aWRpbmcgYSkgY3Jl
YXRlcyBhIHJlYWwgDQppbnRlcm9wZXJhYmlsaXR5IGlzc3VlLCByZWFzb24gd2h5IGV2ZW4gYSAo
Y29ycmVjdCkgcHJvcG9zYWwgYWxvbmcgdGhlIA0KbGluZXMgb2YgdXBzdHJlYW0gZmxvd3NwZWMg
aW4gdGhlIFBhdGggbXNnIGFuZCBhIHVwc3RyZWFtIHRzcGVjIGluIHRoZSANClJlc3YgbWVzc2Fn
ZSBkaWQgbm90IHByb2dyZXNzIChzZWUgZS5nLiBkcmFmdC1kdWJlLCB0aGF0IHdhcyBwYXJ0aWFs
bHkgDQpnb2luZyBpbnRvIHRoZSBjb3JyZWN0IGRpcmVjdGlvbikNCg0KLWQuDQoNCg0KDQoNCg0K
SWdvciBCcnlza2luIA0KMDMvMDMvMjAwNyAxNDoyNg0KDQpUbzogQWRyaWFuIEZhcnJlbCAsIERv
biBGZWR5ayANCiwgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KY2M6
IGNjYW1wQG9wcy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IEktRCBBQ1RJT046ZHJhZnQtdGFrYWNz
LWFzeW0tYnctbHNwLTAwLnR4dA0KDQoNCkhpLA0KDQpQcm92aWRlZCB0aGF0IHdlIGhhdmUgMS5h
IC0gdGhlcmUgaXMgYSBjbGVhciByZXF1aXJlbWVudCBmb3IgYXN5bW1ldHJpY2FsIA0KYmlkaXJl
Y3Rpb25hbCBzZXJ2aWNlcyDU4fUgSSB0ZW5kIHRvIGFncmVlIHdpdGggRG9uIG9uIHRoaXMuIA0K
DQpJZiBpbXBsZW1lbnRpbmcgYSBiaWRpcmVjdGlvbmFsIHNlcnZpY2UgYnkgYW4gYXNzb2NpYXRp
b24gb2YgdHdvIA0KcmVjaXByb2NhbCB1bmlkaXJlY3Rpb25hbCBMU1BzIGlzIHNvIGdyZWF0LCB0
aGVuIHdoeSBkbyB3ZSBuZWVkIA0KYmktZGlyZWN0aW9uYWwgTFNQcyBpbiB0aGUgZmlyc3QgcGxh
Y2U/IFRoZSBhbnN3ZXIgaXMgd2VsbCByZWNvZ25pemVkOg0KYSkgdGhlIHNldHVwIGlzIGZhc3Rl
cjsNCmIpIHRoZSBDUCBzdGF0ZSBpcyBzbWFsbGVyDQpjKSB0aGUgbWFuYWdlbWVudCBpcyBzaW1w
bGVyIChmYXRlLXNoYXJpbmcsIHJlY292ZXJ5LCBhbGFybSANCmRpc3RyaWJ1dGlvbiwsLCwpDQpk
KSBzb2x1dGlvbiBmb3IgdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiByZXNvdXJjZSBhbGxvY2F0aW9u
IGNvbnRlbnRpb24gDQpwcm9ibGVtDQplKSDU4dYNCg0KVGhhdNTh/XMgd2h5IHdlIGRlY2lkZWQg
dG8gaW50cm9kdWNlIFVwc3RyZWFtIExhYmVsIGFuZCBzdXBwb3J0IA0KYmktZGlyZWN0aW9uYWwg
TFNQcy4NClRoZSBpbnRyb2R1Y3Rpb24gb2YgVXBzdHJlYW0gVC1TUEVDL0ZMT1dTUEVDIHNlZW1z
IHRvIG1lIGEgbmF0dXJhbCBhbmQgDQpyZWxhdGl2ZWx5IGluZXhwZW5zaXZlIHByaWNlIGZvciBw
cmVzZXJ2aW5nIHRoZSBhKSxiKSxjKdTh1i4uDQoNCg0KSWdvciANCkFkcmlhbiBGYXJyZWwgd3Jv
dGU6DQpDdXR0aW5nIHRvIHRoZSBjaGFzZSAoSSBob3BlKToNCg0KPj4tPiBidHcsIHdoZXJlIHRo
aXMgcmVxdWlyZW1lbnQgY29tZSBmcm9tID8NCj4gW0RGXSBTcGVjaWZpY2FsbHkgR01QTFMgY29u
dHJvbCBvZiBFdGhlcm5ldC4NCj4NCj4NCj4gW2RwXSBpIHRoaW5rIGkgc2hvdWxkIGJlIG1vcmUg
cHJlY2lzZSBXSFkgdGhpcyBzcGVjaWZpYyByZXEgPw0KPiBpcyB0aGF0IHNwZWNpZmljIHRvIEV0
aGVybmV0ID8NCg0KMS5hLiBEbyB3ZSBoYXZlIGEgY2xlYXIgcmVxdWlyZW1lbnQgZm9yIGFuIGFz
eW1tZXRyaWNhbCBiaWRpcmVjdGlvbmFsIA0Kc2VydmljZT8NCg0KMS5iLiBEbyB3ZSBoYXZlIGEg
Y2xlYXIgcmVxdWlyZW1lbnQgZm9yIGFzeW1tZXRyaWNhbCBiaWRpcmVjdGlvbmFsIExTUHM/DQoo
RG9lcyAxLmIgZm9sbG93IGZyb20gMS5hPykNCg0KPiBbZHBdIHRoZSBpc3N1ZSBpcyB0aHJlZWZv
bGQNCj4NCj4gYSkgeW91IHdpbGwgc2VlIGZyb20gdGhlIGFib3ZlIHRoYXQgYXN5bSBiaS1kaXIg
TFNQIGRvIG5vdA0KPiBjYWxsIGZvciBhbiB1cHN0cmVhbSB0c3BlYw0KDQoyLiBJZiAxLmIsIHdo
YXQgc2hvdWxkIHdlIHVzZSBvbiBhIFBhdGggbWVzc2FnZSB0byBpbmRpY2F0ZSB0aGUgYmFuZHdp
ZHRoIA0Kb2YgDQp0aGUgZm9yd2FyZCBmbG93Lg0KMi5hLiBhbiAndXBzdHJlYW0nIFRTcGVjDQoy
LmIuIGEgRmxvd1NwZWMNCg0KPiBiKSB0aGUgZ2FpbiBjb21wYXJlZCB0byB0aGUgY29zdCBvZiBo
YXZpbmcgYSByZWFsIGJpLWRpci4NCj4gc2V0dXAgaXMgc28gbG93IHRoYXQgc2V0dGluZyB1bmlk
aXIgTFNQIGlzIHNpbXBsZXINCj4NCj4gYykgYnV0IHRoZXJlIGlzIGFuIG9wZXJhdGlvbmFsIGlz
c3VlIGluIGxpbmtpbmcgdHdvIExTUHMNCj4gKGFzeW1tZXRyaWMpIHRvZ2V0aGVyIHRoYXQgb25l
IGNvdWxkIHRoaW5rIG9mIGFzc29jaWF0aW5nDQo+IHRoZW0sIHdlIGhhdmUgYSB2ZXJ5IGVmZmlj
aWVudCB0ZWNobmlxdWUgZm9yIHRoaXMsIHRoYXQNCj4gZG9lcyBub3QgaW1wYWN0IGludGVybWVk
aWF0ZSBub2RlcyAoQVNTT0NJQVRJT04gb2JqZWN0KQ0KPiBhbmQgcHJvdmlkZXMgZm9yIGZ1bGwg
ZmxleGliaWxpdHkgKGNvbW1vbiBvciBkaXZlcnNlIHNwYXRpYWwNCj4gcGF0aCBmb3IgdGhlIHVw
c3RyZWFtIGFuZCBkb3duc3RyZWFtIGZsb3cpDQoNCjMuIEV2ZW4gaWYgMS5iLiB3ZSBjYW4gY29u
c2lkZXI6DQozLmEuIEEgc2luZ2xlIHNpZ25hbGluZyBleGNoYW5nZSBmb3IgYm90aCBkaXJlY3Rp
b25zDQozLmIuIFR3byAnYXNzb2NpYXRlZCcgc2lnbmFsaW5nIGV4Y2hhbmdlcw0KDQpQZXJzb25h
bGx5LCBJIHRoaW5rIHRoYXQgdGhlIGRpc2N1c3Npb24gaXMgY29uZnVzZWQgYnkgdGFsa2luZyBh
Ym91dCANCiJiaWRpcmVjdGlvbmFsIExTUHMiLiBUaGUgaXNzdWUgcmVhbGx5IHNlZW1zIHRvIHJl
dm9sdmUgYXJvdW5kIHRoZSANCnNpZ25hbGluZyANCmV4Y2hhbmdlcy4gVGhlIGRhdGEgcGxhbmUg
cHJlc2VuY2UgY2FuIGJlIGVzdGFibGlzaGVkIGlkZW50aWNhbGx5IGJ5IDMuYS4gDQpvciANCjMu
Yi4NCg0KQWRyaWFuIA0KDQoNCg0KDQpUViBkaW5uZXIgc3RpbGwgY29vbGluZz8NCkNoZWNrIG91
dCAiVG9uaWdodCdzIFBpY2tzIiBvbiBZYWhvbyEgVFYuDQoNCg0KIE5lZWQgYSBxdWljayBhbnN3
ZXI/IEdldCBvbmUgaW4gbWludXRlcyBmcm9tIHBlb3BsZSB3aG8ga25vdy4gQXNrIHlvdXIgDQpx
dWVzdGlvbiBvbiBZYWhvbyEgQW5zd2Vycy4NCg0K



Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 20:05:28 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=akjxqABzWM9XDKhixF833sKXm5V4Zq4rnNVJr6HZK1m5qZO62DrOUx+aEgM0m1BjaGTXOoW9vIR/ChyzbVv+/6jOKF7sIBuKWMTvS30WawthnNI3xKKJqkIOMJ0ZEGSLRBuzis1aaR1IDIEt92+2WCalAxDUDkvnbS4l5vodPD0=;
Date: Sat, 3 Mar 2007 12:03:15 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: [e-mail]
Cc: Adrian Farrel <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-478059516-1172952195=:32586"
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>

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

[e-mail] 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:     [e-mail]
        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>[e-mail]</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 <[e-mail]><br>03/03/2007 14:26<br> <br>        To:     Adrian Farrel <[e-mail]>, Don Fedyk <br><[e-mail]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>        cc:     [e-mail]<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 <[e-mail]> 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></[e-mail]></[e-mail]></[e-mail]></[e-mail]></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--



Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 16:56:14 +0000
To: Igor Bryskin <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Don Fedyk <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 3 Mar 2007 17:53:25 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aWdvcg0KDQoNCjEuIHRyZWF0aW5nIHRoZSBMU1BzIGluZGVwZW5kZW50bHkgaXMgYW4gYWRkZWQg
dmFsdWUgKGluIHRlcm1zIG9mIA0KZmxleGliaWxpdHkpLCB0aGUgc29sZSByZWFzb24gZm9yIGRl
cGFydGluZyBpbiBjYXNlIG9mIGJpLWRpcmVjdGlvbmFsIExTUCANCndhcyAobG9vayBhdCB0aGUg
ZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBpbiAyMDAwKSBkdWUgdG8gYSkga2VlcGluZyANCmVzdGFi
bGlzaG1lbnQgb2YgZGF0YSBwYXRoIGluZGVwZW5kZW50IHdvdWxkIGhhdmUgbGVkIHRvIGxhbWJk
YSBMU1BzIHdpdGggDQpkaWZmZXJlbnQgd2F2ZWxlbmd0aCBpbiB1cCBhbmQgZG93bnN0cmVhbSBk
aXJlY3Rpb24gb3ZlciBkaWZmZXJlbnQgcGF0aHMgDQpiKSBpbXByb3ZlIHNldHVwIGFuZCByZWNv
dmVyeSB0aW1lIA0KDQpub3csIHRoZSBjb25kaXRpb25zIGFyZSB0b3RhbGx5IGRpZmZlcmVudCwg
cmVhc29uIHdoeSBleHBsaWNpdGluZyB0aGVzZSBpcyANCmRlLWZhY3RvIHJlcXVpcmVkIGluIGFk
ZGl0aW9uIHRvIHRoZSBjbGFpbSAiaSBoYXZlIGEgY2xlYXIgcmVxdWlyZW1lbnQgDQpmb3IiIHRo
YXQga2luZCBvZiBzZXJ2aWNlDQoNCg0KMi4gYXQgdGhlIGVuZCwgdGhlIHF1ZXN0aW9uIGlzIHdo
ZXRoZXIgeW91IG5lZWQgdG8gaGF2ZSBmb3IgdGhlIHVuZGVybHlpbmcgDQpkYXRhIHBhdGhzIA0K
DQphKSBhIHNpZ25hbGVkIGFzc29jaWF0aW9uIG9uIGVhY2ggaW50ZXJtZWRpYXRlIG5vZGUgDQoN
CmIpIGEgc2lnbmFsZWQgYXNzb2NpYXRpb24gYXQgdGhlIGVuZC1wb2ludHMNCg0KYykgbm8gc2ln
bmFsZWQgYXNzb2NpYXRpb24NCg0KDQozLiBpZiBhKSBpcyBzZWxlY3RlZCB0aGVyZSBpcyBubyBv
dGhlciBjaG9pY2UgdGhhbiBhbiB1cHN0cmVhbSBmbG93c3BlYyBpbiANCnRoZSBQYXRoIG1zZyBh
bmQgYSB1cHN0cmVhbSB0c3BlYyBpbiB0aGUgUmVzdiBtZXNzYWdlDQoNCnRoZSByZWFzb24gaXMg
dWx0cmEtY2xlYXIsIGlmIHlvdSB1c2UgYW4gdXBzdHJlYW0gdHNwZWMgYXMgdGhpcyBkcmFmdCAN
CnByb3Bvc2VzIGl0IGlzIGVxdWl2YWxlbnQgdG8gdGhlIGRlc3QuIChzb3VyY2UgUngpIHRlbGxp
bmcgdG8gdGhlIHNvdXJjZSANCihEZXN0IFR4KSB3aGF0IGFyZSB0cmFmZmljIGNoYXJhY3Rlcmlz
dGljcyBvZiB0aGUgZGF0YSBmbG93IHRoYXQgdGhlIA0KInNlbmRlciIgKD0gRGVzdCBUeCkgd2ls
bCBnZW5lcmF0ZSBoZW5jZSBqdXN0IHRlbGxpbmcgd2hhdCB0aGUgbGF0dGVyIA0Ka25vd3M7IGhl
bmNlIHJlc3VsdGluZyBpbiByZXF1aXJpbmcgdG8gc2VuZCBiYWNrIG92ZXIgdGhlIFJlc3YgdGhl
IGFkYXB0ZWQgDQp1cHN0cmVhbSB0c3BlYywgYW5kIGEgdGhpcmQgZXhjaGFuZ2UgaW4gdGhlIGZv
cm0gb2YgYW4gdXBzdHJlYW0gZmxvd3NwZWMgDQoob2sgdG90YWxseSBpcnJlYWxpc3RpYyBhbmQg
Y29tcGxldGVseSBvcHBvc2VkIHRvIHRoZSBzaW1wbGUgYW5kIA0KaW5leHBlbnNpdmUgbWV0aG9k
IHlvdSBhcmUgbG9va2luZyBhdCkNCg0Kbm90ZSB0aGF0IGFueSBtZXRob2QgY3JlYXRlcyBmb3Ig
cHJvdmlkaW5nIGEpIGNyZWF0ZXMgYSByZWFsIA0KaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSwgcmVh
c29uIHdoeSBldmVuIGEgKGNvcnJlY3QpIHByb3Bvc2FsIGFsb25nIHRoZSANCmxpbmVzIG9mIHVw
c3RyZWFtIGZsb3dzcGVjIGluIHRoZSBQYXRoIG1zZyBhbmQgYSB1cHN0cmVhbSB0c3BlYyBpbiB0
aGUgDQpSZXN2IG1lc3NhZ2UgZGlkIG5vdCBwcm9ncmVzcyAoc2VlIGUuZy4gZHJhZnQtZHViZSwg
dGhhdCB3YXMgcGFydGlhbGx5IA0KZ29pbmcgaW50byB0aGUgY29ycmVjdCBkaXJlY3Rpb24pDQoN
Ci1kLg0KDQoNCg0KDQoNCklnb3IgQnJ5c2tpbiA8aV9icnlza2luQHlhaG9vLmNvbT4NCjAzLzAz
LzIwMDcgMTQ6MjYNCiANCiAgICAgICAgVG86ICAgICBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xk
ZG9nLmNvLnVrPiwgRG9uIEZlZHlrIA0KPGR3ZmVkeWtAbm9ydGVsLmNvbT4sIERpbWl0cmkgUEFQ
QURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCiAgICAgICAgY2M6ICAgICBjY2FtcEBvcHMu
aWV0Zi5vcmcNCiAgICAgICAgU3ViamVjdDogICAgICAgIFJlOiBJLUQgQUNUSU9OOmRyYWZ0LXRh
a2Fjcy1hc3ltLWJ3LWxzcC0wMC50eHQNCg0KDQpIaSwNCg0KUHJvdmlkZWQgdGhhdCB3ZSBoYXZl
IDEuYSAtIHRoZXJlIGlzIGEgY2xlYXIgcmVxdWlyZW1lbnQgZm9yICBhc3ltbWV0cmljYWwgDQpi
aWRpcmVjdGlvbmFsIHNlcnZpY2VzIOKAkyBJIHRlbmQgdG8gYWdyZWUgd2l0aCBEb24gb24gdGhp
cy4gDQogDQpJZiBpbXBsZW1lbnRpbmcgYSBiaWRpcmVjdGlvbmFsIHNlcnZpY2UgYnkgYW4gYXNz
b2NpYXRpb24gb2YgdHdvIA0KcmVjaXByb2NhbCB1bmlkaXJlY3Rpb25hbCBMU1BzIGlzIHNvIGdy
ZWF0LCB0aGVuIHdoeSBkbyB3ZSBuZWVkIA0KYmktZGlyZWN0aW9uYWwgTFNQcyBpbiB0aGUgZmly
c3QgcGxhY2U/IFRoZSBhbnN3ZXIgaXMgd2VsbCByZWNvZ25pemVkOg0KYSkgICAgICB0aGUgc2V0
dXAgaXMgZmFzdGVyOw0KYikgICAgICB0aGUgQ1Agc3RhdGUgaXMgc21hbGxlcg0KYykgICAgICB0
aGUgbWFuYWdlbWVudCBpcyBzaW1wbGVyIChmYXRlLXNoYXJpbmcsIHJlY292ZXJ5LCBhbGFybSAN
CmRpc3RyaWJ1dGlvbiwsLCwpDQpkKSAgICAgIHNvbHV0aW9uIGZvciB0aGUgb3Bwb3NpdGUgZGly
ZWN0aW9uIHJlc291cmNlIGFsbG9jYXRpb24gY29udGVudGlvbiANCnByb2JsZW0NCmUpICAgICAg
4oCmDQogDQpUaGF04oCZcyB3aHkgd2UgZGVjaWRlZCB0byBpbnRyb2R1Y2UgVXBzdHJlYW0gTGFi
ZWwgYW5kIHN1cHBvcnQgDQpiaS1kaXJlY3Rpb25hbCBMU1BzLg0KVGhlIGludHJvZHVjdGlvbiBv
ZiBVcHN0cmVhbSBULVNQRUMvRkxPV1NQRUMgc2VlbXMgdG8gbWUgYSBuYXR1cmFsIGFuZCANCnJl
bGF0aXZlbHkgaW5leHBlbnNpdmUgcHJpY2UgZm9yIHByZXNlcnZpbmcgdGhlIGEpLGIpLGMp4oCm
Li4NCiANCiANCklnb3IgDQpBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3cm90
ZToNCkN1dHRpbmcgdG8gdGhlIGNoYXNlIChJIGhvcGUpOg0KDQo+Pi0+IGJ0dywgd2hlcmUgdGhp
cyByZXF1aXJlbWVudCBjb21lIGZyb20gPw0KPiBbREZdIFNwZWNpZmljYWxseSBHTVBMUyBjb250
cm9sIG9mIEV0aGVybmV0Lg0KPg0KPg0KPiBbZHBdIGkgdGhpbmsgaSBzaG91bGQgYmUgbW9yZSBw
cmVjaXNlIFdIWSB0aGlzIHNwZWNpZmljIHJlcSA/DQo+IGlzIHRoYXQgc3BlY2lmaWMgdG8gRXRo
ZXJuZXQgPw0KDQoxLmEuIERvIHdlIGhhdmUgYSBjbGVhciByZXF1aXJlbWVudCBmb3IgYW4gYXN5
bW1ldHJpY2FsIGJpZGlyZWN0aW9uYWwgDQpzZXJ2aWNlPw0KDQoxLmIuIERvIHdlIGhhdmUgYSBj
bGVhciByZXF1aXJlbWVudCBmb3IgYXN5bW1ldHJpY2FsIGJpZGlyZWN0aW9uYWwgTFNQcz8NCihE
b2VzIDEuYiBmb2xsb3cgZnJvbSAxLmE/KQ0KDQo+IFtkcF0gdGhlIGlzc3VlIGlzIHRocmVlZm9s
ZA0KPg0KPiBhKSB5b3Ugd2lsbCBzZWUgZnJvbSB0aGUgYWJvdmUgdGhhdCBhc3ltIGJpLWRpciBM
U1AgZG8gbm90DQo+IGNhbGwgZm9yIGFuIHVwc3RyZWFtIHRzcGVjDQoNCjIuIElmIDEuYiwgd2hh
dCBzaG91bGQgd2UgdXNlIG9uIGEgUGF0aCBtZXNzYWdlIHRvIGluZGljYXRlIHRoZSBiYW5kd2lk
dGggDQpvZiANCnRoZSBmb3J3YXJkIGZsb3cuDQoyLmEuIGFuICd1cHN0cmVhbScgVFNwZWMNCjIu
Yi4gYSBGbG93U3BlYw0KDQo+IGIpIHRoZSBnYWluIGNvbXBhcmVkIHRvIHRoZSBjb3N0IG9mIGhh
dmluZyBhIHJlYWwgYmktZGlyLg0KPiBzZXR1cCBpcyBzbyBsb3cgdGhhdCBzZXR0aW5nIHVuaWRp
ciBMU1AgaXMgc2ltcGxlcg0KPg0KPiBjKSBidXQgdGhlcmUgaXMgYW4gb3BlcmF0aW9uYWwgaXNz
dWUgaW4gbGlua2luZyB0d28gTFNQcw0KPiAoYXN5bW1ldHJpYykgdG9nZXRoZXIgdGhhdCBvbmUg
Y291bGQgdGhpbmsgb2YgYXNzb2NpYXRpbmcNCj4gdGhlbSwgd2UgaGF2ZSBhIHZlcnkgZWZmaWNp
ZW50IHRlY2huaXF1ZSBmb3IgdGhpcywgdGhhdA0KPiBkb2VzIG5vdCBpbXBhY3QgaW50ZXJtZWRp
YXRlIG5vZGVzIChBU1NPQ0lBVElPTiBvYmplY3QpDQo+IGFuZCBwcm92aWRlcyBmb3IgZnVsbCBm
bGV4aWJpbGl0eSAoY29tbW9uIG9yIGRpdmVyc2Ugc3BhdGlhbA0KPiBwYXRoIGZvciB0aGUgdXBz
dHJlYW0gYW5kIGRvd25zdHJlYW0gZmxvdykNCg0KMy4gRXZlbiBpZiAxLmIuIHdlIGNhbiBjb25z
aWRlcjoNCjMuYS4gQSBzaW5nbGUgc2lnbmFsaW5nIGV4Y2hhbmdlIGZvciBib3RoIGRpcmVjdGlv
bnMNCjMuYi4gVHdvICdhc3NvY2lhdGVkJyBzaWduYWxpbmcgZXhjaGFuZ2VzDQoNClBlcnNvbmFs
bHksIEkgdGhpbmsgdGhhdCB0aGUgZGlzY3Vzc2lvbiBpcyBjb25mdXNlZCBieSB0YWxraW5nIGFi
b3V0IA0KImJpZGlyZWN0aW9uYWwgTFNQcyIuIFRoZSBpc3N1ZSByZWFsbHkgc2VlbXMgdG8gcmV2
b2x2ZSBhcm91bmQgdGhlIA0Kc2lnbmFsaW5nIA0KZXhjaGFuZ2VzLiBUaGUgZGF0YSBwbGFuZSBw
cmVzZW5jZSBjYW4gYmUgZXN0YWJsaXNoZWQgaWRlbnRpY2FsbHkgYnkgMy5hLiANCm9yIA0KMy5i
Lg0KDQpBZHJpYW4gDQoNCg0KDQoNCiBUViBkaW5uZXIgc3RpbGwgY29vbGluZz8NCkNoZWNrIG91
dCAiVG9uaWdodCdzIFBpY2tzIiBvbiBZYWhvbyEgVFYuDQoNCg==



Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 13:29:03 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VaG/p8zM9cInaMlLe9HdQRvCbjdmfh0Z/cD059Qur25H1hyG/ttMHM5WJqT6GpkGVnnMn4732wgYD6w5Dr5AZpNcJ/OpUR6/noWuYCyti8z52+FDpveQkZqLZSfpQXqvG2K6kOOjExO4SpJrtPCz+s20b/aDoMfVMxY0o8ApvlU=  ;
Message-ID: <[e-mail]>
Date: Sat, 3 Mar 2007 05:26:53 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
To: Adrian Farrel <[e-mail]>, Don Fedyk <[e-mail]>, [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-642856478-1172928413=:1739"
Content-Transfer-Encoding: 8bit

--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 <[e-mail]> 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;[e-mail]&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--



Envelope-to: [e-mail]
Delivery-date: Sat, 03 Mar 2007 00:12:03 +0000
Message-ID: <094901c75d28$78d94b50$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Fri, 02 Mar 2007 23:57:51 +0000
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 3 Mar 2007 00:56:09 +0100
Content-Type: text/plain; charset="US-ASCII"

hi don

see inline

>"Don Fedyk" <[e-mail]> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[e-mail]>
>
>Hi Dimitri 
>
>Please see inline:
>> -----Original Message----- From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> 
>> 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>
>
>
>






Envelope-to: [e-mail]
Delivery-date: Fri, 02 Mar 2007 21:24:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Fri, 2 Mar 2007 16:21:35 -0500
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: Acdc7R5m4DpcofGnQm21JY1TtdtKjwAIpeZQ
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

Hi Dimitri

See inline [DF]

>hi don
>
>"Don Fedyk" <[e-mail]> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[e-mail]>
>
>Hi Dimitri=20
>
>Please see inline:
>> -----Original Message----- From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>>=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>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 02 Mar 2007 17:07:07 +0000
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 2 Mar 2007 18:06:23 +0100
Content-Type: text/plain; charset="US-ASCII"

hi don




"Don Fedyk" <[e-mail]>
02/03/2007 17:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
<[e-mail]>
        cc: 
        Subject:        RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt


Hi Dimitri 

Please see inline:
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> 
> 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>





Envelope-to: [e-mail]
Delivery-date: Fri, 02 Mar 2007 16:47:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Date: Fri, 2 Mar 2007 11:44:42 -0500
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Thread-Index: AcdcoBcJJPehlr2/TIyJlJB9RsUsXAANtJiw
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Hi Dimitri=20

Please see inline:
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of=20
> [e-mail]
>=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>



Envelope-to: [e-mail]
Delivery-date: Fri, 02 Mar 2007 07:42:24 +0000
To: [e-mail]
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 2 Mar 2007 08:40:29 +0100
Content-Type: text/plain; charset="US-ASCII"

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.




[e-mail]
27/02/2007 21:50
Please respond to internet-drafts
 
        To:     [e-mail]
        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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-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:
                 [e-mail].
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://[e-mail]/internet-drafts/draft-takacs-asym-bw-lsp-00.txt
_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 23:50:51 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt 
Message-Id: <[e-mail]>
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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 23:43:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75C5B.2661B6D1"
Subject: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
Date: Thu, 1 Mar 2007 18:41:34 -0500
Message-ID: <[e-mail]>
Thread-Topic: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
thread-index: AcdcWyVNrEVd1Fz2RHeB0X1gu8LT2Q==
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>, "Jean Philippe Vasseur \(jvasseur\)" <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3089; t=1172792498; x=1173656498; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20<[e-mail]> |Subject:=20Next=20steps=20for=20draft-ietf-ccamp-mpls-graceful-shutdown- 01.txt.... |Sender:=20 |To:=20=22Adrian=20Farrel=22=20<[e-mail]>,=0A=20=20=20=20=20=2 0=20=20=22Brungard,=20Deborah=20A,=20ALABS=22=20<[e-mail]>,=0A=20 =20=20=20=20=20=20=20=22Dimitri=20Papadimitriou=22=20<Dimitri.Papadimitrio [e-mail]>; bh=oLzh5z9apm4YMVp1LmXI9GOCSEGBpmsdqJAvMye6e+Q=; b=fqz5jKd9KGchEyivw4Qn8Ba/0TEpuTpbXwB/KK+tA52ZHkcKGuu/yw0wFkMc9u+zGYYpoIvY QMGTbhs+Di9z8Rf79jbyjmBmRIWBPKWEjGEOybgFMQJHNH0dmm5MJ7QV;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; );

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



Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 20:51:09 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
Message-Id: <[e-mail]>
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 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 19:51:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
Date: Thu, 1 Mar 2007 20:48:53 +0100
Message-ID: <[e-mail]>
Thread-Topic: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
Thread-Index: AcdQ9GI+c99qgvstR7+om7JHEHjxDQLQVytw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Mike,

Thanks for these comments.

Please see inline,

> -----Message d'origine-----
> De : [e-mail]=20
> [mailto:[e-mail]] De la part de Adrian Farrel
> Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10
> =C0 : [e-mail]
> Objet : Review comments on=20
> draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
>=20
>=20
> ----- Original Message -----
> From: "mike shand" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "'Jean Philippe Vasseur'" <[e-mail]>
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 14:01:34 +0000
Message-ID: <00b301c75c09$d9259b50$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Jean Philippe Vasseur'" <[e-mail]>
Subject: New revision of draft-ietf-ccamp-lsp-stitching
Date: Thu, 1 Mar 2007 13:58:27 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

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.

> ===





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 11:11:19 +0000
Message-ID: <005501c75bf2$0e023f30$22849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: "Pandian, Vijay" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> Sent by: [e-mail]
> 01/03/2007 03:35
>
>        To:     <[e-mail]>
>        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: [e-mail]
Delivery-date: Thu, 01 Mar 2007 07:56:46 +0000
To: "Pandian, Vijay" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 1 Mar 2007 08:54:53 +0100
Content-Type: text/plain; charset="US-ASCII"

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" <[e-mail]>
Sent by: [e-mail]
01/03/2007 03:35
 
        To:     <[e-mail]>
        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: [e-mail]
Delivery-date: Thu, 01 Mar 2007 05:10:34 +0000
Date: Wed, 28 Feb 2007 21:08:55 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4803 on Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base
From: [e-mail]
Cc: [e-mail], [e-mail]

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:    [e-mail], 
                    [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

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


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 05:10:26 +0000
Date: Wed, 28 Feb 2007 21:09:47 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4802 on Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base
From: [e-mail]
Cc: [e-mail], [e-mail]

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:    [e-mail], 
                    [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

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


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 05:10:18 +0000
Date: Wed, 28 Feb 2007 21:10:07 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4801 on Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management
From: [e-mail]
Cc: [e-mail], [e-mail]

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:    [e-mail], 
                    [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

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


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Thu, 01 Mar 2007 02:36:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75BAA.4C2DEEC8"
Subject: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt 
Date: Wed, 28 Feb 2007 21:35:38 -0500
Message-ID: <[e-mail]>
Thread-Topic: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt 
Thread-Index: AcdbqkwudMWow1z7QOGdxW9tcuWY1A==
From: "Pandian, Vijay" <[e-mail]>
To: <[e-mail]>

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