Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 11 May 2004 22:08:08 +0200

hi adrian,

Adrian Farrel wrote:

 > Folks,
 >
 > This draft represents the first step in the much-discussed six point
 > plan towards inter-area/AS solutions.
 >
 > I would like three things to happen:
 >
 > a. This draft to become a WG draft
 >     Please send your opinions

i think this is a good start

 > b. The draft to be reinforced in areas that people consider necessary
 >     One such area MAY be diverse routing.
 >     Please send suggested text, but
 >     - recall that this is not a solutions draft
 >     - try to keep the length of the draft down below 100 pages

i think the draft should focus on automated stitching and more advanced
features like inter-domain recovery and crankback signaling

this said the document points out a very interesting concept of multi-
domain FA (since so far the concept has been detailed in the context of
a single area and TE link) - imho it would be worth reinforcing also 
this part of the document as well, if that was the intention -

 > c. Move on with the next step in the plan.
 >     At the moment, this seems to require effort on points 2 and 4
 >     Viz, develop individual signaling solutions as required and
 >     state their applicability.
 >     We await input from those who have preferred solutions.
 >
 > Cheers,
 > Adrian
 > ----- Original Message -----
 > From: <[email-masked]>
 > To: <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Friday, April 30, 2004 8:44 PM
 > Subject: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
 >
 >
 >
 >>A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 >>
 >>
 >>Title : A Framework for Inter-Domain MPLS Traffic Engineering
 >>Author(s) : A. Farrel, et al.
 >>Filename : draft-farrel-ccamp-inter-domain-framework-00.txt
 >>Pages : 14
 >>Date : 2004-4-30
 >>
 >>This document provides a framework for establishing and controlling
 >>   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
 >>   Label Switched Paths (LSPs) in multi-domain networks.
 >>
 >>   For the purposes of this document, a domain is considered to be any
 >>   collection of network elements within a common sphere of address
 >>   management or path computational responsibility. Examples of such
 >>   domains include IGP areas and Autonomous Systems.
 >>
 >>A URL for this Internet-Draft is:
 >>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-00.txt
 >>
 >>To remove yourself from the I-D Announcement list, send a message to
 >>[email-masked] with the word unsubscribe in the body 
of the message.
 >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
 >>to change your subscription settings.
 >>
 >>
 >>Internet-Drafts are also available by anonymous FTP. Login with the 
username
 >>"anonymous" and a password of your e-mail address. After logging in,
 >>type "cd internet-drafts" and then
 >>"get draft-farrel-ccamp-inter-domain-framework-00.txt".
 >>
 >>A list of Internet-Drafts directories can be found in
 >>http://www.ietf.org/shadow.html
 >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >>
 >>
 >>Internet-Drafts can also be obtained by e-mail.
 >>
 >>Send a message to:
 >>[email-masked].
 >>In the body type:
 >>"FILE /internet-drafts/draft-farrel-ccamp-inter-domain-framework-00.txt".
 >>
 >>NOTE: The mail server at ietf.org can return the document in
 >>MIME-encoded form by using the "mpack" utility.  To use this
 >>feature, insert the command "ENCODING mime" before the "FILE"
 >>command.  To decode the response(s), you will need "munpack" or
 >>a MIME-compliant mail reader.  Different MIME-compliant mail readers
 >>exhibit different behavior, especially when dealing with
 >>"multipart" MIME messages (i.e. documents which have been split
 >>up into multiple messages), so check your local documentation on
 >>how to manipulate these messages.
 >>
 >>
 >>Below is the data which will enable a MIME compliant mail reader
 >>implementation to automatically retrieve the ASCII version of the
 >>Internet-Draft.

---

From: Tomohiro Otani <[email-masked]>
Date: Tue, 18 May 2004 09:47:41 +0900

Hi Everyone,

I have a couple of questions or comments on this draft.

1) Does this draft cover requirements described in draft-ietf-tewg-interas-
mpls-te-req-06.txt ?
2) Although this draft describes the framework in not only MPLS but
also GMPLS, the content mainly focuses on MPLS.  For example of
As pointed out by Dimitri, this should focus on automated stitching,
referring to GMPLS e2e recovery drafts.
3) In this draft, the architecture using PCE is assumed.  I do not deny
this description in MPLS, but I feel unnatural in the case of GMPLS.
4) In terms of Inter-domain OAM, RRO processing may also be clarified
on this draft from the point of route management.
5) Considering the overall, I feel unclear about the difference between
requirement draft and the framework draft. Could you clarify this?
6) I propose to have a separate framework draft of MPLS as well as
GMPLS.

Regards,

tomo

----------------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
----------------------------------------

At 22:08 04/05/11 +0200, dimitri papadimitriou wrote:
 >a single area and TE link) - imho it would be worth reinforcing also this 
part of the document as well, if that was the intention -
directories.
of the message.
 > >>Internet-Drafts are also available by anonymous FTP. Login with the username

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 May 2004 15:55:31 +0100

Hi Tomohiro,

Thanks for reading the draft.

> 1) Does this draft cover requirements described in draft-ietf-tewg-interas-

The intention is that the inter-as and inter-area drafts are inputs to this ID. The
framework should not contradict any requirements expressed in those drafts.

> referring to GMPLS e2e recovery drafts.

It was certainly not the intention to limit the scope to MPLS.
There will certainly be some techniques that are described that are only applicable to
MPLS. It will be the job of an applicability statement for a specific proposed solution to
show what functions and scenarios are supported.

> this description in MPLS, but I feel unnatural in the case of GMPLS.

It is absolutely not assumed. It is described as only one of the possibilities.
We would welcome text from you if you feel we have missed out any other possibilities.

> on this draft from the point of route management.

Any suggestions?

> requirement draft and the framework draft. Could you clarify this?

The intention is to list the possible techniques that solutions may pick from.
Solutions still have to
- show that they meet requirements
- state their applicability
- define any usage or protocol extensions.

> 6) I propose to have a separate framework draft of MPLS as well as

Kireeti may care to comment as the independent co-chair in this case.
My reading is that we are chartered to derive solutions for both environments and that it
would be good to have solutions that are applicable in both situations.

Perhaps you could develop this discussion by suggesting what you would like to see
included in / ommitted from a GMPLS draft.

Thanks.
Adrian

---

From: Tomohiro Otani <[email-masked]>
Date: Tue, 01 Jun 2004 10:50:50 +0900

Hi Adrian,

Sorry for the delay of my response.
I basically understand the intenstion of this draft.

I know the charter deals with the problem and development of both MPLS
and GMPLS.  My concern is that there remains unclear what can be done for
MPLS and not be done for GMPLS, vice versa.  I agree with the procedure
such that GMPLS inter-area/AS-TE framework is progresssed with MPLS
one in a single draft, however, I strongly request to describe the common
functions and differently supported functions more explicitely.

In terms of RRO text, I will send it later.

Regards,

tomo

 >included in / ommitted from a GMPLS draft.

Delivery-date: Mon, 31 May 2004 03:19:41 +0000
From: [email-masked]
To: [email-masked]
Subject: stolen
Date: Mon, 31 May 2004 11:14:20 +0800

--14426260
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

i'm waiting

--14426260
Content-Type: application/x-zip-compressed; name="textfile.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="textfile.zip"

////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////

--14426260--

Delivery-date: Sat, 29 May 2004 20:30:43 +0000
From: "zafar ali" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Sat, 29 May 2004 16:25:29 -0400
Organization: Cisco Systems

>-----Original Message-----
>From: Yakov Rekhter [mailto:[email-masked]]=20
>Sent: Friday, May 28, 2004 6:11 PM
>To: zafar ali
>Cc: 'John Drake'; [email-masked]; 'Anca Zamfir'; 'Adrian=20
>Farrel'; [email-masked]; [email-masked]
>Subject: Re: I-D=20
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt=20
>
>
>Zafar,
>
>> Dear Yakov,
>>=20
>> You mentioned that bundle draft does NOT mention/ use the following=20
>> TLVs, for the IF_ID RSVP_HOP,
>>=20
>> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
>> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)
>
>That is correct.
>
>> So what was the motivation behind such definition (two TLVs) in the=20
>> RFC? Furthermore, the RFC states: "For types 4 and 5, the=20
>Interface ID=20
>> indicates a bundled component link.". Can you please=20
>elaborate on this disconnect?
>
>I think that the editor of that RFC would be the more=20
>appropriate person to elaborate on this.
>

Dear Yakov,=20

So you agree that there is a (possible) disconnect and we either need =
some
clarification (from editors of the RFC) or fix the specs to avoid =
confusion.

BTW as you may recall there has been some discussions on the mailing =
list on
this issue in past. Let's try to close the issue while we are on it.=20

Thanks

Regards... Zafar=20

>Yakov.
> =20
>> Thanks
>>=20
>> Regards... Zafar
>>=20
>>=20
>> >-----Original Message-----
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of Yakov Rekhter
>> >Sent: Friday, May 28, 2004 10:25 AM
>> >To: zafar ali
>> >Cc: 'John Drake'; [email-masked]; 'Anca Zamfir'; 'Adrian=20
>> >Farrel'; [email-masked]; [email-masked]
>> >Subject: Re: I-D=20
>> >ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt=20
>> >
>> >
>> >Zafar,
>> >
>> >> Dear Yakov,
>> >>=20
>> >> Please see in-line.
>> >
>> >response in-line...
>> >
>> >> >Zafar,
>> >> >
>> >> >> Hi John,
>> >> >>=20
>> >> >> Sorry for the delay in reply. In this ID we combined the
>> >following
>> >> >> two
>> >> >> drafts:
>> >> >>=20
>> >> >> 1. Component Link Recording and Resource Control for=20
>GMPLS Link=20
>> >> >> Bundles,
>> >> >>=20
>> >> >> http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
>> >> >> rce-control-b
>> >> >> undle-03.txt. We had discuss and agreement on the content on=20
>> >> >> this draft (especially need for RRO sub-object).
>> >> >>=20
>> >> >> 2. Identification of Component Links of Unnumbered Interfaces,
>> >> >>=20
>> >>=20
>>=20
>>>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00
>> >>.
>> >> >txt.
>> >> >>=20
>> >> >> I think your question is for the portion of ID that came from=20
>> >> >> (2), correct?
>> >> >>=20
>> >> >> Assuming this, here is the rationale.
>> >> >>=20
>> >> >> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
>> >> >>=20
>> >> >>    Type Length Format     Description
>> >> >>   =20
>> >>=20
>>------------------------------------------------------------------
>> >> >--
>> >> >>     1      8   IPv4 Addr. IPv4
>> >> >>     2     20   IPv6 Addr. IPv6
>> >> >>     3     12   See below  IF_INDEX               =20
>> >(Interface Index)
>> >> >>     4     12   See below  COMPONENT_IF_DOWNSTREAM=20
>> >(Component interface)
>> >> >>     5     12   See below  COMPONENT_IF_UPSTREAM  =20
>> >(Component interface)
>> >> >>=20
>> >> >> We need following new TLVs to describe Numbered IF_IDs using=20
>> >> >> IF_ID RSVP_HOP Object.
>> >> >>=20
>> >> >> IPv4 - DOWNSTREAM (Component IF)
>> >> >> IPv4 - UPSTREAM (Component IF)
>> >> >> IPv6 - DOWNSTREAM (Component IF)
>> >> >> IPv6 - UPSTREAM (Component IF)
>> >> >>=20
>> >> >> As the definition in RFC3471 are not sufficient to identify the
>> >> >> above
>> >> >> mentioned cases. Agreed? This is where the discussion started.
>> >> >
>> >> >Could yoy please explain why there is a need for=20
>allowing separate=20
>> >> >downstream and upstream for component links of a bundled=20
>link, but=20
>> >> >there is no such need for plain links ?
>> >> >
>> >>=20
>> >> I wish bundling draft would clearly state the same. Instead
>> >it states,
>> >> "The choice of the component link to use is always made by
>> >the sender
>> >> of the Path/REQUEST message (if an LSP is bidirectional=20
>> >> [GMPLS-SIG],
>> >> the sender chooses a component link in each direction)",=20
>and makes=20
>> >> room for interpretation that the forward and reverse may use=20
>> >the same
>> >> TE link but different component links.
>> >
>> >Good point. Perhaps the bundling draft should be clarified to
>> >make it explicit that it is the same component link that is=20
>> >used for both the forward and reverse direction.
>> >
>> >> Furthermore, if this is true, can you please
>> >> elaborate on the motivation behind using the following (different)
>> >> TLVs, for the IF_ID RSVP_HOP, for the unnumbered case?
>> >>=20
>> >> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component=20
>interface)
>> >> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component=20
>interface)
>> >
>> >The bundling draft does not say anything about these two TLVs.
>> > =20
>> >> >> It was pointed out that some implementations have IF index
>> >> >> assignment
>> >> >> such that IF indexes are only unique within the TE link=20
>> >they belong
>> >> >> to. I.e., assumption that IF_indexes are NOT box wide
>> >unique is not
>> >> >> valid across implementations. In order to accommodate such
>> >> >> implementation, we came up with what is in the ID at=20
>the present=20
>> >> >> moment.
>> >> >
>> >> >That is totally unreasonable. Standards are *not* produced to=20
>> >> >accommodate a particular implementation, and especially to=20
>> >> >accommodate some fairly random assumption(s) made by the=20
>> >> >implementation. So, fix the implementation !!!
>> >> > =20
>> >>=20
>> >> I fully agree with you.
>> >
>> >So, with this in mind let me propose that we clarify the
>> >bundling text, as I suggested above, and then consider the=20
>> >issue closed.
>> >
>> >Yakov.
>> >
>>=20
>

Delivery-date: Sat, 29 May 2004 01:45:20 +0000
Date: Fri, 28 May 2004 18:44:56 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Jean Philippe Vasseur <[email-masked]>
cc: Tony Li <[email-masked]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: RE : RE : RE : Last call for  draft-ietf-tewg-interarea-mpls-te-req-01.txt

On Fri, 28 May 2004, Jean Philippe Vasseur wrote:

> At 09:24 AM 5/28/2004 -0700, Kireeti Kompella wrote:
> >On Fri, 28 May 2004, Tony Li wrote:
> >
> > > > No, computation can be distributed on ABRs. This is basically the
> > > > scenario 4 of draft-kompella-mpls-multiarea-te :
> >...
> > > Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti
> > > ;-).
> >
> >Hey, I'm with you -- the scenarios are ordered roughly by preference
>
> this was not the intention in the draft though ;-)

Actually, it _was_ the intention.

Kireeti.
-------

Delivery-date: Sat, 29 May 2004 01:43:26 +0000
Date: Fri, 28 May 2004 16:31:21 -0400
To: Kireeti Kompella <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: Tony Li <[email-masked]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

At 09:24 AM 5/28/2004 -0700, Kireeti Kompella wrote:
>On Fri, 28 May 2004, Tony Li wrote:
>
> > > No, computation can be distributed on ABRs. This is basically the
> > > scenario 4 of draft-kompella-mpls-multiarea-te :
>...
> > Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti
> > ;-).
>
>Hey, I'm with you -- the scenarios are ordered roughly by preference

this was not the intention in the draft though ;-)

JP.

>(i.e., Scenario 1 is my preferred option.)
>
> > Again, I'm happy to make the tradeoff of less work for less optimality.
>
>Agreed.
>
>Kireeti.
>-------

Delivery-date: Fri, 28 May 2004 22:12:15 +0000
To: "zafar ali" <[email-masked]>
cc: "'John Drake'" <[email-masked]>, [email-masked], "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Fri, 28 May 2004 15:11:10 -0700
From: Yakov Rekhter <[email-masked]>

Zafar,

> Dear Yakov, 
> 
> You mentioned that bundle draft does NOT mention/ use the following TLVs,
> for the IF_ID RSVP_HOP, 
> 
> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

That is correct.

> So what was the motivation behind such definition (two TLVs) in the RFC?
> Furthermore, the RFC states: "For types 4 and 5, the Interface ID indicates
> a bundled component link.". Can you please elaborate on this disconnect?  

I think that the editor of that RFC would be the more appropriate
person to elaborate on this.

Yakov.
  
> Thanks
> 
> Regards... Zafar
> 
> 
> >-----Original Message-----
> >From: [email-masked] 
> >[mailto:[email-masked]] On Behalf Of Yakov Rekhter
> >Sent: Friday, May 28, 2004 10:25 AM
> >To: zafar ali
> >Cc: 'John Drake'; [email-masked]; 'Anca Zamfir'; 'Adrian 
> >Farrel'; [email-masked]; [email-masked]
> >Subject: Re: I-D 
> >ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
> >
> >
> >Zafar,
> >
> >> Dear Yakov,
> >> 
> >> Please see in-line.
> >
> >response in-line...
> >
> >> >Zafar,
> >> >
> >> >> Hi John,
> >> >> 
> >> >> Sorry for the delay in reply. In this ID we combined the 
> >following 
> >> >> two
> >> >> drafts:
> >> >> 
> >> >> 1. Component Link Recording and Resource Control for GMPLS Link
> >> >> Bundles, 
> >> >> 
> >> >> http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
> >> >> rce-control-b
> >> >> undle-03.txt. We had discuss and agreement on the content on
> >> >> this draft (especially need for RRO sub-object). 
> >> >> 
> >> >> 2. Identification of Component Links of Unnumbered Interfaces,
> >> >> 
> >> 
> >>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.
> >> >txt.
> >> >> 
> >> >> I think your question is for the portion of ID that came from (2),
> >> >> correct?
> >> >> 
> >> >> Assuming this, here is the rationale.
> >> >> 
> >> >> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
> >> >> 
> >> >>    Type Length Format     Description
> >> >>    
> >> >--------------------------------------------------------------------
> >> >>     1      8   IPv4 Addr. IPv4
> >> >>     2     20   IPv6 Addr. IPv6
> >> >>     3     12   See below  IF_INDEX                
> >(Interface Index)
> >> >>     4     12   See below  COMPONENT_IF_DOWNSTREAM 
> >(Component interface)
> >> >>     5     12   See below  COMPONENT_IF_UPSTREAM   
> >(Component interface)
> >> >> 
> >> >> We need following new TLVs to describe Numbered IF_IDs using IF_ID
> >> >> RSVP_HOP Object.
> >> >> 
> >> >> IPv4 - DOWNSTREAM (Component IF)
> >> >> IPv4 - UPSTREAM (Component IF)
> >> >> IPv6 - DOWNSTREAM (Component IF)
> >> >> IPv6 - UPSTREAM (Component IF)
> >> >> 
> >> >> As the definition in RFC3471 are not sufficient to identify the 
> >> >> above
> >> >> mentioned cases. Agreed? This is where the discussion started.
> >> >
> >> >Could yoy please explain why there is a need for allowing
> >> >separate downstream and upstream for component links of a 
> >> >bundled link, but there is no such need for plain links ?
> >> >
> >> 
> >> I wish bundling draft would clearly state the same. Instead 
> >it states, 
> >> "The choice of the component link to use is always made by 
> >the sender 
> >> of the Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], 
> >> the sender chooses a component link in each direction)", and makes 
> >> room for interpretation that the forward and reverse may use 
> >the same 
> >> TE link but different component links.
> >
> >Good point. Perhaps the bundling draft should be clarified to 
> >make it explicit that it is the same component link that is 
> >used for both the forward and reverse direction.
> >
> >> Furthermore, if this is true, can you please
> >> elaborate on the motivation behind using the following (different) 
> >> TLVs, for the IF_ID RSVP_HOP, for the unnumbered case?
> >> 
> >> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
> >> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)
> >
> >The bundling draft does not say anything about these two TLVs.
> >  
> >> >> It was pointed out that some implementations have IF index 
> >> >> assignment
> >> >> such that IF indexes are only unique within the TE link 
> >they belong 
> >> >> to. I.e., assumption that IF_indexes are NOT box wide 
> >unique is not 
> >> >> valid across implementations. In order to accommodate such 
> >> >> implementation, we came up with what is in the ID at the present 
> >> >> moment.
> >> >
> >> >That is totally unreasonable. Standards are *not* produced to
> >> >accommodate a particular implementation, and especially to 
> >> >accommodate some fairly random assumption(s) made by the 
> >> >implementation. So, fix the implementation !!!
> >> >  
> >> 
> >> I fully agree with you.
> >
> >So, with this in mind let me propose that we clarify the 
> >bundling text, as I suggested above, and then consider the 
> >issue closed.
> >
> >Yakov.
> >
> 

Delivery-date: Fri, 28 May 2004 20:00:09 +0000
Date: Fri, 28 May 2004 15:59:53 -0400
To: Tony Li <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Tony,

At 02:39 AM 5/28/2004 -0700, Tony Li wrote:
>>No, computation can be distributed on ABRs. This is basically the 
>>scenario 4 of
>>draft-kompella-mpls-multiarea-te :
>>"The head-end LSR requests one of the ABRs in the head-end area to
>>    compute a path to the destination. When the ABR in the head-end area
>>    receives the request, the ABR requests one of the ABRs in the tail-
>>    end area to compute paths to the destination from all/some of the
>>    ABRs in the tail-end area. Once the ABR in the head-end area obtains
>>    this information from the ABR in the tail-end area, the ABR in the
>>    head-end area could compute the path through the head-end and the
>>    backbone areas, concatenates the results of this computation with the
>>    appropriate path through the tail-end area, and then return the
>>    result to the head-end LSR."
>
>
>Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti ;-).
>
>Again, I'm happy to make the tradeoff of less work for less optimality.
>If I'm that concerned about optimality, then I'll do offline computation
>and static configuration.  Or human intervention.  I'm not interested in
>spending the rest of my life debugging an incredibly complex solution that
>gives me the last 0.0001% of optimality.

perfectly acceptable point of view of course. If optimality for 
inter-area/AS TE path is not required, just go ahead with ABR selection 
based on local knowledge but the point of the discussion was to mention 
that leaking of partial (topo) or summarized (TE-related) will always have 
an impact on your IGP and never guarantee you to get the shortest path.

JP.

>Tony

Delivery-date: Fri, 28 May 2004 19:55:30 +0000
Date: Fri, 28 May 2004 15:53:58 -0400
To: Tony Li <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Tony,

At 01:19 AM 5/28/2004 -0700, Tony Li wrote:
>>>Combine this with the fact that the primary reason to use this
>>>information
>>>is to ensure an optimal exit from the L1 area, and there doesn't seem
>>>like
>>>a real need to worry about instantaneous capacity.
>>
>>But an optimal exit, as regards cost, may not allow to find a feasible 
>>e2e path, if there is not enough capacity from
>>this exit to the destination.
>
>
>Certainly true.  However, in a practical sense, the area is connected via 
>redundant
>L1L2 routers.  The redundancy is there so that neither is a single point 
>of failure.
>Thus both ABRs can pass the full traffic load of the area into the 
>backbone.  In short,
>engineering is sufficient to guarantee that we have enough fiber.

The case of not being able to find a path is of course not the only one. 
What if one ABR finds a path which turns out to be much longer because of 
the bw constraints ? You'd be in a situation of leaking connectivity info 
with some impact on the IGP but because you do not have bw info, you would 
in many cases get a non optimal path. Hence the requirements for not 
leaking (summarized) connectivity/TE-related info. Indeed, this looks like 
the worst compromise: you would end up impacting your IGP without being 
able to guarantee anything in term of path optimality (not mentioning the 
need for crankback as pointed out by Jean-Louis).

>>>You're making the assumption that the head end of the LSP is computing
>>>the entire
>>>path.
>>>Again, I'm advocating a somewhat different position (ala
>>>Nimrod): the path
>>>is computed with more refinement as you get closer to the
>>>destination.
>>>The
>>>head end might be able to provide an explicit path through the
>>>originating L1
>>>area, and based on its L2 topology information, it might select the
>>>exit point
>>>from that area.
>>
>>Based on which information does the Head End select the ABR ?
>
>
>L1 TE information plus L2 topology.

But again, leaking for L2 topology would not help at all since we may 
select an L1L2 which may have to select a much longer path due to the 
constraints to respect so why leaking L2 topo at the first place ?

>>>By chaining together 3 locally optimal paths, we will NOT
>>>achieve global
>>>optimality, but we will get a good first approximation for a fraction
>>>of the cost.
>>
>>Not so sure that such scheme will get a good first approximation for a 
>>fraction
>>of the cost.
>>The ABR selected by the Head-End based on its L1 and L2 information may 
>>be the worst ABR, as regards the end-to-end path.
>>Actually you can definitely not control that. Further more such scheme 
>>cannot avoid cranckback risks,
>>and it seems from your last comment that you want to avoid that...
>>
>>Let's take the following example
>>A1, A2, A3, A4 are ABRs
>>Area0 topology is leaked into Area1 and Area2.
>>All metrics are set to 10 except A1-A2 metric that is set to 1
>>Avaialble bandwidth is 100M on all links except on link A2->R5, A1->A3, 
>>and A2->A4 where available bw=50M
>>
>>  Area1          Area0       Area2
>>   --------A1--------A2--------
>>R1         |         |        R5
>>   --------A3--------A4---------
>>
>>We want to setup a TE-LSP from R1 to R5 with bandwidth 60M
>>R1 selects an ABR based on Area1 and Area0 topology info. With your 
>>scheme it may select A1
>>Then A1 will select A2, and A2 will find that there is no path to the 
>>destination,
>>Then Crankback on A1 => No path to destination.
>>Then Crankback on R1 that selects A3....
>
>
>a) Per the above, this is an unacceptable network design in the first place.
>b) R1 has metric information for Area 0, so it would naturally select A3.

Well no because the shortest path based on the metric would be via A1

>>>>Not so sure, there are schemes that allow computing an optimal
>>>>inter-area path without adding any byte in LSA/LSP...
>>>Which would take us back down the crankback path.  No thank you.
>>
>>I was refering to PCE approaches where the inter-area path is selected 
>>thanks to
>>a recursive CSPF computation on ABRs. Such schemes allow computing an 
>>OPTIMAL path, without any IGP extension and without crankback...
>
>Sorry, I'm not sure I'm understanding you.  Are you suggesting off-line 
>path computation?

No Jean-Louis refers to the scenario 1 of draft-vasseur-ccamp-inter-area-as-te

JP.

>Tony

Delivery-date: Fri, 28 May 2004 18:15:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Typo in: draft-ietf-ccamp-gmpls-te-mib-04.txt
Date: Fri, 28 May 2004 19:11:34 +0100

Good man. Thank you.

Don't know where this crept in (I blame the editor).

Please be very free with any other comments or observations you have on this MIB.

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 28, 2004 6:07 PM
Subject: Typo in: draft-ietf-ccamp-gmpls-te-mib-04.txt

> I was doing a test compile on the GMPLS-TE-STD-MIB (draft-04) and got a 'Sequence Error'
on the "gmplsTunnelExtraParamsPtr" object.
>
> When I checked to see what was going on, I found there is a typo in the Object
Description. Instead of "gmplsTunnelExtraParamsPtr" it is "gmplsTunnelExtraParamsptr",
with a lower case 'p' at the start of "Ptr".
>
> I corrected my local copy to get the compile to work, but this really should get fixed
in the next draft.
>
> Len Nieman
> The problem always has it's act together...
>
>
>
>

Delivery-date: Fri, 28 May 2004 17:08:39 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: Typo in: draft-ietf-ccamp-gmpls-te-mib-04.txt
Date: Fri, 28 May 2004 13:07:32 -0400

I was doing a test compile on the GMPLS-TE-STD-MIB (draft-04) and got a 'Sequence Error' on the "gmplsTunnelExtraParamsPtr" object.

When I checked to see what was going on, I found there is a typo in the Object Description. Instead of "gmplsTunnelExtraParamsPtr" it is "gmplsTunnelExtraParamsptr", with a lower case 'p' at the start of "Ptr".

I corrected my local copy to get the compile to work, but this really should get fixed in the next draft.

Len Nieman
The problem always has it's act together...

Delivery-date: Fri, 28 May 2004 16:24:53 +0000
Date: Fri, 28 May 2004 09:24:20 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Tony Li <[email-masked]>
cc: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt

On Fri, 28 May 2004, Tony Li wrote:

> > No, computation can be distributed on ABRs. This is basically the
> > scenario 4 of draft-kompella-mpls-multiarea-te :
...
> Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti
> ;-).

Hey, I'm with you -- the scenarios are ordered roughly by preference
(i.e., Scenario 1 is my preferred option.)

> Again, I'm happy to make the tradeoff of less work for less optimality.

Agreed.

Kireeti.
-------

Delivery-date: Fri, 28 May 2004 15:51:19 +0000
From: "zafar ali" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Fri, 28 May 2004 11:50:10 -0400
Organization: Cisco Systems

Dear Yakov, 

You mentioned that bundle draft does NOT mention/ use the following TLVs,
for the IF_ID RSVP_HOP, 

4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

So what was the motivation behind such definition (two TLVs) in the RFC?
Furthermore, the RFC states: "For types 4 and 5, the Interface ID indicates
a bundled component link.". Can you please elaborate on this disconnect?  

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Yakov Rekhter
>Sent: Friday, May 28, 2004 10:25 AM
>To: zafar ali
>Cc: 'John Drake'; [email-masked]; 'Anca Zamfir'; 'Adrian 
>Farrel'; [email-masked]; [email-masked]
>Subject: Re: I-D 
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
>
>
>Zafar,
>
>> Dear Yakov,
>> 
>> Please see in-line.
>
>response in-line...
>
>> >Zafar,
>> >
>> >> Hi John,
>> >> 
>> >> Sorry for the delay in reply. In this ID we combined the 
>following 
>> >> two
>> >> drafts:
>> >> 
>> >> 1. Component Link Recording and Resource Control for GMPLS Link
>> >> Bundles, 
>> >> 
>> >> http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
>> >> rce-control-b
>> >> undle-03.txt. We had discuss and agreement on the content on
>> >> this draft (especially need for RRO sub-object). 
>> >> 
>> >> 2. Identification of Component Links of Unnumbered Interfaces,
>> >> 
>> 
>>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.
>> >txt.
>> >> 
>> >> I think your question is for the portion of ID that came from (2),
>> >> correct?
>> >> 
>> >> Assuming this, here is the rationale.
>> >> 
>> >> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
>> >> 
>> >>    Type Length Format     Description
>> >>    
>> >--------------------------------------------------------------------
>> >>     1      8   IPv4 Addr. IPv4
>> >>     2     20   IPv6 Addr. IPv6
>> >>     3     12   See below  IF_INDEX                
>(Interface Index)
>> >>     4     12   See below  COMPONENT_IF_DOWNSTREAM 
>(Component interface)
>> >>     5     12   See below  COMPONENT_IF_UPSTREAM   
>(Component interface)
>> >> 
>> >> We need following new TLVs to describe Numbered IF_IDs using IF_ID
>> >> RSVP_HOP Object.
>> >> 
>> >> IPv4 - DOWNSTREAM (Component IF)
>> >> IPv4 - UPSTREAM (Component IF)
>> >> IPv6 - DOWNSTREAM (Component IF)
>> >> IPv6 - UPSTREAM (Component IF)
>> >> 
>> >> As the definition in RFC3471 are not sufficient to identify the 
>> >> above
>> >> mentioned cases. Agreed? This is where the discussion started.
>> >
>> >Could yoy please explain why there is a need for allowing
>> >separate downstream and upstream for component links of a 
>> >bundled link, but there is no such need for plain links ?
>> >
>> 
>> I wish bundling draft would clearly state the same. Instead 
>it states, 
>> "The choice of the component link to use is always made by 
>the sender 
>> of the Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], 
>> the sender chooses a component link in each direction)", and makes 
>> room for interpretation that the forward and reverse may use 
>the same 
>> TE link but different component links.
>
>Good point. Perhaps the bundling draft should be clarified to 
>make it explicit that it is the same component link that is 
>used for both the forward and reverse direction.
>
>> Furthermore, if this is true, can you please
>> elaborate on the motivation behind using the following (different) 
>> TLVs, for the IF_ID RSVP_HOP, for the unnumbered case?
>> 
>> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
>> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)
>
>The bundling draft does not say anything about these two TLVs.
>  
>> >> It was pointed out that some implementations have IF index 
>> >> assignment
>> >> such that IF indexes are only unique within the TE link 
>they belong 
>> >> to. I.e., assumption that IF_indexes are NOT box wide 
>unique is not 
>> >> valid across implementations. In order to accommodate such 
>> >> implementation, we came up with what is in the ID at the present 
>> >> moment.
>> >
>> >That is totally unreasonable. Standards are *not* produced to
>> >accommodate a particular implementation, and especially to 
>> >accommodate some fairly random assumption(s) made by the 
>> >implementation. So, fix the implementation !!!
>> >  
>> 
>> I fully agree with you.
>
>So, with this in mind let me propose that we clarify the 
>bundling text, as I suggested above, and then consider the 
>issue closed.
>
>Yakov.
>

Delivery-date: Fri, 28 May 2004 14:25:58 +0000
To: "zafar ali" <[email-masked]>
cc: "'John Drake'" <[email-masked]>, [email-masked], "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Fri, 28 May 2004 07:25:08 -0700
From: Yakov Rekhter <[email-masked]>

Zafar,

> Dear Yakov, 
> Please see in-line. 

response in-line...

> >Zafar,
> >
> >> Hi John,
> >> 
> >> Sorry for the delay in reply. In this ID we combined the following two
> >> drafts:
> >> 
> >> 1. Component Link Recording and Resource Control for GMPLS Link 
> >> Bundles, 
> >> 
> >> http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
> >> rce-control-b
> >> undle-03.txt. We had discuss and agreement on the content on 
> >> this draft (especially need for RRO sub-object). 
> >> 
> >> 2. Identification of Component Links of Unnumbered Interfaces, 
> >> 
> >http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.txt.
> >> 
> >> I think your question is for the portion of ID that came from (2), 
> >> correct?
> >> 
> >> Assuming this, here is the rationale.
> >> 
> >> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
> >> 
> >>    Type Length Format     Description
> >>    
> >--------------------------------------------------------------------
> >>     1      8   IPv4 Addr. IPv4
> >>     2     20   IPv6 Addr. IPv6
> >>     3     12   See below  IF_INDEX                (Interface Index)
> >>     4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
> >>     5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)
> >> 
> >> We need following new TLVs to describe Numbered IF_IDs using IF_ID 
> >> RSVP_HOP Object.
> >> 
> >> IPv4 - DOWNSTREAM (Component IF)
> >> IPv4 - UPSTREAM (Component IF)
> >> IPv6 - DOWNSTREAM (Component IF)
> >> IPv6 - UPSTREAM (Component IF)
> >> 
> >> As the definition in RFC3471 are not sufficient to identify the above 
> >> mentioned cases. Agreed? This is where the discussion started.
> >
> >Could yoy please explain why there is a need for allowing 
> >separate downstream and upstream for component links of a 
> >bundled link, but there is no such need for plain links ?
> >
> 
> I wish bundling draft would clearly state the same. Instead it states, "The
> choice of the component link to use is always made by the sender of the
> Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender
> chooses a component link in each direction)", and makes room for
> interpretation that the forward and reverse may use the same TE link but
> different component links. 

Good point. Perhaps the bundling draft should be clarified to make
it explicit that it is the same component link that is used for both
the forward and reverse direction.

> Furthermore, if this is true, can you please
> elaborate on the motivation behind using the following (different) TLVs, for
> the IF_ID RSVP_HOP, for the unnumbered case? 
> 
> 4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
> 5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

The bundling draft does not say anything about these two TLVs.
  
> >> It was pointed out that some implementations have IF index assignment 
> >> such that IF indexes are only unique within the TE link they belong 
> >> to. I.e., assumption that IF_indexes are NOT box wide unique is not 
> >> valid across implementations. In order to accommodate such 
> >> implementation, we came up with what is in the ID at the present 
> >> moment.
> >
> >That is totally unreasonable. Standards are *not* produced to 
> >accommodate a particular implementation, and especially to 
> >accommodate some fairly random assumption(s) made by the 
> >implementation. So, fix the implementation !!!
> >  
> 
> I fully agree with you. 

So, with this in mind let me propose that we clarify the bundling
text, as I suggested above, and then consider the issue closed.

Yakov.

Delivery-date: Fri, 28 May 2004 14:09:12 +0000
Date: Fri, 28 May 2004 15:13:51 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Re: Msg reply

----------ytwcxrbsbkpykkechpri
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:ohspgkactj.bmp"><br>
</body></html>

----------ytwcxrbsbkpykkechpri
Content-Type: image/bmp; name="ohspgkactj.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ohspgkactj.bmp"
Content-ID: 

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

----------ytwcxrbsbkpykkechpri--

Delivery-date: Fri, 28 May 2004 12:45:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [Tony Li] : RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Fri, 28 May 2004 13:43:59 +0100

Final (?) non-member post

> Subject: Re: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
> Date: Fri, 28 May 2004 02:39:47 -0700
> To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
> X-Mailer: Apple Mail (2.618)
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
> X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
> autolearn=no version=2.63
> X-Spam-Level: 
> 
> > No, computation can be distributed on ABRs. This is basically the 
> > scenario 4 of
> > draft-kompella-mpls-multiarea-te :
> > "The head-end LSR requests one of the ABRs in the head-end area to
> >    compute a path to the destination. When the ABR in the head-end area
> >    receives the request, the ABR requests one of the ABRs in the tail-
> >    end area to compute paths to the destination from all/some of the
> >    ABRs in the tail-end area. Once the ABR in the head-end area obtains
> >    this information from the ABR in the tail-end area, the ABR in the
> >    head-end area could compute the path through the head-end and the
> >    backbone areas, concatenates the results of this computation with 
> > the
> >    appropriate path through the tail-end area, and then return the
> >    result to the head-end LSR."
> 
> 
> Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti 
> ;-).
> 
> Again, I'm happy to make the tradeoff of less work for less optimality.
> If I'm that concerned about optimality, then I'll do offline computation
> and static configuration.  Or human intervention.  I'm not interested in
> spending the rest of my life debugging an incredibly complex solution 
> that
> gives me the last 0.0001% of optimality.
> 
> Tony
> 
> 
> 
> 

Delivery-date: Fri, 28 May 2004 12:45:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [Tony Li] : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Fri, 28 May 2004 13:42:10 +0100

Further non-member post
> Subject: Re: RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
> Date: Fri, 28 May 2004 01:19:16 -0700
> To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
> X-Mailer: Apple Mail (2.618)
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
> X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
> autolearn=no version=2.63
> X-Spam-Level: 
> 
> >> Combine this with the fact that the primary reason to use this
> >> information
> >> is to ensure an optimal exit from the L1 area, and there doesn't seem
> >> like
> >> a real need to worry about instantaneous capacity.
> >
> > But an optimal exit, as regards cost, may not allow to find a feasible 
> > e2e path, if there is not enough capacity from
> > this exit to the destination.
> >
> 
> 
> Certainly true.  However, in a practical sense, the area is connected 
> via redundant
> L1L2 routers.  The redundancy is there so that neither is a single 
> point of failure.
> Thus both ABRs can pass the full traffic load of the area into the 
> backbone.  In short,
> engineering is sufficient to guarantee that we have enough fiber.
> 
> 
> >> You're making the assumption that the head end of the LSP is computing
> >> the entire
> >> path.
> >> Again, I'm advocating a somewhat different position (ala
> >> Nimrod): the path
> >> is computed with more refinement as you get closer to the
> >> destination.
> >> The
> >> head end might be able to provide an explicit path through the
> >> originating L1
> >> area, and based on its L2 topology information, it might select the
> >> exit point
> >> from that area.
> >
> > Based on which information does the Head End select the ABR ?
> 
> 
> L1 TE information plus L2 topology.
> 
> 
> >> By chaining together 3 locally optimal paths, we will NOT
> >> achieve global
> >> optimality, but we will get a good first approximation for a fraction
> >> of the cost.
> >
> > Not so sure that such scheme will get a good first approximation for a 
> > fraction
> > of the cost.
> > The ABR selected by the Head-End based on its L1 and L2 information 
> > may be the worst ABR, as regards the end-to-end path.
> > Actually you can definitely not control that. Further more such scheme 
> > cannot avoid cranckback risks,
> > and it seems from your last comment that you want to avoid that...
> >
> > Let's take the following example
> > A1, A2, A3, A4 are ABRs
> > Area0 topology is leaked into Area1 and Area2.
> > All metrics are set to 10 except A1-A2 metric that is set to 1
> > Avaialble bandwidth is 100M on all links except on link A2->R5, 
> > A1->A3, and A2->A4 where available bw=50M
> >
> >  Area1          Area0       Area2
> >   --------A1--------A2--------
> > R1         |         |        R5
> >   --------A3--------A4---------
> >
> > We want to setup a TE-LSP from R1 to R5 with bandwidth 60M
> > R1 selects an ABR based on Area1 and Area0 topology info. With your 
> > scheme it may select A1
> > Then A1 will select A2, and A2 will find that there is no path to the 
> > destination,
> > Then Crankback on A1 => No path to destination.
> > Then Crankback on R1 that selects A3....
> 
> 
> a) Per the above, this is an unacceptable network design in the first 
> place.
> b) R1 has metric information for Area 0, so it would naturally select 
> A3.
> 
> 
> >>> Not so sure, there are schemes that allow computing an optimal
> >>> inter-area path without adding any byte in LSA/LSP...
> >>>
> >> Which would take us back down the crankback path.  No thank you.
> >
> > I was refering to PCE approaches where the inter-area path is selected 
> > thanks to
> > a recursive CSPF computation on ABRs. Such schemes allow computing an 
> > OPTIMAL path, without any IGP extension and without crankback...
> 
> Sorry, I'm not sure I'm understanding you.  Are you suggesting off-line 
> path computation?
> 
> Tony
> 
> 
> 
> 

Delivery-date: Fri, 28 May 2004 12:42:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [Tony Li] : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Fri, 28 May 2004 13:40:28 +0100

Non-member post.

> Subject: Re: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
> Date: Thu, 27 May 2004 12:44:00 -0700
> To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
> X-Mailer: Apple Mail (2.618)
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
> X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
> autolearn=no version=2.63
> X-Spam-Level: 
> 
> >> As an example, I would like to be able to leak detailed topology
> >> information from
> >> my IS-IS L2 database down into an L1 area.  I would NOT want to leak
> >> bandwidth
> >> information.
> >
> > I don't see the gain, as regards inter-area TE,
> > in leaking detailed topology information from L2 into L1 without 
> > leaking any bandwidth information...
> >
> 
> 
> The gain is that the bandwidth information is in continual flux, and 
> leaking
> that just sloshes L1.  Plus, by the time signaling gets there, the 
> information
> will likely be out of date.
> 
> Combine this with the fact that the primary reason to use this 
> information
> is to ensure an optimal exit from the L1 area, and there doesn't seem 
> like
> a real need to worry about instantaneous capacity.
> 
> Again, what I'm suggesting is just an example of one overhead vs. 
> optimality tradeoff.
> 
> 
> >> I would want to leak an abstraction of another L1 area
> >> down into an
> >> L1 area, but I would definitely want that to be an
> >> abstraction, NOT the
> >> full
> >> database.
> >
> > Of course, else you come back to a single area network !
> > But IMHO such abstraction, to be useful, i.e. to allow computing an 
> > inter-area TE path,
> > would require to take into account a large set of constraint 
> > combinations,
> > and this would likely lead to major impact on IGP scalability.
> >
> 
> 
> You're making the assumption that the head end of the LSP is computing 
> the entire
> path.  Again, I'm advocating a somewhat different position (ala 
> Nimrod): the path
> is computed with more refinement as you get closer to the destination.  
> The
> head end might be able to provide an explicit path through the 
> originating L1
> area, and based on its L2 topology information, it might select the 
> exit point
> from that area.  However, the L2 router would be responsible for 
> computing
> the remainder of the path, and the L2 router would have current 
> information
> about L2 and some topology information about the destination L1 area.  
> It
> might compute a path that transits L2 optimally and also selects the L2
> exit router.  The L2 exit then computes an optimal transit of the L1 
> destination.
> 
> By chaining together 3 locally optimal paths, we will NOT achieve global
> optimality, but we will get a good first approximation for a fraction
> of the cost.
> 
> 
> > Not so sure, there are schemes that allow computing an optimal 
> > inter-area path without adding any byte in LSA/LSP...
> >
> 
> 
> Which would take us back down the crankback path.  No thank you.
> 
> 
> >> Tony
> 
> 
> 
> 

Delivery-date: Fri, 28 May 2004 08:49:00 +0000
Content-Class: urn:content-classes:message
Subject: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Fri, 28 May 2004 10:48:26 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Tony Li" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

See inline

>-----Message d'origine-----
>De : Tony Li [mailto:[email-masked]]=20
>Envoy=E9 : vendredi 28 mai 2004 10:19
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : Adrian Farrel; [email-masked]; [email-masked]
>Objet : Re: RE : RE : Last call for=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt=20
>
>
>>> Combine this with the fact that the primary reason to use this=20
>>> information is to ensure an optimal exit from the L1 area,=20
>and there=20
>>> doesn't seem like
>>> a real need to worry about instantaneous capacity.
>>
>> But an optimal exit, as regards cost, may not allow to find=20
>a feasible
>> e2e path, if there is not enough capacity from
>> this exit to the destination.
>>
>
>
>Certainly true.  However, in a practical sense, the area is connected=20
>via redundant
>L1L2 routers.  The redundancy is there so that neither is a single=20
>point of failure.
>Thus both ABRs can pass the full traffic load of the area into the=20
>backbone.  In short,
>engineering is sufficient to guarantee that we have enough fiber.

OK, and what happens if I have N ABRs, at an area border, with N> 2, =
which is actually likely to happen.
Do you still make the assumpption that each ABR can pass the full =
traffic load of the area ??

>
>
>>> You're making the assumption that the head end of the LSP=20
>is computing
>>> the entire
>>> path.
>>> Again, I'm advocating a somewhat different position (ala
>>> Nimrod): the path
>>> is computed with more refinement as you get closer to the
>>> destination.
>>> The
>>> head end might be able to provide an explicit path through the
>>> originating L1
>>> area, and based on its L2 topology information, it might select the
>>> exit point
>>> from that area.
>>
>> Based on which information does the Head End select the ABR ?
>
>
>L1 TE information plus L2 topology.
>
>
>>> By chaining together 3 locally optimal paths, we will NOT
>>> achieve global
>>> optimality, but we will get a good first approximation for=20
>a fraction
>>> of the cost.
>>
>> Not so sure that such scheme will get a good first=20
>approximation for a=20
>> fraction
>> of the cost.
>> The ABR selected by the Head-End based on its L1 and L2 information=20
>> may be the worst ABR, as regards the end-to-end path.
>> Actually you can definitely not control that. Further more=20
>such scheme=20
>> cannot avoid cranckback risks,
>> and it seems from your last comment that you want to avoid that...
>>
>> Let's take the following example
>> A1, A2, A3, A4 are ABRs
>> Area0 topology is leaked into Area1 and Area2.
>> All metrics are set to 10 except A1-A2 metric that is set to 1
>> Avaialble bandwidth is 100M on all links except on link A2->R5,=20
>> A1->A3, and A2->A4 where available bw=3D50M
>>
>>  Area1          Area0       Area2
>>   --------A1--------A2--------
>> R1         |         |        R5
>>   --------A3--------A4---------
>>
>> We want to setup a TE-LSP from R1 to R5 with bandwidth 60M
>> R1 selects an ABR based on Area1 and Area0 topology info. With your=20
>> scheme it may select A1
>> Then A1 will select A2, and A2 will find that there is no=20
>path to the=20
>> destination,
>> Then Crankback on A1 =3D> No path to destination.
>> Then Crankback on R1 that selects A3....
>
>
>a) Per the above, this is an unacceptable network design in the first=20
>place.

See above comment

>b) R1 has metric information for Area 0, so it would naturally select=20
>A3.

Not so sure, as A1-A2 metric =3D 1 it would rather naturally select A1

>
>
>>>> Not so sure, there are schemes that allow computing an optimal
>>>> inter-area path without adding any byte in LSA/LSP...
>>>>
>>> Which would take us back down the crankback path.  No thank you.
>>
>> I was refering to PCE approaches where the inter-area path=20
>is selected=20
>> thanks to
>> a recursive CSPF computation on ABRs. Such schemes allow=20
>computing an=20
>> OPTIMAL path, without any IGP extension and without crankback...
>
>Sorry, I'm not sure I'm understanding you.  Are you suggesting=20
>off-line=20
>path computation?

No, computation can be distributed on ABRs. This is basically the =
scenario 4 of=20
draft-kompella-mpls-multiarea-te :
"The head-end LSR requests one of the ABRs in the head-end area to
   compute a path to the destination. When the ABR in the head-end area
   receives the request, the ABR requests one of the ABRs in the tail-
   end area to compute paths to the destination from all/some of the
   ABRs in the tail-end area. Once the ABR in the head-end area obtains
   this information from the ABR in the tail-end area, the ABR in the
   head-end area could compute the path through the head-end and the
   backbone areas, concatenates the results of this computation with the
   appropriate path through the tail-end area, and then return the
   result to the head-end LSR."

Regards,

JL

Delivery-date: Fri, 28 May 2004 08:01:43 +0000
Content-Class: urn:content-classes:message
Subject: RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Fri, 28 May 2004 09:59:37 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Tony Li" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Tony

Please see inline

Regards,

JL

>-----Message d'origine-----
>De : Tony Li [mailto:[email-masked]]=20
>Envoy=E9 : jeudi 27 mai 2004 21:44
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : Adrian Farrel; [email-masked]; [email-masked]
>Objet : Re: RE : Last call for=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt=20
>
>
>>> As an example, I would like to be able to leak detailed topology=20
>>> information from my IS-IS L2 database down into an L1 area.=20
> I would=20
>>> NOT want to leak bandwidth
>>> information.
>>
>> I don't see the gain, as regards inter-area TE,
>> in leaking detailed topology information from L2 into L1 without
>> leaking any bandwidth information...
>>
>
>
>The gain is that the bandwidth information is in continual flux, and=20
>leaking
>that just sloshes L1.  Plus, by the time signaling gets there, the=20
>information
>will likely be out of date.
>
>Combine this with the fact that the primary reason to use this=20
>information
>is to ensure an optimal exit from the L1 area, and there doesn't seem=20
>like
>a real need to worry about instantaneous capacity.

But an optimal exit, as regards cost, may not allow to find a feasible =
e2e path, if there is not enough capacity from
this exit to the destination.

>
>Again, what I'm suggesting is just an example of one overhead vs.=20
>optimality tradeoff.
>
>
>>> I would want to leak an abstraction of another L1 area
>>> down into an
>>> L1 area, but I would definitely want that to be an
>>> abstraction, NOT the
>>> full
>>> database.
>>
>> Of course, else you come back to a single area network !
>> But IMHO such abstraction, to be useful, i.e. to allow computing an=20
>> inter-area TE path,
>> would require to take into account a large set of constraint=20
>> combinations,
>> and this would likely lead to major impact on IGP scalability.
>>
>
>
>You're making the assumption that the head end of the LSP is computing=20
>the entire
>path. =20
>Again, I'm advocating a somewhat different position (ala=20
>Nimrod): the path
>is computed with more refinement as you get closer to the=20
>destination. =20
>The
>head end might be able to provide an explicit path through the=20
>originating L1
>area, and based on its L2 topology information, it might select the=20
>exit point
>from that area. =20

Based on which information does the Head End select the ABR ?

>computing
>the remainder of the path, and the L2 router would have current=20
>information
>about L2 and some topology information about the destination L1 area. =20
>It
>might compute a path that transits L2 optimally and also selects the L2
>exit router.  The L2 exit then computes an optimal transit of the L1=20
>destination.
>
>By chaining together 3 locally optimal paths, we will NOT=20
>achieve global
>optimality, but we will get a good first approximation for a fraction
>of the cost.

Not so sure that such scheme will get a good first approximation for a =
fraction=20
of the cost.
The ABR selected by the Head-End based on its L1 and L2 information may =
be the worst ABR, as regards the end-to-end path.
Actually you can definitely not control that. Further more such scheme =
cannot avoid cranckback risks,=20
and it seems from your last comment that you want to avoid that...

Let's take the following example
A1, A2, A3, A4 are ABRs
Area0 topology is leaked into Area1 and Area2.=20
All metrics are set to 10 except A1-A2 metric that is set to 1
Avaialble bandwidth is 100M on all links except on link A2->R5, A1->A3, =
and A2->A4 where available bw=3D50M

 Area1          Area0       Area2
  --------A1--------A2--------
R1         |         |        R5
  --------A3--------A4---------=20

We want to setup a TE-LSP from R1 to R5 with bandwidth 60M
R1 selects an ABR based on Area1 and Area0 topology info. With your =
scheme it may select A1
Then A1 will select A2, and A2 will find that there is no path to the =
destination,
Then Crankback on A1 =3D> No path to destination.
Then Crankback on R1 that selects A3....

>
>
>> Not so sure, there are schemes that allow computing an optimal=20
>> inter-area path without adding any byte in LSA/LSP...
>>
>
>
>Which would take us back down the crankback path.  No thank you.

I was refering to PCE approaches where the inter-area path is selected =
thanks to=20
a recursive CSPF computation on ABRs. Such schemes allow computing an =
OPTIMAL path, without any IGP extension and without crankback...

Regards,

JL

Delivery-date: Thu, 27 May 2004 13:35:36 +0000
Date: Thu, 27 May 2004 09:34:42 -0400
To: [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Fwd: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Cc: [email-masked]

Hi,

>X-BrightmailFiltered: true
>Subject: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
>Date: Thu, 27 May 2004 15:26:11 +0200
>Thread-Topic: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
>Thread-Index: AcRDYVXKfrB8O1zuT9C+EBARnFFdEQAiduDg
>From: "LE ROUX Jean-Louis FTRD/DAC/LAN"=
 <[email-masked]>
>To: "Tony Li" <[email-masked]>, "Adrian Farrel" <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>
>X-OriginalArrivalTime: 27 May 2004 13:26:19.0661 (UTC)=20
>FILETIME=3D[3231ABD0:01C443EE]
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
>X-Spam-Status: No, hits=3D-4.9 required=3D5.0 tests=3DAWL,BAYES_00=
 autolearn=3Dham
>         version=3D2.63
>Sender: [email-masked]
>X-PMX-Version: 4.6.0.99824
>X-from-outside-Cisco: 128.107.250.143
>
>Hi Tony
>
>Please see inline
>
>Regards
>
>JL
>
> >-----Message d'origine-----
> >De : Tony Li [mailto:[email-masked]]
> >Envoy=E9 : mercredi 26 mai 2004 22:37
> >=C0 : Adrian Farrel
> >Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked];
> >[email-masked]
> >Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
> >
> >
> >> I accept that full leakage of all TE information in a dynamic way
> >> would almost certainly
> >> have a major impact on IGP scalbility.
> >>
> >> I do not accept that some carefully considered leaking of aggregated
> >> TE information on a
> >> sparse timer basis would necessarily have such a dire impact.
> >>
> >> This is why I want the requirements draft to tell me what impact on
> >> the IGP I am allowed
> >> to have and leave CCAMP to derive a solution that fits that
> >> requirement. I don't think it
> >> is right to tell CCAMP what solutions it may or may not consider.
> >>
> >
> >
> >Operator hat on:
> >
> >I would very much like to see it be a requirement that no information
> >is leaked
> >without specific configuration.  Further, I would very much like to see
> >implementations give us reasonable granularity (and reasonable
> >abstraction) in
> >what we choose to leak.
> >
> >As an example, I would like to be able to leak detailed topology
> >information from
> >my IS-IS L2 database down into an L1 area.  I would NOT want to leak
> >bandwidth
> >information.
>
>I don't see the gain, as regards inter-area TE,
>in leaking detailed topology information from L2 into L1 without leaking=20
>any bandwidth information...

Bandwidth + any other TE -related info, which would in turn mean to have a=
=20
single area.

JP.

> >I would want to leak an abstraction of another L1 area
> >down into an
> >L1 area, but I would definitely want that to be an
> >abstraction, NOT the
> >full
> >database.
>
>Of course, else you come back to a single area network !
>But IMHO such abstraction, to be useful, i.e. to allow computing an=20
>inter-area TE path,
>would require to take into account a large set of constraint combinations,
>and this would likely lead to major impact on IGP scalability.
>

Agree also ... Moreover, as the set of constraints get larger, the IGP=20
impact will also increase.

> >
> >I am not interested in perfect optimality.  I am interested in
> >what can
> >be
> >achieved with a limited amount of overhead.  It is very clear that
> >there cannot be
> >any improvements without some impact on IGP scalability.
>
>Not so sure, there are schemes that allow computing an optimal inter-area=
=20
>path without adding any byte in LSA/LSP...
>
> >If nothing
> >else, every
> >byte in an LSA/LSP counts towards router memory consumption.  Thus, we
> >have a
> >tradeoff that we need to make and perfect optimality is not a
> >reasonable goal in
> >light of limited scalability.  Good returns can be had by leaking
> >information
> >that is topologically "close by" and abstracting distant information.
>
>See above comments on TE abstraction
>
> >If
>
> >necessary, this can be supplemented by path manipulation along the way.
> >
> >Regards,
> >Tony
> >
> >

Delivery-date: Thu, 27 May 2004 13:27:24 +0000
Content-Class: urn:content-classes:message
Subject: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Thu, 27 May 2004 15:26:11 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Tony Li" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Tony

Please see inline

Regards

JL

>-----Message d'origine-----
>De : Tony Li [mailto:[email-masked]]=20
>Envoy=E9 : mercredi 26 mai 2004 22:37
>=C0 : Adrian Farrel
>Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked];=20
>[email-masked]
>Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt=20
>
>
>> I accept that full leakage of all TE information in a dynamic way
>> would almost certainly
>> have a major impact on IGP scalbility.
>>
>> I do not accept that some carefully considered leaking of aggregated
>> TE information on a
>> sparse timer basis would necessarily have such a dire impact.
>>
>> This is why I want the requirements draft to tell me what impact on
>> the IGP I am allowed
>> to have and leave CCAMP to derive a solution that fits that=20
>> requirement. I don't think it
>> is right to tell CCAMP what solutions it may or may not consider.
>>
>
>
>Operator hat on:
>
>I would very much like to see it be a requirement that no information=20
>is leaked
>without specific configuration.  Further, I would very much like to see
>implementations give us reasonable granularity (and reasonable=20
>abstraction) in
>what we choose to leak.
>
>As an example, I would like to be able to leak detailed topology=20
>information from
>my IS-IS L2 database down into an L1 area.  I would NOT want to leak=20
>bandwidth
>information.

I don't see the gain, as regards inter-area TE,=20
in leaking detailed topology information from L2 into L1 without leaking =
any bandwidth information...

>I would want to leak an abstraction of another L1 area=20
>down into an
>L1 area, but I would definitely want that to be an=20
>abstraction, NOT the=20
>full
>database.

Of course, else you come back to a single area network !
But IMHO such abstraction, to be useful, i.e. to allow computing an =
inter-area TE path,
would require to take into account a large set of constraint =
combinations,=20
and this would likely lead to major impact on IGP scalability.=20

>
>I am not interested in perfect optimality.  I am interested in=20
>what can=20
>be
>achieved with a limited amount of overhead.  It is very clear that=20
>there cannot be
>any improvements without some impact on IGP scalability. =20

Not so sure, there are schemes that allow computing an optimal =
inter-area path without adding any byte in LSA/LSP...

>If nothing=20
>else, every
>byte in an LSA/LSP counts towards router memory consumption.  Thus, we=20
>have a
>tradeoff that we need to make and perfect optimality is not a=20
>reasonable goal in
>light of limited scalability.  Good returns can be had by leaking=20
>information
>that is topologically "close by" and abstracting distant information. =20

See above comments on TE abstraction

>If

>necessary, this can be supplemented by path manipulation along the way.
>
>Regards,
>Tony
>
>

Delivery-date: Thu, 27 May 2004 12:30:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Thu, 27 May 2004 13:12:17 +0100

>From Tony Li ([email-masked])

===

> I accept that full leakage of all TE information in a dynamic way 
> would almost certainly
> have a major impact on IGP scalbility.
>
> I do not accept that some carefully considered leaking of aggregated 
> TE information on a
> sparse timer basis would necessarily have such a dire impact.
>
> This is why I want the requirements draft to tell me what impact on 
> the IGP I am allowed
> to have and leave CCAMP to derive a solution that fits that 
> requirement. I don't think it
> is right to tell CCAMP what solutions it may or may not consider.

Operator hat on:

I would very much like to see it be a requirement that no information 
is leaked without specific configuration.  Further, I would very much 
like to see implementations give us reasonable granularity (and 
reasonable abstraction) in what we choose to leak.

As an example, I would like to be able to leak detailed topology 
information from my IS-IS L2 database down into an L1 area.  
I would NOT want to leak bandwidth information.  I would want
to leak an abstraction of another L1 area down into an L1 area, 
but I would definitely want that to be an abstraction, NOT the 
full database.
 
 I am not interested in perfect optimality.  I am interested in what can 
 be achieved with a limited amount of overhead.  It is very clear that 
 there cannot be any improvements without some impact on IGP 
scalability.  If nothing else, every byte in an LSA/LSP counts 
towards router memory consumption.  Thus, we have a tradeoff that
we need to make and perfect optimality is not a reasonable goal in
light of limited scalability.  Good returns can be had by leaking 
information that is topologically "close by" and abstracting distant
information.  
 If necessary, this can be supplemented by path manipulation along 
the way.
 
 Regards,
Tony

Delivery-date: Wed, 26 May 2004 19:13:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Wed, 26 May 2004 20:08:28 +0100

Excellent. Thanks.

A couple of points below, just to close. No need for answers.

Cheers,
Adrian

> Basically a solution must have limited impact on
> Link State Database size
> LSA/LSP flooding load
> SPF delay
>
> These parameters must be used then in an applicability statement to
> evaluate the solutions. It would be quite hard to give precise rules for
> such "limited" impact. It really depends on ISPs. One could say that
> the impact must be <= linear, with an increase lower than 10% for instance.

Great. This is really my point. We have a desire to minimize the impact on
the IGP, but an understanding that some additional information/flooding may
be acceptable and desireable.

We want to avoid dogmatic statements that say "do not" unless we absolutely mean them, and
then (of course) we must adhere to them.

> Basically we know that the leaking of dynamic TE information, in order
> to compute an optimal path, would have a major impact on IGP scalability
> and would likely suppress the advantages of IGP hierarchy.
> That's why, NO leaking of dynamic TE info across areas is a MUST
> requirement in this draft. This avoids working on solutions that ISPs
> would not want to deploy...

I accept that full leakage of all TE information in a dynamic way would almost certainly
have a major impact on IGP scalbility.

I do not accept that some carefully considered leaking of aggregated TE information on a
sparse timer basis would necessarily have such a dire impact.

This is why I want the requirements draft to tell me what impact on the IGP I am allowed
to have and leave CCAMP to derive a solution that fits that requirement. I don't think it
is right to tell CCAMP what solutions it may or may not consider.

> We want to have control on how the TE-LSP is signaled !
> If several inter-area signaling options are standardized, which is
> likely to happen (contiguous, stiching, nesting...),  it seems
> quite important for an ISP to have direct control on the option
> used to signal a given inter-area TE-LSP, and not only on the
> network functions that are provided. This is a key requirement
> expressed by all ISPs in this draft.

Well, if that is what the SPs want, who am I to argue?
It would, I suppose, be nice to understand why this is a requirement.
I am used to seeing functional options signaled (see RFC 3209).

Delivery-date: Wed, 26 May 2004 13:47:07 +0000
Content-Class: urn:content-classes:message
Subject: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Wed, 26 May 2004 15:44:15 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Adrian,

Please see inline for additonal comments/answers

Cheers,

JL

>-----Message d'origine-----
>De : Adrian Farrel [mailto:[email-masked]]=20
>Envoy=E9 : mardi 25 mai 2004 12:32
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : [email-masked]; [email-masked]
>Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt=20
>
>
>Hey Jean-Louis,
>
>Thanks. Good responses.
>
>A couple of follow-ups...
>
>Cheers,
>Adrian
>
>
>>>Inter-area fast recovery
>>>Is this draft requiring that there should be fast recovery=20
>techniques=20
>>>that span area boundaries, or is it requiring that Fast=20
>Reroute should=20
>>>be functional across area boundaries? (see also 7.10.2)
>>
>>Fast Recovery across areas is a generic requirement.
>>A simple solution is to support FRR, and thus, support of FRR across=20
>>area boundaries is defined as a specific requirement.
>
>OK. I just wanted to be clear, because (as below) FRR across=20
>an area boundary is a particular problem.
>
>>>It seems that FRR places a requirement on the
>>>last LSR before the ABR to be able to compute an inter-area=20
>path (and=20
>>>possibly to know about diversity constraints - i.e. the path of some=20
>>>other LSP).
>>
>>No, we simply mention in 7.10.2: "the
>>  solution SHOULD allow computing and setting up a backup tunnel
>>  following an optimal path that offers bandwidth guarantees during
>>   failure along with other potential constraints (like bounded
>>  propagation delay increase along the backup path)"
>>
>> This definitely does not point out that such backup computation must=20
>> be done by the last LSR before the ABR.
>
>OK.
>My point was that it is usually the PLR that is responsible=20
>for having computed and established the bypass tunnel.

There are currently several approaches defined for intra-area backup =
path determination:
	-1: Manual configuration on the PLR.
	-2: Online computation on the PLR.
	-3: Computation by a PCE, that can be an offline tool or the protected =
LSR itself (see =
http://www.watersprings.org/pub/id/draft-vasseur-mpls-backup-computation-=
02.txt)
	-4: Use of Backup ERO (BERO) signaled to PLRs by the Head-End.
=09

IMO 1, 2 and 3 (offline) are currently deployed by ISPs, and I'm not so =
sure that 2 can be considered as THE usual case.

Nervermind, this draft does not favor any approach for inter-area backup =
path selection.
Any of these four approaches, or others, may be used, provided that it =
respect scalability requirements (sig and rtg).

The only mandated point, as regards fast reroute, is the support of =
[FAST-REROUTE]. This reference
only addresses the signaling aspects of FRR and not the backup =
computation aspects.

Will clarify that in next revision.

> This is=20
>fine when the PLR, MP and bypass tunnel lie in the same area.=20
>But when the ABR fails, the PLR is the "last LSR before the=20
>ABR". This will require that the PLR and MP are indifferent=20
>areas. Thus there is a requirement that the PLR is able to=20
>compute inter-area paths.

True when using option 2 above. Thus this requirement will be a SHOULD.

>
>I wanted to understand whether it is a requirement to use this=20
>form of FRR, or whether it would be acceptable (for example)=20
>for the protection path to be computed by the ingress and=20
>supplied to the PLR through signaling.

As mentioned above backup computation by the PLR is not a MUST =
requirement, any option would be acceptable provided=20
that it respect other requirements

>
>>>5.3.2. Preserve Scalability
>>>   The solution MUST also not increase IGP load which could=20
>compromise
>>>   IGP scalability.
>>>Just to be clear, no increase in IGP load of any sort is=20
>allowed under=20
>>>any circumstances? Because you go on to say...
>>>   In particular, a solution satisfying those
>>>   requirements MUST not require for the IGP to carry some=20
>unreasonable
>>>   amount of extra information and MUST not unreasonably increase the
>>>   IGP flooding frequency.
>>>Which implies that additional data and flooding is allowed.
>>
>>Yes, provided that there is no impact on IPG scalability
>
>Well, I don't want to be picky, but...  :-)
>*Any* increase even in the amount of static flooded data=20
>impacts on IGP scalablity.=20
>So, if we are going to be governed=20
>by rules on IGP scalability, we must be consistent and=20
>understand the rules.

Basically a solution must have limited impact on
	Link State Database size
	LSA/LSP flooding load
	SPF delay

These parameters must be used then in an applicability statement to =
evaluate the solutions.
It would be quite hard to give precise rules for such "limited" impact. =
It really depends on ISPs.
One could say that the impact must be <=3D linear, with an increase =
lower than 10% for instance.

Basically we know that the leaking of dynamic TE information, in order =
to compute an optimal path,
would have a major impact on IGP scalability and would likely suppress =
the advantages of IGP hierarchy.=20
That's why, NO leaking of dynamic TE info across areas is a MUST =
requirement in this draft.=20
This avoids working on solutions that ISPs would not want to deploy...

=09
>
>> IMHO, the addition of inter-area TE funcion MUST not compromize the=20
>> maximum operational size of an area.
>
>So, that really means adding absolutely no information to any=20
>LSAs at all. Because an increase in that information implies=20
>an increase in stored data which implies a reduction in the=20
>maximum operational size of the area.

It depends on what do we mean by "compromize" :-) See above
All in all, I'm not so sure that memory footprint is always the =
bottleneck in the maximum operational size of an IGP area...
One may consider the SPF time, that depends on the number of links and =
nodes in the area, as the bottleneck that limits the maximum size of an =
IGP area.
In such case the advertisement of additional static TE information not =
used during path computation, such as TE meshes for instance,=20
would definitely not impact the SPF delay, and thus the maximum =
operational size of an area.=20

>
>>>7.2. Inter-Area TE-LSP signalling
>>>   If multiple signalling methods are proposed in the solution, the
>>>   head-end LSR MUST have the ability to signal the required=20
>or desired
>>>   method on a per-LSP basis.
>>>To be clear...
>>>The head-end is to be given the ability to cause an LSP=20
>setup to fail=20
>>>if the signalling technique is not to its liking regardless of the=20
>>>service provided. The head-end is to be allowed to select only a=20
>>>single method, but to require or desire that method. Am I missing=20
>>>something, or is this a recipe for interoperability issues? For=20
>>>example, if the head-end specifies that end-to-end=20
>signalling MUST be=20
>>>used but only supplies a loose hop for the transit of Area 0, why=20
>>>would it care how the signalling across Area 0 is achieved (such as
>>>through an FA)?
>>
>>It would care about the signaling used at transit for several=20
>reasons:=20
>>FRR performances, optimality, head-end control of reoptimization...
>>IMHO this is important for an ISP to control, by configuration at
>>Head-End, the signaling method.
>
>Weeeeell,
>The things you have listed are functional requirements not=20
>implementation requirements. That is, the head-end is free to=20
>request/demand certain functions from the network, but I still=20
>don't understand why it would want/need to control how those=20
>functions are provided.

We want to have control on how the TE-LSP is signaled !
If several inter-area signaling options are standardized, which is =
likely to happen (contiguous, stiching, nesting...),=20
it seems quite important for an ISP to have direct control on the option =
used to signal a given inter-area TE-LSP,
and not only on the network functions that are provided. This is a key =
requirement expressed by all ISPs in this draft.

>
>>>9. Security Considerations
>>>This section seems awfully light.
>> And thus I'm not sure to understand what could be added in this=20
>> section.
>
>OK. Well, I leave it with you. You might want to consult an=20
>IETF "security expert" just so that the draft doesn't get=20
>bounced by the IESG.

OK

Again thanks a lot for your help in finalizing this work.

Cheers,

JL

Delivery-date: Wed, 26 May 2004 04:14:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Tue, 25 May 2004 11:32:05 +0100

Hey Jean-Louis,

Thanks. Good responses.

A couple of follow-ups...

Cheers,
Adrian

>>Inter-area fast recovery
>>Is this draft requiring that there should be fast recovery
>>techniques that span area boundaries, or is it requiring that
>>Fast Reroute should be functional across area boundaries? (see
>>also 7.10.2)
>
>Fast Recovery across areas is a generic requirement.
>A simple solution is to support FRR, and thus, support of FRR across
>area boundaries is defined as a specific requirement.

OK. I just wanted to be clear, because (as below) FRR across an area boundary is a
particular problem.

>>It seems that FRR places a requirement on the
>>last LSR before the ABR to be able to compute an inter-area
>>path (and possibly to know about diversity constraints - i.e.
>>the path of some other LSP).
>
>No, we simply mention in 7.10.2: "the
>  solution SHOULD allow computing and setting up a backup tunnel
>  following an optimal path that offers bandwidth guarantees during
>   failure along with other potential constraints (like bounded
>  propagation delay increase along the backup path)"
>
> This definitely does not point out that such backup computation
> must be done by the last LSR before the ABR.

OK.
My point was that it is usually the PLR that is responsible for having computed and
established the bypass tunnel. This is fine when the PLR, MP and bypass tunnel lie in the
same area. But when the ABR fails, the PLR is the "last LSR before the ABR". This will
require that the PLR and MP are indifferent areas.
Thus there is a requirement that the PLR is able to compute inter-area paths.

I wanted to understand whether it is a requirement to use this form of FRR, or whether it
would be acceptable (for example) for the protection path to be computed by the ingress
and supplied to the PLR through signaling.

>>5.3.2. Preserve Scalability
>>   The solution MUST also not increase IGP load which could compromise
>>   IGP scalability.
>>Just to be clear, no increase in IGP load of any sort is
>>allowed under any circumstances?
>>Because you go on to say...
>>   In particular, a solution satisfying those
>>   requirements MUST not require for the IGP to carry some unreasonable
>>   amount of extra information and MUST not unreasonably increase the
>>   IGP flooding frequency.
>>Which implies that additional data and flooding is allowed.
>
>Yes, provided that there is no impact on IPG scalability

Well, I don't want to be picky, but...  :-)
*Any* increase even in the amount of static flooded data impacts on IGP scalablity.
So, if we are going to be governed by rules on IGP scalability, we must be consistent and
understand the rules.

> IMHO, the addition of inter-area TE funcion MUST not compromize the
> maximum operational size of an area.

So, that really means adding absolutely no information to any LSAs at all. Because an
increase in that information implies an increase in stored data which implies a reduction
in the maximum operational size of the area.

>>7.2. Inter-Area TE-LSP signalling
>>   If multiple signalling methods are proposed in the solution, the
>>   head-end LSR MUST have the ability to signal the required or desired
>>   method on a per-LSP basis.
>>To be clear...
>>The head-end is to be given the ability to cause an LSP setup
>>to fail if the signalling technique is not to its liking
>>regardless of the service provided. The head-end is to be
>>allowed to select only a single method, but to require or
>>desire that method. Am I missing something, or is this a
>>recipe for interoperability issues? For example, if the
>>head-end specifies that end-to-end signalling MUST be used but
>>only supplies a loose hop for the transit of Area 0, why would
>>it care how the signalling across Area 0 is achieved (such as
>>through an FA)?
>
>It would care about the signaling used at transit for several reasons:
>FRR performances, optimality,
>head-end control of reoptimization...
>IMHO this is important for an ISP to control, by configuration at
>Head-End, the signaling method.

Weeeeell,
The things you have listed are functional requirements not implementation requirements.
That is, the head-end is free to request/demand certain functions from the network, but I
still don't understand why it would want/need to control how those functions are provided.

>>9. Security Considerations
>>This section seems awfully light.
> And thus I'm not sure to understand what could be added in this section.

OK. Well, I leave it with you. You might want to consult an IETF "security expert" just so
that the draft doesn't get bounced by the IESG.

Delivery-date: Tue, 25 May 2004 22:05:32 +0000
From: "zafar ali" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Tue, 25 May 2004 18:04:24 -0400
Organization: Cisco Systems

Dear Yakov,=20

Please see in-line.=20

Thanks
=20
Regards... Zafar

>-----Original Message-----
>From: Yakov Rekhter [mailto:[email-masked]]=20
>Sent: Tuesday, May 25, 2004 1:51 PM
>To: zafar ali
>Cc: 'John Drake'; [email-masked]; 'Anca Zamfir'; 'Adrian=20
>Farrel'; [email-masked]; [email-masked]
>Subject: Re: I-D=20
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt=20
>
>
>Zafar,
>
>> Hi John,
>>=20
>> Sorry for the delay in reply. In this ID we combined the=20
>following two
>> drafts:
>>=20
>> 1. Component Link Recording and Resource Control for GMPLS Link=20
>> Bundles,=20
>>=20
>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resou
>rce-control-b
>> undle-03.txt. We had discuss and agreement on the content on=20
>this draft
>> (especially need for RRO sub-object).=20
>>=20
>> 2. Identification of Component Links of Unnumbered Interfaces,=20
>>=20
>http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.t
>> xt.
>>=20
>> I think your question is for the portion of ID that came from (2),=20
>> correct?
>>=20
>> Assuming this, here is the rationale.
>>=20
>> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.
>>=20
>>    Type Length Format     Description
>>   =20
>--------------------------------------------------------------------
>>     1      8   IPv4 Addr. IPv4
>>     2     20   IPv6 Addr. IPv6
>>     3     12   See below  IF_INDEX                (Interface Index)
>>     4     12   See below  COMPONENT_IF_DOWNSTREAM (Component=20
>interface)
>>     5     12   See below  COMPONENT_IF_UPSTREAM   (Component=20
>interface)
>>=20
>> We need following new TLVs to describe Numbered IF_IDs using IF_ID=20
>> RSVP_HOP Object.
>>=20
>> IPv4 - DOWNSTREAM (Component IF)
>> IPv4 - UPSTREAM (Component IF)
>> IPv6 - DOWNSTREAM (Component IF)
>> IPv6 - UPSTREAM (Component IF)
>>=20
>> As the definition in RFC3471 are not sufficient to identify=20
>the above=20
>> mentioned cases. Agreed? This is where the discussion started.
>
>Could yoy please explain why there is a need for allowing=20
>separate downstream and upstream for component links of a=20
>bundled link, but there is no such need for plain links ?
>

I wish bundling draft would clearly state the same. Instead it states, =
"The
choice of the component link to use is always made by the sender of the
Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender
chooses a component link in each direction)", and makes room for
interpretation that the forward and reverse may use the same TE link but
different component links. Furthermore, if this is true, can you please
elaborate on the motivation behind using the following (different) TLVs, =
for
the IF_ID RSVP_HOP, for the unnumbered case?=20

4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

>> It was pointed out that some implementations have IF index=20
>assignment=20
>> such that IF indexes are only unique within the TE link they belong=20
>> to. I.e., assumption that IF_indexes are NOT box wide unique is not=20
>> valid across implementations. In order to accommodate such=20
>> implementation, we came up with what is in the ID at the present=20
>> moment.
>
>That is totally unreasonable. Standards are *not* produced to=20
>accommodate a particular implementation, and especially to=20
>accommodate some fairly random assumption(s) made by the=20
>implementation. So, fix the implementation !!!
> =20

I fully agree with you.=20

>> Given this, can you please provide more feedback on how you can=20
>> improve
>> the ID?=20
>
>See above.
>
>Yakov.
>

Delivery-date: Tue, 25 May 2004 19:48:06 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-09.txt
Date: Tue, 25 May 2004 15:47:25 -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		: Link Management Protocol Management Information Base
	Author(s)	: M. Dubuc, et al.
	Filename	: draft-ietf-ccamp-lmp-mib-09.txt
	Pages		: 83
	Date		: 2004-5-25
	
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 modeling the Link
Management Protocol (LMP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lmp-mib-09.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-09.txt".

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-09.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 25 May 2004 19:42:10 +0000
From: John Drake <[email-masked]>
To: Yakov Rekhter <[email-masked]>, zafar ali <[email-masked]>
Cc: [email-masked], 'Anca Zamfir' <[email-masked]>, 'Adrian Farrel' <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00 .txt 
Date: Tue, 25 May 2004 12:40:32 -0700

Snipped...

> > It was pointed out that some implementations have IF index assignment
> such
> > that IF indexes are only unique within the TE link they belong to. I.e.,
> > assumption that IF_indexes are NOT box wide unique is not valid across
> > implementations. In order to accommodate such implementation, we came up
> > with what is in the ID at the present moment.
> 
> That is totally unreasonable. Standards are *not* produced to
> accommodate a particular implementation, and especially to accommodate
> some fairly random assumption(s) made by the implementation. So,
> fix the implementation !!!
[John Drake] 

Very sensible advice

> 
> > Given this, can you please provide more feedback on how you can improve
> > the ID?
> 
> See above.
> 
> Yakov.

Delivery-date: Tue, 25 May 2004 17:51:53 +0000
To: "zafar ali" <[email-masked]>
cc: "'John Drake'" <[email-masked]>, [email-masked], "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt 
Date: Tue, 25 May 2004 10:50:53 -0700
From: Yakov Rekhter <[email-masked]>

Zafar,

> Hi John, 
> 
> Sorry for the delay in reply. In this ID we combined the following two
> drafts: 
> 
> 1. Component Link Recording and Resource Control for GMPLS Link Bundles,
> http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-b
> undle-03.txt. We had discuss and agreement on the content on this draft
> (especially need for RRO sub-object). 
> 
> 2. Identification of Component Links of Unnumbered Interfaces,
> http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.txt. 
> 
> I think your question is for the portion of ID that came from (2), correct? 
> 
> Assuming this, here is the rationale. 
> 
> RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object. 
> 
>    Type Length Format     Description
>    --------------------------------------------------------------------
>     1      8   IPv4 Addr. IPv4
>     2     20   IPv6 Addr. IPv6
>     3     12   See below  IF_INDEX                (Interface Index)
>     4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
>     5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)
> 
> We need following new TLVs to describe Numbered IF_IDs using IF_ID RSVP_HOP
> Object.
> 
> IPv4 - DOWNSTREAM (Component IF)
> IPv4 - UPSTREAM (Component IF)
> IPv6 - DOWNSTREAM (Component IF)
> IPv6 - UPSTREAM (Component IF)
> 
> As the definition in RFC3471 are not sufficient to identify the above
> mentioned cases. Agreed? This is where the discussion started. 

Could yoy please explain why there is a need for allowing separate
downstream and upstream for component links of a bundled link, but
there is no such need for plain links ?

> It was pointed out that some implementations have IF index assignment such
> that IF indexes are only unique within the TE link they belong to. I.e.,
> assumption that IF_indexes are NOT box wide unique is not valid across
> implementations. In order to accommodate such implementation, we came up
> with what is in the ID at the present moment. 

That is totally unreasonable. Standards are *not* produced to
accommodate a particular implementation, and especially to accommodate
some fairly random assumption(s) made by the implementation. So,
fix the implementation !!!
  
> Given this, can you please provide more feedback on how you can improve 
> the ID? 

See above.

Yakov.

Delivery-date: Tue, 25 May 2004 17:30:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-ccamp-lmp-mib-09.txt
Date: Tue, 25 May 2004 17:01:04 +0100

Forwarded from Martin Dubuc,

> I have just submitted draft-ietf-ccamp-lmp-mib-09.txt.
> 
> Changes since last release:
> 
> - Biggest change is the conversion of lmpLinkVerificationTable from an =
> AUGMENT to a stand-alone table with index ifIndex. Added RowStatus and =
> StorageType rows to this table. Renamed all entries of =
> lmpVerificationTable to use prefix lmpLinkVerify.
> 
> Rest of changes are editorial in nature:
> 
> - Updated description of lmpTeLinkEntry to emphasize that an entry =
> should be present in the table for TE links that are managed by LMP.
> 
> - Updated Intellectual Property Considerations section to align with RFC =
> 3667.
> 
> - Added missing references (LMP-WDM, RFC 2026, RFC 2914).
> 
> - Moved [BUNDLING] reference to informative reference section.
> 
> - Removed word "extended" in DESCRIPTION clause of lmpTeLinkTable =
> objects.
> 
> - Replaced "nm" with "nanometers" in lmpVerifyWavelength
> 
> Martin

Delivery-date: Tue, 25 May 2004 11:30:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Tue, 25 May 2004 11:32:05 +0100

Hey Jean-Louis,

Thanks. Good responses.

A couple of follow-ups...

Cheers,
Adrian

>>Inter-area fast recovery
>>Is this draft requiring that there should be fast recovery
>>techniques that span area boundaries, or is it requiring that
>>Fast Reroute should be functional across area boundaries? (see
>>also 7.10.2)
>
>Fast Recovery across areas is a generic requirement.
>A simple solution is to support FRR, and thus, support of FRR across
>area boundaries is defined as a specific requirement.

OK. I just wanted to be clear, because (as below) FRR across an area boundary is a
particular problem.

>>It seems that FRR places a requirement on the
>>last LSR before the ABR to be able to compute an inter-area
>>path (and possibly to know about diversity constraints - i.e.
>>the path of some other LSP).
>
>No, we simply mention in 7.10.2: "the
>  solution SHOULD allow computing and setting up a backup tunnel
>  following an optimal path that offers bandwidth guarantees during
>   failure along with other potential constraints (like bounded
>  propagation delay increase along the backup path)"
>
> This definitely does not point out that such backup computation
> must be done by the last LSR before the ABR.

OK.
My point was that it is usually the PLR that is responsible for having computed and
established the bypass tunnel. This is fine when the PLR, MP and bypass tunnel lie in the
same area. But when the ABR fails, the PLR is the "last LSR before the ABR". This will
require that the PLR and MP are indifferent areas.
Thus there is a requirement that the PLR is able to compute inter-area paths.

I wanted to understand whether it is a requirement to use this form of FRR, or whether it
would be acceptable (for example) for the protection path to be computed by the ingress
and supplied to the PLR through signaling.

>>5.3.2. Preserve Scalability
>>   The solution MUST also not increase IGP load which could compromise
>>   IGP scalability.
>>Just to be clear, no increase in IGP load of any sort is
>>allowed under any circumstances?
>>Because you go on to say...
>>   In particular, a solution satisfying those
>>   requirements MUST not require for the IGP to carry some unreasonable
>>   amount of extra information and MUST not unreasonably increase the
>>   IGP flooding frequency.
>>Which implies that additional data and flooding is allowed.
>
>Yes, provided that there is no impact on IPG scalability

Well, I don't want to be picky, but...  :-)
*Any* increase even in the amount of static flooded data impacts on IGP scalablity.
So, if we are going to be governed by rules on IGP scalability, we must be consistent and
understand the rules.

> IMHO, the addition of inter-area TE funcion MUST not compromize the
> maximum operational size of an area.

So, that really means adding absolutely no information to any LSAs at all. Because an
increase in that information implies an increase in stored data which implies a reduction
in the maximum operational size of the area.

>>7.2. Inter-Area TE-LSP signalling
>>   If multiple signalling methods are proposed in the solution, the
>>   head-end LSR MUST have the ability to signal the required or desired
>>   method on a per-LSP basis.
>>To be clear...
>>The head-end is to be given the ability to cause an LSP setup
>>to fail if the signalling technique is not to its liking
>>regardless of the service provided. The head-end is to be
>>allowed to select only a single method, but to require or
>>desire that method. Am I missing something, or is this a
>>recipe for interoperability issues? For example, if the
>>head-end specifies that end-to-end signalling MUST be used but
>>only supplies a loose hop for the transit of Area 0, why would
>>it care how the signalling across Area 0 is achieved (such as
>>through an FA)?
>
>It would care about the signaling used at transit for several reasons:
>FRR performances, optimality,
>head-end control of reoptimization...
>IMHO this is important for an ISP to control, by configuration at
>Head-End, the signaling method.

Weeeeell,
The things you have listed are functional requirements not implementation requirements.
That is, the head-end is free to request/demand certain functions from the network, but I
still don't understand why it would want/need to control how those functions are provided.

>>9. Security Considerations
>>This section seems awfully light.
> And thus I'm not sure to understand what could be added in this section.

OK. Well, I leave it with you. You might want to consult an IETF "security expert" just so
that the draft doesn't get bounced by the IESG.

Delivery-date: Mon, 24 May 2004 18:17:11 +0000
Content-Class: urn:content-classes:message
Subject: Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
Date: Mon, 24 May 2004 20:15:27 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Adrian

Thanks for these useful comments.
Previous mail was a partial answer.
Please see inline for the complete answer.

>
>Hi,
>
>Thanks for this draft. Lots of good material and plenty to think about.
>
>I'm reviewing this with a CCAMP co-chair hat on. My
>perspective is very much that this draft will be handed over=20
>to CCAMP as input and constraints to the process of developing=20
>protocol extensions to deliver MPLS TE in an inter-area scenario.
>
>Thus most of my questions/issues are requests for
>clarification and are not debates on technical issues.
>
>Cheers,
>Adrian
>
>Abstract
>   This document lists a detailed set of functional
>requirements for the
>   support of inter-area MPLS Traffic Engineering (inter-area MPLS TE)
>   which could serve as a guideline to develop the required set of
>   protocol extensions.
>It is not clear to me whether these are requirements or=20
>whether this draft is a general set of guidelines. Of course,=20
>CCAMP will be bound by the former, and MAY ignore the latter.

They are requirements...
Agree that the abstract is confusing.
 We will rephrase as follows "This document lists a detailed set of
functional requirements for the support of inter-area MPLS Traffic
Engineering (inter-area MPLS TE). It is intended that solutions that
specify procedures for inter-area MPLS-TE  satisfy these
requirements..."

>
>Current limitations
>You make some fairly strong statements such as in 5.1...
>   However, MPLS-TE mechanisms are currently limited to a single IGP
>   area.
>I don't think this is clear at all. I don't see any
>limitations, for example, in MPLS-TE signalling in this=20
>respect. It would be helpful to break down "MPLS-TE" into its=20
>functional components and then it will be easy to show which=20
>components are limited to a single IGP and which not. This is=20
>more than the trivial point which it may appear since this=20
>analysis is what will drive the solution

Basically limitations rely essentially on the routing (IGP) and path
computation components.=20
You are right, we need to clarify this section.
Note that this is already partially mentionned in 5.1: "However, MPLS-TE
mechanisms are currently limited to a single IGP=20
   area. This is basically due to the fact that hierarchy limits=20
   topology visibility of head-end LSRs to their IGP area, and=20
   consequently head-end LSRs can no longer run a CSPF algorithm to=20
   compute the shortest constrained path to the tail-end"

>
>Inter-area fast recovery
>Is this draft requiring that there should be fast recovery
>techniques that span area boundaries, or is it requiring that=20
>Fast Reroute should be functional across area boundaries? (see=20
>also 7.10.2)=20

Fast Recovery across areas is a generic requirement.
A simple solution is to support FRR, and thus, support of FRR across
area boundaries is defined as a specific requirement.

>It seems that FRR places a requirement on the=20
>last LSR before the ABR to be able to compute an inter-area=20
>path (and possibly to know about diversity constraints - i.e.=20
>the path of some other LSP).

No, we simply mention in 7.10.2: "the=20
   solution SHOULD allow computing and setting up a backup tunnel=20
   following an optimal path that offers bandwidth guarantees during=20
   failure along with other potential constraints (like bounded=20
   propagation delay increase along the backup path)"

This definitely does not point out that such backup computation=20
must be done by the last LSR before the ABR.

>Perhaps you could relax the=20
>requirement to adhere to FRR so as to allow the head-end to=20
>supply the information for the bypass tunnel? In other words,=20
>perhaps you could state the functional requirement not the=20
>implementation?

>
>5.3.1. Preserve the IGP hierarchy concept
>The reason given in this section is chiefly scalability. How=20
>does this section differ from the next section? It seems to be=20
>a subset. But aren't hierarchies a solution to the scalability=20
>requirement, not a requirement of themselves?

Basically the IGP hierachy concept MUST be preserved (ie containement of
routing information).
Hierachy is useful for various reasons, including scalability, but not
only scalability.
This is not entirely correlated, there may be inter-area solutions that
preserve IGP hierachy but are not scalable.
Preserving hierachy is necessary but not sufficient to ensure
scalability.
Basically we want a solution allowing to compute inter-area TE-LSP paths
while preserving IGP hierachy and scalability.

Section 5.3.2 adress scalability of both IGP AND RSVP.

>
>5.3.2. Preserve Scalability
>   The solution MUST also not increase IGP load which could compromise
>   IGP scalability.
>Just to be clear, no increase in IGP load of any sort is=20
>allowed under any circumstances?=20
>Because you go on to say...
>   In particular, a solution satisfying those
>   requirements MUST not require for the IGP to carry some unreasonable
>   amount of extra information and MUST not unreasonably increase the
>   IGP flooding frequency.
>Which implies that additional data and flooding is allowed.

Yes, provided that there is no impact on IPG scalability

>The definition of "unreasonable" may require some work!

Right...

>I think you are going to have to bite the bullet on=20
>scalability since you have already stated that the reason that=20
>areas exist is chiefly because of scalability issues.=20
>If, for=20
>example, the maximum operational size of an area was reduced=20
>by the addition of inter-area TE function, would that be=20
>unacceptable?

IMHO, the addition of inter-area TE funcion MUST not compromize the
maximum operational size
of an area.

 >Note also that 8.1 (4) seems to adopt a far more=20
>relaxed attitude to this question.=20

>Ingress and egress in the=20
>same area. I think there is an important issue that we need to=20
>check everyone is comfortable with. In section 6...
>   In some cases, it might also be possible to have an=20
>inter-area TE LSP
>   from R0 to R5 transiting via the backbone area (or any other levels
>   with IS-IS). Basically, there may be cases where there is no longer
>   enough resources on any intra area path R0-to-R5, while there is a
>   feasible inter-area path through the backbone area.
>So we are going to specifically allow a routing scenario where=20
>we may leave and re-enter an area.=20

Right

>This, I believe, does not=20
>happen in open shortest path first.=20

Right, but here we want to do TE. One goal of MPLS-TE is to setup
constraint based paths regardless of the=20
IP path isn't it ?

>Just wanted to be clear=20
>that everyone agrees to this. (see also 7.8)
>
>7.1. Inter-area MPLS TE operations and interoperability
>Is it a requirement that we protect non-head-end, non-ABR LSRs=20
>from knowledge of inter-area function? This seems to be what=20
>8.3 says. This raises a big issue for FRR (or any other form=20
>of) protection of an ABR.

Of course the PLR must support inter-area functions
Will clarify

>
>7.2. Inter-Area TE-LSP signalling
>   If multiple signalling methods are proposed in the solution, the
>   head-end LSR MUST have the ability to signal the required or desired
>   method on a per-LSP basis.
>To be clear...
>The head-end is to be given the ability to cause an LSP setup=20
>to fail if the signalling technique is not to its liking=20
>regardless of the service provided. The head-end is to be=20
>allowed to select only a single method, but to require or=20
>desire that method. Am I missing something, or is this a=20
>recipe for interoperability issues? For example, if the=20
>head-end specifies that end-to-end signalling MUST be used but=20
>only supplies a loose hop for the transit of Area 0, why would=20
>it care how the signalling across Area 0 is achieved (such as=20
>through an FA)? =20

It would care about the signaling used at transit for several reasons:
FRR performances, optimality,
head-end control of reoptimization...
IMHO this is important for an ISP to control, by configuration at
Head-End, the signaling method.

>There may be *functional* reasons why one=20
>signalling method is preferred, but in that case, surely the=20
>head-end should specify the functions/service level that it wants.

>
>7.4. Inter-Area MPLS-TE Routing
>   As already mentioned in 5.3, IGP hierarchy does not allow the Head-
>   End LSR computing an end-to-end optimal path. Additional mechanisms
>   are required to compute an optimal path. These additional mechanisms
>   MUST not alter the IGP hierarchy principles.
>   One solution could consist of extending the IGP for the leaking of
>   summarized TE information across areas, but this would not scale: An
>   ABR would have to compute and advertise summarized TE data for each
>   potential destination and a large set of constraints combinations
>   which would ineluctability have undesirable consequences in term of
>   amount of flooded information and ABR CSPF computations.
>   Thus, in order to maintain containment of routing information and
>   preserve the overall IGP scalability, the solution MUST preclude the
>   leaking across area of any TE link information summarized=20
>or not. Whatever your views on the likelihood of a successful=20
>aggregation algorithm being developed, it seems to me that you=20
>are deliberately curtailing the solution space rather than=20
>stating the requirements. Could you limit yourself to scaling=20
>requirements rather than state how these requirements must be met?

I will answer this point in a separate email

>
>   Conversely, this does not preclude the leaking of non topology
>   related information, that are not taken into account during path
>   selection, such as static TE Node information like TE router ids or
>   TE node capabilities.
>Are TE node capabilities not topology related? They certainly=20
>affect how you choose a path. Perhaps you are trying to=20
>distinguish between dynamic and static information?

Yes we are disinghuishing between static and dynamic TE information.
Will clarify this section.

>
>7.5. Inter-Area MPLS-TE Path computation
>   In case a solution supports more than one method, it SHOULD=20
>allow the
>   operator to select by configuration, and on a per-LSP basis, the
>   desired option.
>Again, you want to be able to control the way in which a=20
>service is provided at a downstream ABR rather than specify=20
>the service. I am uneasy with this and see interop problems=20
>without a gain in function.

IMHO this is important for an ISP to exactly control, by configuration
at Head-End, the way the path is computed

>
>7.7. Support of diversely routed inter-area TE LSPs
>   Moreover, the solution SHOULD not require
>   extra-load in signalling and routing in order to reach that
>   objective.
>Why do you say this and not...
>   Moreover, the solution SHOULD not require extra
>   load in processing at the head-end LSR, nor extra load
>   in communication with an offline path computation
>   server.
>It seems to me that if (for example) it was necessary to=20
>signal fifty additional bytes in a signalling message in order=20
>to achieve diverse paths, this would be entirely acceptable.=20
>Actually, the whole of this section describes computation of=20
>diverse paths rather than establishment of diverse paths. The=20
>service that we want to achieve is clearly one where diverse=20
>paths are established: computation of such paths (rather than=20
>derivation) is surely just one way of facilitating the service.

You are right, we will update this section as you suggest

>
>7.9. Reoptimization of inter-area TE LSP
>Just for the record, make-before-break is only "nearly=20
>non-disruptive". "Minimally disruptive" might be a good=20
>phrase. This is true even in packet networks since the first=20
>packet on the new LSP may overtake the last on the old path.=20

Right, will clarify

>TE link across Area 0?
>
>7.14. Auto-discovery of TE meshes
>Perhaps you could add a reference for this section.
>I note that in this particular case, dynamic inter-area IGP=20
>information is allowed. Curious to know how you decide where=20
>to draw the line.

TE mesh is basically a static TE information, and we allow advertisement
of static TE info

>
>7.15. Inter-area MPLS TE fault management requirements
>Is there a requirement here for hierarchical LSP-PING since=20
>you allow hierarchies across Area 0?

Yes, will add this requirement

>
>7.16. Inter-area MPLS-TE and routing
>To be clear, you are precluding the use of IGP shortcuts where=20
>the head and tail of an LSP are in separate areas?

Bascially we are precluding the use of IGP shortcuts and also the
advertisement of a TE-LSP as a link into the IGP
Will clarify that in next revision

>
>8.1. Performances
>   Other criteria may be added in further revisions of this=20
>document. I guess now is your last chance :-)

Right, we will update this section in next revision

>
>8.2. Complexity and risks
>   The proposed solution(s) SHOULD not introduce unnecessary complexity
>   to the current operating network to such a degree that it would
>   affect the stability and diminish the benefits of deploying such
>   solution over SP networks.
>But we are allowed to introduce unnecessary complexity to a=20
>lesser degree? :-)

Definitely no... will rephrase

>
>9. Security Considerations
>This section seems awfully light. There is at least a new=20
>policy point (the ABR) that may be responsible for security.=20
>It is also possible to consider that the limited visibility=20
>from one area to another is a security feature (even if it was=20
>not designed as such) and so there is something to be said on=20
>that topic.
>

IGP hiearchy are not defined and not used today by ISPs to improve
security,
And thus I'm not sure to understand what could be added in this section.

>References
>I wonder if all of your normative references need to be=20
>normative. This is likely to hold up the publication as an RFC=20
>for a long time.

Right, will update.

>
>Copyright and IPR
>No IPR statement found
>Copyright needs to use the new boilerplate.

OK

>
>Typos.
>Could someone have a good go through the draft to clean up the=20
>typos and non-ASCII characters. This will make it easier to=20
>read an use.
>

OK

Again, thanks a lot Adrian for these highly relevant comments

Best Regards

JL

Delivery-date: Mon, 24 May 2004 17:02:40 +0000
Content-Class: urn:content-classes:message
Subject: RE : 
Date: Mon, 24 May 2004 18:59:51 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Adrian

Thanks for these useful comments.
Please see inline

>
>Hi,
>
>Thanks for this draft. Lots of good material and plenty to think about.
>
>I'm reviewing this with a CCAMP co-chair hat on. My=20
>perspective is very much that this draft will be handed over=20
>to CCAMP as input and constraints to the process of developing=20
>protocol extensions to deliver MPLS TE in an inter-area scenario.
>
>Thus most of my questions/issues are requests for=20
>clarification and are not debates on technical issues.
>
>Cheers,
>Adrian
>
>Abstract
>   This document lists a detailed set of functional=20
>requirements for the
>   support of inter-area MPLS Traffic Engineering (inter-area MPLS TE)
>   which could serve as a guideline to develop the required set of
>   protocol extensions.
>It is not clear to me whether these are requirements or=20
>whether this draft is a general set of guidelines. Of course,=20
>CCAMP will be bound by the former, and MAY ignore the latter.

These are requirements...Agree that the abstract is confusing
We will rephrase as follows
"This document lists a detailed set of functional requirements for the
support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).
It is intended that solutions that specify procedures for inter-area
MPLS-TE
 satisfy these requirements..."

>
>Current limitations
>You make some fairly strong statements such as in 5.1...
>   However, MPLS-TE mechanisms are currently limited to a single IGP
>   area.
>I don't think this is clear at all. I don't see any=20
>limitations, for example, in MPLS-TE signalling in this=20
>respect. It would be helpful to break down "MPLS-TE" into its=20
>functional components and then it will be easy to show which=20
>components are limited to a single IGP and which not. This is=20
>more than the trivial point which it may appear since this=20
>analysis is what will drive the solution

Basically limitations rely essentially on the routing (IGP) and path
computation
components. You are right, we need to clarify this section.
Note that this is already partially mentionned in 5.1:
"However, MPLS-TE mechanisms are currently limited to a single IGP=20
   area. This is basically due to the fact that hierarchy limits=20
   topology visibility of head-end LSRs to their IGP area, and=20
   consequently head-end LSRs can no longer run a CSPF algorithm to=20
   compute the shortest constrained path to the tail-end"

>
>Inter-area fast recovery
>Is this draft requiring that there should be fast recovery=20
>techniques that span area boundaries, or is it requiring that=20
>Fast Reroute should be functional across area boundaries? (see=20
>also 7.10.2)=20

It seems that FRR places a requirement on the=20
>last LSR before the ABR to be able to compute an inter-area=20
>path (and possibly to know about diversity constraints - i.e.=20
>the path of some other LSP). Perhaps you could relax the=20
>requirement to adhere to FRR so as to allow the head-end to=20
>supply the information for the bypass tunnel? In other words,=20
>perhaps you could state the functional requirement not the=20
>implementation?
>
>5.3.1. Preserve the IGP hierarchy concept
>The reason given in this section is chiefly scalability. How=20
>does this section differ from the next section? It seems to be=20
>a subset. But aren't hierarchies a solution to the scalability=20
>requirement, not a requirement of themselves?
>
>5.3.2. Preserve Scalability
>   The solution MUST also not increase IGP load which could compromise
>   IGP scalability.
>Just to be clear, no increase in IGP load of any sort is=20
>allowed under any circumstances? Because you go on to say...
>   In particular, a solution satisfying those
>   requirements MUST not require for the IGP to carry some unreasonable
>   amount of extra information and MUST not unreasonably increase the
>   IGP flooding frequency.
>Which implies that additional data and flooding is allowed.
>The definition of "unreasonable" may require some work!
>I think you are going to have to bite the bullet on=20
>scalability since you have already stated that the reason that=20
>areas exist is chiefly because of scalability issues. If, for=20
>example, the maximum operational size of an area was reduced=20
>by the addition of inter-area TE function, would that be=20
>unacceptable? Note also that 8.1 (4) seems to adopt a far more=20
>relaxed attitude to this question. Ingress and egress in the=20
>same area. I think there is an important issue that we need to=20
>check everyone is comfortable with. In section 6...
>   In some cases, it might also be possible to have an=20
>inter-area TE LSP
>   from R0 to R5 transiting via the backbone area (or any other levels
>   with IS-IS). Basically, there may be cases where there is no longer
>   enough resources on any intra area path R0-to-R5, while there is a
>   feasible inter-area path through the backbone area.
>So we are going to specifically allow a routing scenario where=20
>we may leave and re-enter an area. This, I believe, does not=20
>happen in open shortest path first. Just wanted to be clear=20
>that everyone agrees to this. (see also 7.8)
>
>7.1. Inter-area MPLS TE operations and interoperability
>Is it a requirement that we protect non-head-end, non-ABR LSRs=20
>from knowledge of inter-area function? This seems to be what=20
>8.3 says. This raises a big issue for FRR (or any other form=20
>of) protection of an ABR.
>
>7.2. Inter-Area TE-LSP signalling
>   If multiple signalling methods are proposed in the solution, the
>   head-end LSR MUST have the ability to signal the required or desired
>   method on a per-LSP basis.
>To be clear...
>The head-end is to be given the ability to cause an LSP setup=20
>to fail if the signalling technique is not to its liking=20
>regardless of the service provided. The head-end is to be=20
>allowed to select only a single method, but to require or=20
>desire that method. Am I missing something, or is this a=20
>recipe for interoperability issues? For example, if the=20
>head-end specifies that end-to-end signalling MUST be used but=20
>only supplies a loose hop for the transit of Area 0, why would=20
>it care how the signalling across Area 0 is achieved (such as=20
>through an FA)?  There may be *functional* reasons why one=20
>signalling method is preferred, but in that case, surely the=20
>head-end should specify the functions/service level that it wants.
>
>7.4. Inter-Area MPLS-TE Routing
>   As already mentioned in 5.3, IGP hierarchy does not allow the Head-
>   End LSR computing an end-to-end optimal path. Additional mechanisms
>   are required to compute an optimal path. These additional mechanisms
>   MUST not alter the IGP hierarchy principles.
>   One solution could consist of extending the IGP for the leaking of
>   summarized TE information across areas, but this would not scale: An
>   ABR would have to compute and advertise summarized TE data for each
>   potential destination and a large set of constraints combinations
>   which would ineluctability have undesirable consequences in term of
>   amount of flooded information and ABR CSPF computations.
>   Thus, in order to maintain containment of routing information and
>   preserve the overall IGP scalability, the solution MUST preclude the
>   leaking across area of any TE link information summarized=20
>or not. Whatever your views on the likelihood of a successful=20
>aggregation algorithm being developed, it seems to me that you=20
>are deliberately curtailing the solution space rather than=20
>stating the requirements. Could you limit yourself to scaling=20
>requirements rather than state how these requirements must be met?
>
>   Conversely, this does not preclude the leaking of non topology
>   related information, that are not taken into account during path
>   selection, such as static TE Node information like TE router ids or
>   TE node capabilities.
>Are TE node capabilities not topology related? They certainly=20
>affect how you choose a path. Perhaps you are trying to=20
>distinguish between dynamic and static information?
>
>7.5. Inter-Area MPLS-TE Path computation
>   In case a solution supports more than one method, it SHOULD=20
>allow the
>   operator to select by configuration, and on a per-LSP basis, the
>   desired option.
>Again, you want to be able to control the way in which a=20
>service is provided at a downstream ABR rather than specify=20
>the service. I am uneasy with this and see interop problems=20
>without a gain in function.
>
>7.7. Support of diversely routed inter-area TE LSPs
>   Moreover, the solution SHOULD not require
>   extra-load in signalling and routing in order to reach that
>   objective.
>Why do you say this and not...
>   Moreover, the solution SHOULD not require extra
>   load in processing at the head-end LSR, nor extra load
>   in communication with an offline path computation
>   server.
>It seems to me that if (for example) it was necessary to=20
>signal fifty additional bytes in a signalling message in order=20
>to achieve diverse paths, this would be entirely acceptable.=20
>Actually, the whole of this section describes computation of=20
>diverse paths rather than establishment of diverse paths. The=20
>service that we want to achieve is clearly one where diverse=20
>paths are established: computation of such paths (rather than=20
>derivation) is surely just one way of facilitating the service.
>
>7.9. Reoptimization of inter-area TE LSP
>Just for the record, make-before-break is only "nearly=20
>non-disruptive". "Minimally disruptive" might be a good=20
>phrase. This is true even in packet networks since the first=20
>packet on the new LSP may overtake the last on the old path.=20
>TE link across Area 0?
>
>7.14. Auto-discovery of TE meshes
>Perhaps you could add a reference for this section.
>I note that in this particular case, dynamic inter-area IGP=20
>information is allowed. Curious to know how you decide where=20
>to draw the line.
>
>7.15. Inter-area MPLS TE fault management requirements
>Is there a requirement here for hierarchical LSP-PING since=20
>you allow hierarchies across Area 0?
>
>7.16. Inter-area MPLS-TE and routing
>To be clear, you are precluding the use of IGP shortcuts where=20
>the head and tail of an LSP are in separate areas?
>
>8.1. Performances
>   Other criteria may be added in further revisions of this=20
>document. I guess now is your last chance :-)
>
>8.2. Complexity and risks
>   The proposed solution(s) SHOULD not introduce unnecessary complexity
>   to the current operating network to such a degree that it would
>   affect the stability and diminish the benefits of deploying such
>   solution over SP networks.
>But we are allowed to introduce unnecessary complexity to a=20
>lesser degree? :-)
>
>9. Security Considerations
>This section seems awfully light. There is at least a new=20
>policy point (the ABR) that may be responsible for security.=20
>It is also possible to consider that the limited visibility=20
>from one area to another is a security feature (even if it was=20
>not designed as such) and so there is something to be said on=20
>that topic.
>
>References
>I wonder if all of your normative references need to be=20
>normative. This is likely to hold up the publication as an RFC=20
>for a long time.
>
>Copyright and IPR
>No IPR statement found
>Copyright needs to use the new boilerplate.
>
>Typos.
>Could someone have a good go through the draft to clean up the=20
>typos and non-ASCII characters. This will make it easier to=20
>read an use.
>

Delivery-date: Mon, 24 May 2004 09:38:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ed Kern" <[email-masked]>, "Jim Boyle" <[email-masked]>
Subject: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 24 May 2004 10:32:37 +0100

Folks,
Just in case it got lost in bouncing emails...

The Traffic Engineering Working Group is holding a last call on this draft. Since this is
input to our multi-area/AS TE solutions work, it is important to give it a thorough
review.

Comments should be sent to the TEWG mailing list, but if you are not subscribed, please
send comments to the chairs,
Ed Kern ([email-masked]) and Jim Boyle ([email-masked]).

Thanks,
Adrian

----- Original Message ----- 
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, May 22, 2004 12:49 AM
Subject: BOUNCE [email-masked]: Non-member submission from [Ed Kern <[email-masked]>]
(fwd)

>
> Approved: kl00j
> >From [email-masked] Fri May 21 14:57:54 2004
> Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
> by psg.com with esmtp (Exim 4.30; FreeBSD)
> id 1BRBT8-000JR0-FX
> for [email-masked]; Fri, 21 May 2004 14:57:54 +0000
> Received: from sj-core-1.cisco.com (171.71.177.237)
>   by sj-iport-3.cisco.com with ESMTP; 21 May 2004 07:05:44 +0000
> Received: from [10.32.14.74] ([10.32.14.74])
> by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4LEvqDe013159
> for <[email-masked]>; Fri, 21 May 2004 07:57:52 -0700 (PDT)
> Mime-Version: 1.0 (Apple Message framework v613)
> Content-Transfer-Encoding: 7bit
> Message-Id: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> To: [email-masked]
> From: Ed Kern <[email-masked]>
> Subject: (TE-WG) Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
> Date: Fri, 21 May 2004 07:57:49 -0700
> X-Mailer: Apple Mail (2.613)
> X-PMX-Version: 4.6.0.99824
> X-from-outside-Cisco: [10.32.14.74]
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
> version=2.63
> X-Spam-Level:
>
> Heads up on TE-WG last call, comments to the [email-masked] list.
>
> thanks,
>
> Ed
>
>
> > From: Ed Kern <[email-masked]>
> > Date: May 21, 2004 7:55:38 AM PDT
> > To: [email-masked]
> > Cc: Jim Boyle <[email-masked]>
> > Subject: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
> >
> >
> > This email starts a WG last call on
> >
> > "Requirements for Inter-area MPLS Traffic Engineering"
> >
> > which can be found at:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-
> > req-01.txt
> >
> > This document is intended to become an Informational RFC, and will be
> > used
> > as the requirements document to which ccamp will develop a technical
> > solution.
> >
> > This WG last call will last 3 weeks, as some from CCAMP may want to
> > take
> > this opportunity to get involved in the review, if they haven't
> > already.
> >
> > The WG last call will run from 5/21 through 6/11.  All comments should
> > be
> > sent to [email-masked].
> >
> > Thanks,
> >
> > Ed
> >
>
>
>
>

Delivery-date: Mon, 24 May 2004 04:28:33 +0000
Date: Mon, 24 May 2004 09:46:12 +0530
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: RE: Incoming Msg

----------jjjygqahiidwwlkhupum
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:fsfowzibyn.gif"><br>
</body></html>

----------jjjygqahiidwwlkhupum
Content-Type: image/gif; name="fsfowzibyn.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fsfowzibyn.gif"
Content-ID: 

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

----------jjjygqahiidwwlkhupum--

Delivery-date: Sat, 22 May 2004 14:42:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: ID Tracker State Update Notice: draft-ietf-ccamp-lmp-mib
Date: Sat, 22 May 2004 14:15:43 +0100

FYI
----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, May 20, 2004 3:38 PM
Subject: ID Tracker State Update Notice: draft-ietf-ccamp-lmp-mib

> 'State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bert Wijnen'
> ID Tracker URL:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=7778&rfc_flag=0

Delivery-date: Fri, 21 May 2004 23:53:29 +0000
Date: Fri, 21 May 2004 16:49:53 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Ed Kern <[email-masked]>]    (fwd)

Approved: kl00j
>From [email-masked] Fri May 21 14:57:54 2004
To: [email-masked]
From: Ed Kern <[email-masked]>
Subject: (TE-WG) Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 21 May 2004 07:57:49 -0700

Heads up on TE-WG last call, comments to the [email-masked] list.

thanks,

Ed

> From: Ed Kern <[email-masked]>
> Date: May 21, 2004 7:55:38 AM PDT
> To: [email-masked]
> Cc: Jim Boyle <[email-masked]>
> Subject: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> This email starts a WG last call on
>
> "Requirements for Inter-area MPLS Traffic Engineering"
>
> which can be found at:
>
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-
> req-01.txt
>
> This document is intended to become an Informational RFC, and will be
> used
> as the requirements document to which ccamp will develop a technical
> solution.
>
> This WG last call will last 3 weeks, as some from CCAMP may want to
> take
> this opportunity to get involved in the review, if they haven't
> already.
>
> The WG last call will run from 5/21 through 6/11.  All comments should
> be
> sent to [email-masked].
>
> Thanks,
>
> Ed
>

Delivery-date: Fri, 21 May 2004 10:05:21 +0000
Date: Fri, 21 May 2004 11:08:50 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Re: Thanks :)

----------ntnkzqavqpsnrsfhwzxp
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------ntnkzqavqpsnrsfhwzxp
Content-Type: application/octet-stream; name="Info.hta"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Info.hta"

----------ntnkzqavqpsnrsfhwzxp--

Delivery-date: Thu, 20 May 2004 14:57:20 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "dimitri papadimitriou" <[email-masked]>, "Tomohiro Otani" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Thu, 20 May 2004 15:55:31 +0100

Hi Tomohiro,

Any suggestions?

Thanks.
Adrian

Delivery-date: Wed, 19 May 2004 19:14:09 +0000
From: "zafar ali" <[email-masked]>
To: "'John Drake'" <[email-masked]>, <[email-masked]>
Cc: "'Anca Zamfir'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
Date: Wed, 19 May 2004 15:11:59 -0400
Organization: Cisco Systems

Hi John,=20

Sorry for the delay in reply. In this ID we combined the following two
drafts:=20

1. Component Link Recording and Resource Control for GMPLS Link Bundles,
http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-contro=
l-b
undle-03.txt. We had discuss and agreement on the content on this draft
(especially need for RRO sub-object).=20

2. Identification of Component Links of Unnumbered Interfaces,
http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ifid-unnum-00.txt.=
=20

I think your question is for the portion of ID that came from (2), =
correct?=20

Assuming this, here is the rationale.=20

RFC3471 defines the following TLVs for IF_ID RSVP_HOP Object.=20

   Type Length Format     Description
   --------------------------------------------------------------------
    1      8   IPv4 Addr. IPv4
    2     20   IPv6 Addr. IPv6
    3     12   See below  IF_INDEX                (Interface Index)
    4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
    5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

We need following new TLVs to describe Numbered IF_IDs using IF_ID =
RSVP_HOP
Object.

IPv4 - DOWNSTREAM (Component IF)
IPv4 - UPSTREAM (Component IF)
IPv6 - DOWNSTREAM (Component IF)
IPv6 - UPSTREAM (Component IF)

As the definition in RFC3471 are not sufficient to identify the above
mentioned cases. Agreed? This is where the discussion started.=20

It was pointed out that some implementations have IF index assignment =
such
that IF indexes are only unique within the TE link they belong to. I.e.,
assumption that IF_indexes are NOT box wide unique is not valid across
implementations. In order to accommodate such implementation, we came up
with what is in the ID at the present moment.=20

Given this, can you please provide more feedback on how you can improve =
the
ID?=20

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of John Drake
>Sent: Monday, May 17, 2004 12:05 PM
>To: [email-masked]
>Subject: FW: I-D=20
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
>
>
>Zafar,
>
>I'm sorry but I'm a little confused.
>
>What problem is it that you are addressing with this draft=20
>that isn't already addressed by RFC 3471/3473/3477 and the=20
>bundling draft?
>
>Thanks,
>
>John
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>Sent: Friday, May 14, 2004 12:40 PM
>To: [email-masked]
>Subject: I-D=20
>ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
>
>A New Internet-Draft is available from the on-line=20
>Internet-Drafts directories.
>
>
>	Title		: Generalized Multi-Protocol Label=20
>Switching (GMPLS)
>RSVP-TE=20
>			  signaling using Bundled Traffic=20
>Engineering (TE)
>Links
>	Author(s)	: Z. Ali, et al.
>	Filename	:
>draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
>	Pages		: 14
>	Date		: 2004-5-14
>=09
>This document is a companion to the Generalized Multi-Protocol Label
>   Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions
>   of [RFC3471] to provide the means to identify component links of
>   unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID
>   ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE
>   in support of component link identifiers for explicit resource
>   control and recording over link bundles.
>
>A URL for this Internet-Draft is:=20
>http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-r
svp-te-bundle
d-links-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of =
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 =
username
"anonymous" and a password of your e-mail address. After logging in, =
type
"cd internet-drafts" and then
	"get draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.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

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt".=

=09
	=09
	=09

Delivery-date: Tue, 18 May 2004 00:49:12 +0000
Date: Tue, 18 May 2004 09:47:41 +0900
To: dimitri papadimitriou <[email-masked]>, Adrian Farrel <[email-masked]>
From: Tomohiro Otani <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Cc: [email-masked]

Hi Everyone,

Regards,

tomo

directories.
of the message.
 > >>implementation to automatically retrieve the ASCII version of the

Delivery-date: Mon, 17 May 2004 18:22:05 +0000
Date: Mon, 17 May 2004 14:20:08 -0400
To: ricciato <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: RE:Comments on ARO: ARO and PCE order of computation.
Cc: Adrian Farrel <[email-masked]>, ccamp <[email-masked]>, ugo <[email-masked]>, Marco Listanti <[email-masked]>, Daniele  =?iso-8859-1?Q?Al=EC?= <[email-masked]>, "alessio d'achille" <[email-masked]>

Hi,

At 10:22 AM 5/17/2004 +0200, ricciato wrote:
>Dear JP, Adrian, CCAMPers,
>
>I have been thinking to the PCE proposal.
>
>Aside from the details of the signaling procedure, it seems to me that
>a very basic difference between the PCE
>proposal and the ARO proposal is in the order of computation.
>
>In the ARO proposal, the path sections in AS(k) are computed *before* the
>path sections in AS(k+1). Instead, in the PCE approach the path
>sections in AS(k) are computed *after* the path sections in AS(k+1) (at
>least, this is what I understood from sec. 6.6 of your draft).
>
>I've called this approach "egress-influenced path comp. " in my reply
>to Adrian, see http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html.
>(I relate this to the comment previously issued by Adrian, about the
>possibility to let the downstream ASBR to take part to the path computation
>process.)
>
>In other words, we can say that the path computation with ARO proceeds
>forward, while with PCE it proceeds backward.
>
>Do you confirm this?

Not at all ... the example provided in the draft shows a backward procedure 
but one could also use a forward path computation procedure. Moreover, 
there are many implementations details that are not discussed in the draft.
The fundamental difference is that with the PCE-based approach one can 
built a shortest end to end path (along with other path attributes such as 
path diversity)

JP.

>If the comment above is correct, could you (or Adrian) clarify the
>technical reasons why a "backward computation" approach is superior or
>more desirable than a forward approach?
>
>
>Regards
>Fabio
>
>

Delivery-date: Mon, 17 May 2004 16:05:50 +0000
From: John Drake <[email-masked]>
To: [email-masked]
Subject: FW: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00 .txt
Date: Mon, 17 May 2004 09:04:43 -0700

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.

------_=_NextPart_000_01C43C28.AA96E270
Content-Type: text/plain

Zafar,

I'm sorry but I'm a little confused.

What problem is it that you are addressing with this draft that isn't
already addressed by RFC 3471/3473/3477 and the bundling draft?

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 14, 2004 12:40 PM
To: [email-masked]
Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt

	Title		: Generalized Multi-Protocol Label Switching (GMPLS)
RSVP-TE 
			  signaling using Bundled Traffic Engineering (TE)
Links
	Author(s)	: Z. Ali, et al.
	Filename	:
draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
	Pages		: 14
	Date		: 2004-5-14
	
This document is a companion to the Generalized Multi-Protocol Label
   Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions
   of [RFC3471] to provide the means to identify component links of
   unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID
   ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE
   in support of component link identifiers for explicit resource
   control and recording over link bundles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundle
d-links-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt".

------_=_NextPart_000_01C43C28.AA96E270
Content-Type: message/rfc822

To: 
Subject: 
Date: Fri, 14 May 2004 13:20:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C43C28.AA96E270"

------_=_NextPart_002_01C43C28.AA96E270
Content-Type: text/plain

------_=_NextPart_002_01C43C28.AA96E270
Content-Type: application/octet-stream;
	name="ATT92113.txt"
Content-Disposition: attachment;
	filename="ATT92113.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt

------_=_NextPart_002_01C43C28.AA96E270
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C43C28.AA96E270--

------_=_NextPart_000_01C43C28.AA96E270--

Delivery-date: Mon, 17 May 2004 14:58:49 +0000
Date: Mon, 17 May 2004 10:55:28 -0400
To: "Tom Petch" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Tom,

At 01:49 PM 5/16/2004 +0100, Tom Petch wrote:
>in line
>
>Tom
>-----Original Message-----
>From: Adrian Farrel <[email-masked]>
>To: Tom Petch <[email-masked]>; [email-masked]
><[email-masked]>
>Date: 13 May 2004 20:12
>Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
> >A reasonable request, Tom.
> >And heaven knows I have enough other stuff to do.
> >
> >For the record, I took this on in order to drive the work through in a
>shape that was
> >agreed by the WG. I'm more than happy to drop to the role of contributing
>author.
> >
> >Tom, are you busy? What do you know about multi-area/AS? Could you be the
>editor?
> >
>
>I am flattered by the offer but no, that was not what I had in mind:-)
>
>The draft looks fine and perhaps will need little further work.  And I have
>no
>problems with your work as chair or as editor.
>
>But in this case, multiple editors are listed in the I-D - et and al - and
>if they
>are still actively involved,

This is the case ;-)

Thanks

JP.

>I thought we
>could produce better output, even quicker output, by having two brains
>working on it rather than one ie editor editing, chairman chairing.
>
>But I have seen the other posts supporting your dual role so, so be it.
>
>tom
>
> >Adrian
> >
> >From: "Tom Petch" <[email-masked]>
> >To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> >Sent: Monday, May 10, 2004 8:52 PM
> >Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
> >
> >> I always have a reservation when the WG chair and the I-D editor are or
> >> turn out to be the same individual.  I think that the IETF discourages
>this
> >> for good reason and so for this to be adopted, I would like someone
>other
> >> than the WG chair to take the role of (lead) editor.
> >>
> >> Tom Petch
> >>
> >> -----Original Message-----
> >> From: Adrian Farrel <[email-masked]>
> >> To: [email-masked] <[email-masked]>
> >> Date: 06 May 2004 22:08
> >> Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
> >>
> >>
> >> >Folks,
> >> >
> >> >This draft represents the first step in the much-discussed six point pl
>an
> >> towards
> >> >inter-area/AS solutions.
> >> >

Delivery-date: Mon, 17 May 2004 08:24:26 +0000
Date: Mon, 17 May 2004 10:22:49 +0200
From: ricciato <[email-masked]>
To: Jean Philippe Vasseur <[email-masked]>,  Adrian Farrel <[email-masked]>, ccamp <[email-masked]>
CC: ugo <[email-masked]>,  Marco Listanti <[email-masked]>, =?ISO-8859-1?Q?Daniele_Al=EC?= <[email-masked]>,  alessio d'achille <[email-masked]>
Subject: RE:Comments on ARO: ARO and PCE order of computation.

Dear JP, Adrian, CCAMPers,

I have been thinking to the PCE proposal.

Aside from the details of the signaling procedure, it seems to me that
a very basic difference between the PCE
proposal and the ARO proposal is in the order of computation.

In the ARO proposal, the path sections in AS(k) are computed *before* the
path sections in AS(k+1). Instead, in the PCE approach the path
sections in AS(k) are computed *after* the path sections in AS(k+1) (at
least, this is what I understood from sec. 6.6 of your draft).

I've called this approach "egress-influenced path comp. " in my reply
to Adrian, see http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html.
(I relate this to the comment previously issued by Adrian, about the
possibility to let the downstream ASBR to take part to the path computation
process.)

In other words, we can say that the path computation with ARO proceeds
forward, while with PCE it proceeds backward.

Do you confirm this?

If the comment above is correct, could you (or Adrian) clarify the
technical reasons why a "backward computation" approach is superior or
more desirable than a forward approach?

Regards
Fabio

Delivery-date: Sun, 16 May 2004 12:55:49 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Sun, 16 May 2004 13:49:35 +0100

in line

Tom
-----Original Message-----
From: Adrian Farrel <[email-masked]>
To: Tom Petch <[email-masked]>; [email-masked]
<[email-masked]>
Date: 13 May 2004 20:12
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

>A reasonable request, Tom.
>And heaven knows I have enough other stuff to do.
>
>For the record, I took this on in order to drive the work through in a
shape that was
>agreed by the WG. I'm more than happy to drop to the role of contributing
author.
>
>Tom, are you busy? What do you know about multi-area/AS? Could you be the
editor?

I am flattered by the offer but no, that was not what I had in mind:-)

The draft looks fine and perhaps will need little further work.  And I have
no
problems with your work as chair or as editor.

But in this case, multiple editors are listed in the I-D - et and al - and
if they
are still actively involved, I thought we
could produce better output, even quicker output, by having two brains
working on it rather than one ie editor editing, chairman chairing.

But I have seen the other posts supporting your dual role so, so be it.

tom

>From: "Tom Petch" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
>Sent: Monday, May 10, 2004 8:52 PM
>Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>> I always have a reservation when the WG chair and the I-D editor are or
>> turn out to be the same individual.  I think that the IETF discourages
this
>> for good reason and so for this to be adopted, I would like someone
other
>> than the WG chair to take the role of (lead) editor.
>>
>> Tom Petch
>>
>> -----Original Message-----
>> From: Adrian Farrel <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> Date: 06 May 2004 22:08
>> Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>>
>>
>> >Folks,
>> >
>> >This draft represents the first step in the much-discussed six point pl
an
>> towards
>> >inter-area/AS solutions.
http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framewo
>> rk-00.txt

Delivery-date: Fri, 14 May 2004 14:43:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Martin Dubuc" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Questions about draft-ietf-ccamp-lmp-mib-08.txt
Date: Fri, 14 May 2004 15:23:45 +0100

OK.

Unless anyone on the list objects, can you store up five edits and make the changes during
updates after AD review or after IETF last call.

Thanks.
Adrian

1.      lmpTeLinkVerification
         Delete "extended"
2.      lmpTeLinkFaultManagement
         Delete "extended"
3.      lmpTeLinkDwdm

         Delete "extended"
4.      lmpTeLinkDwdm
         Correct reference to point to LMP-WDM
5.      Normative references
         Add LMP-WDM

----- Original Message ----- 
From: "Martin Dubuc" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Thomas D. Nadeau" <[email-masked]>
Sent: Thursday, May 13, 2004 1:31 AM
Subject: Re: Questions about draft-ietf-ccamp-lmp-mib-08.txt

You are correct.

Martin
  ----- Original Message ----- 
  From: Adrian Farrel
  To: [email-masked]
  Cc: [email-masked] ; [email-masked] ; Thomas D. Nadeau
  Sent: Wednesday, May 12, 2004 7:10 PM
  Subject: Questions about draft-ietf-ccamp-lmp-mib-08.txt

  Hi,

  In the lmpTeLinkTable we have

     lmpTeLinkVerification OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP link verification
             procedure is enabled for this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
           -- RFC Editor to fill in RFC number that will be assigned to
           -- [LMP]
        ::= { lmpTeLinkEntry 2 }

     lmpTeLinkFaultManagement OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP fault management
             procedure is enabled on this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
            -- RFC Editor to fill in RFC number that will be assigned to
            -- [LMP]
        ::= { lmpTeLinkEntry 3 }

     lmpTeLinkDwdm OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP DWDM procedure
             is enabled on this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
            -- RFC Editor to fill in RFC number that will be assigned to
            -- [LMP]
        ::= { lmpTeLinkEntry 4 }

  So, I searched in draft-ietf-ccamp-lmp-10.txt but couldn't find suitable references.

  I assume that:
  - "extended LMP link verification procedure" means
    "LMP link verification procedure" and that you have
     used the word "extended" because it is an optional
    procedure.
  - Ditto for "extended LMP fault management procedure"
  - the "extended LMP DWMD procedure" is intended to
    refer to the LMP-WDM extensions defined in
    draft-ietf-ccamp-lmp-wdm-02.txt (in which case the
    reference is wrong).

  Could you confirm or deny.

  Thanks,
  Adrian

Delivery-date: Fri, 14 May 2004 12:52:25 +0000
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Fri, 14 May 2004 07:50:44 -0500
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>, "Tom Petch" <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>, <[email-masked]>, <[email-masked]>

> Quite frankly, Adrian has been helping out in this draft=20
> (and others) and his contribution has been a key element
> of success in trying to achieve/reflect the consensus of
> many individuals.

I agree with JP and would like to see Adrian continue as editor.  =
Furthermore, IMO Adrian is doing a great job as co-chair of CCAMP, =
author/editor of many other documents, and expert =
consultant/collaborator.  It would be a shame to slow by even a little =
bit that excellent momentum.

Jerry

Delivery-date: Fri, 14 May 2004 00:44:34 +0000
From: "zafar ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "'Tom Petch'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Thu, 13 May 2004 20:43:48 -0400
Organization: Cisco Systems

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Thursday, May 13, 2004 3:02 PM
>To: Tom Petch; [email-masked]
>Subject: Re: I-D=20
>ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
>A reasonable request, Tom.
>And heaven knows I have enough other stuff to do.
>
>For the record, I took this on in order to drive the work=20
>through in a shape that was agreed by the WG. I'm more than=20
>happy to drop to the role of contributing author.
>

PLEASE DON'T and we will not let you ;-). I think most of the community
respect you as the WG Chair and as well as a contributor. In this =
particular
case you did a very good job in shaping up a "difficult" ID.=20

Tom,=20

This is NOT the first time when a WG chair is one of the main =
contributors
and editor of an ID and AFAIK IETF procedures do NOT prevent a WG chair =
to
contribute in that role. Can you cite a place where such a "reservation" =
is
documented?=20

>Tom, are you busy? What do you know about multi-area/AS? Could=20
>you be the editor?
>
>Thanks,
>Adrian
>
>----- Original Message -----=20
>From: "Tom Petch" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
>Sent: Monday, May 10, 2004 8:52 PM
>Subject: Re: I-D=20
>ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
>> I always have a reservation when the WG chair and the I-D editor are=20
>> or turn out to be the same individual.  I think that the IETF=20
>> discourages this for good reason and so for this to be adopted, I=20
>> would like someone other than the WG chair to take the role=20
>of (lead)=20
>> editor.
>>
>> Tom Petch
>>
>> -----Original Message-----
>> From: Adrian Farrel <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> Date: 06 May 2004 22:08
>> Subject: Re: I-D=20
>> ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>>
>>
>> >Folks,
>> >
>> >This draft represents the first step in the much-discussed=20
>six point=20
>> >plan
>> towards
>> >inter-area/AS solutions.
>> >
>> >b. The draft to be reinforced in areas that people consider=20
>necessary
>> >    - try to keep the length of the draft down below 100 pages c.=20
>> >Move on with the next step in the plan.
>> >> This document provides a framework for establishing and=20
>controlling
>> >>    Multiprotocol Label Switching (MPLS) and Generalized=20
>MPLS (GMPLS)
>> >>    For the purposes of this document, a domain is=20
>considered to be any
>> >>    collection of network elements within a common sphere=20
>of address
>> >>    management or path computational responsibility.=20
>Examples of such
>>=20
>http://www.ietf.org/internet-drafts/draft->farrel-ccamp-inter-domain-fr
>> amewo
>> rk-00.txt
>> >>
>>
>>
>>
>>
>>
>
>

Delivery-date: Thu, 13 May 2004 23:49:05 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>, Tom Petch <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt 
Date: Thu, 13 May 2004 16:48:37 -0700

I also have no problem with Adrian editing the document,
especially since it is a framework document and does not
advocate any specific technique.  I understand the 
reservation, but it should be balanced against the
need to make progress in the group.

Cheers,

Lyndon

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Thursday, May 13, 2004 4:25 PM
To: Tom Petch
Cc: Adrian Farrel; [email-masked]
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

Tom,

> I always have a reservation when the WG chair and the I-D editor are or
> turn out to be the same individual.  I think that the IETF discourages this
> for good reason and so for this to be adopted, I would like someone other
> than the WG chair to take the role of (lead) editor.

There are plenty of precedence where a WG chair/co-chair is also
an editor of some of the WG documents, and so far we've yet to
see any significant problem(s) with this. So, I don't think Adrian
being an editor is a problem. Especially, since he is not the
only chair of the WG.

Yakov.

> 
> Tom Petch
> 
> -----Original Message-----
> From: Adrian Farrel <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: 06 May 2004 22:08
> Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
> 
> 
> >Folks,
> >
> >This draft represents the first step in the much-discussed six point plan
> towards
> >inter-area/AS solutions.
> >

Delivery-date: Thu, 13 May 2004 23:25:36 +0000
To: "Tom Petch" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt 
Date: Thu, 13 May 2004 16:24:30 -0700
From: Yakov Rekhter <[email-masked]>

Tom,

> I always have a reservation when the WG chair and the I-D editor are or
> turn out to be the same individual.  I think that the IETF discourages this
> for good reason and so for this to be adopted, I would like someone other
> than the WG chair to take the role of (lead) editor.

There are plenty of precedence where a WG chair/co-chair is also
an editor of some of the WG documents, and so far we've yet to
see any significant problem(s) with this. So, I don't think Adrian
being an editor is a problem. Especially, since he is not the
only chair of the WG.

Yakov.

> 
> Tom Petch
> 
> -----Original Message-----
> From: Adrian Farrel <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: 06 May 2004 22:08
> Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
> 
> 
> >Folks,
> >
> >This draft represents the first step in the much-discussed six point plan
> towards
> >inter-area/AS solutions.
> >

Delivery-date: Thu, 13 May 2004 21:03:02 +0000
Date: Thu, 13 May 2004 17:02:01 -0400
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Cc: <[email-masked]>, [email-masked]

Hi Tom,

Quite frankly, Adrian has been helping out in this draft (and others) and 
his contribution has been a key element of success in trying to 
achieve/reflect the consensus of many individuals.

Thanks.

JP.

At 08:01 PM 5/13/2004 +0100, Adrian Farrel wrote:
>A reasonable request, Tom.
>And heaven knows I have enough other stuff to do.
>
>For the record, I took this on in order to drive the work through in a 
>shape that was
>agreed by the WG. I'm more than happy to drop to the role of contributing 
>author.
>
>Tom, are you busy? What do you know about multi-area/AS? Could you be the 
>editor?
>
>Thanks,
>Adrian
>
>From: "Tom Petch" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
>Sent: Monday, May 10, 2004 8:52 PM
>Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
> > I always have a reservation when the WG chair and the I-D editor are or
> > turn out to be the same individual.  I think that the IETF discourages this
> > for good reason and so for this to be adopted, I would like someone other
> > than the WG chair to take the role of (lead) editor.
> >
> > Tom Petch
> >
> > -----Original Message-----
> > From: Adrian Farrel <[email-masked]>
> > To: [email-masked] <[email-masked]>
> > Date: 06 May 2004 22:08
> > Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
> >
> >
> > >Folks,
> > >
> > >This draft represents the first step in the much-discussed six point plan
> > towards
> > >inter-area/AS solutions.
> > >

Delivery-date: Thu, 13 May 2004 19:04:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Tom Petch" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Thu, 13 May 2004 20:01:53 +0100

A reasonable request, Tom.
And heaven knows I have enough other stuff to do.

For the record, I took this on in order to drive the work through in a shape that was
agreed by the WG. I'm more than happy to drop to the role of contributing author.

Tom, are you busy? What do you know about multi-area/AS? Could you be the editor?

Thanks,
Adrian

----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Monday, May 10, 2004 8:52 PM
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

> I always have a reservation when the WG chair and the I-D editor are or
> turn out to be the same individual.  I think that the IETF discourages this
> for good reason and so for this to be adopted, I would like someone other
> than the WG chair to take the role of (lead) editor.
>
> Tom Petch
>
> -----Original Message-----
> From: Adrian Farrel <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: 06 May 2004 22:08
> Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
> >Folks,
> >
> >This draft represents the first step in the much-discussed six point plan
> towards
> >inter-area/AS solutions.
> >

Delivery-date: Thu, 13 May 2004 17:44:44 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Mon, 10 May 2004 20:52:15 +0100

I always have a reservation when the WG chair and the I-D editor are or
turn out to be the same individual.  I think that the IETF discourages this
for good reason and so for this to be adopted, I would like someone other
than the WG chair to take the role of (lead) editor.

Tom Petch

-----Original Message-----
From: Adrian Farrel <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 06 May 2004 22:08
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

>Folks,
>
>This draft represents the first step in the much-discussed six point plan
towards
>inter-area/AS solutions.
directories.
>> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framewo
rk-00.txt

Delivery-date: Thu, 13 May 2004 16:54:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt
Date: Thu, 13 May 2004 12:53:21 -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		: RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
	Author(s)	: J. Lang, et al.
	Filename	: draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt
	Pages		: 36
	Date		: 2004-5-12
	
This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support end-to-end LSP recovery (protection and restoration). A
   generic functional description of GMPLS recovery can be found in a
   companion document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt".

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 13 May 2004 13:23:08 +0000
Date: Thu, 13 May 2004 14:26:24 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Protected message

----------khbesjifzdmdwgcpbfgw
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------khbesjifzdmdwgcpbfgw
Content-Type: application/octet-stream; name="the_message.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="the_message.cpl"

----------khbesjifzdmdwgcpbfgw--

Delivery-date: Thu, 13 May 2004 07:22:31 +0000
Date: Thu, 13 May 2004 09:22:17 +0100
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: New changes

----------wmgomqrfqcctgvhwiuhq
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------wmgomqrfqcctgvhwiuhq
Content-Type: application/octet-stream; name="Manufacture.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Manufacture.com"

////////////////////////////////////////////////////////////////////////

----------wmgomqrfqcctgvhwiuhq--

Delivery-date: Thu, 13 May 2004 00:30:27 +0000
From: "Martin Dubuc" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Questions about draft-ietf-ccamp-lmp-mib-08.txt
Date: Wed, 12 May 2004 20:31:09 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C43860.0F5D38C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You are correct.

Martin
  ----- Original Message -----=20
  From: Adrian Farrel=20
  To: [email-masked]=20
  Cc: [email-masked] ; [email-masked] ; Thomas D. Nadeau=20
  Sent: Wednesday, May 12, 2004 7:10 PM
  Subject: Questions about draft-ietf-ccamp-lmp-mib-08.txt

  Hi,

  In the lmpTeLinkTable we have

     lmpTeLinkVerification OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP link verification
             procedure is enabled for this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
           -- RFC Editor to fill in RFC number that will be assigned to
           -- [LMP]
        ::=3D { lmpTeLinkEntry 2 }

     lmpTeLinkFaultManagement OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP fault management
             procedure is enabled on this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
            -- RFC Editor to fill in RFC number that will be assigned to
            -- [LMP]
        ::=3D { lmpTeLinkEntry 3 }

     lmpTeLinkDwdm OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This object indicates if the extended LMP DWDM procedure
             is enabled on this TE link."
        REFERENCE
            "Link Management Protocol, RFC xxx"
            -- RFC Editor to fill in RFC number that will be assigned to
            -- [LMP]
        ::=3D { lmpTeLinkEntry 4 }

  So, I searched in draft-ietf-ccamp-lmp-10.txt but couldn't find =
suitable references.

  I assume that:
  - "extended LMP link verification procedure" means
    "LMP link verification procedure" and that you have
     used the word "extended" because it is an optional
    procedure.
  - Ditto for "extended LMP fault management procedure"
  - the "extended LMP DWMD procedure" is intended to=20
    refer to the LMP-WDM extensions defined in=20
    draft-ietf-ccamp-lmp-wdm-02.txt (in which case the
    reference is wrong).

  Could you confirm or deny.

  Thanks,
  Adrian

------=_NextPart_000_0008_01C43860.0F5D38C0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4937.800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT size=3D2>You are correct.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Martin</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] =
href=3D"mailto:[email-masked]">Adrian=20
  Farrel</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  =
href=3D"mailto:[email-masked]">[email-masked]</=
A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Thomas D. =
Nadeau</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, May 12, 2004 =
7:10=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Questions about=20
  draft-ietf-ccamp-lmp-mib-08.txt</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>In the lmpTeLinkTable we =
have</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; lmpTeLinkVerification=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  TruthValue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  &nbsp;&nbsp; DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  "This object indicates if the extended LMP link=20
  verification<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;=20
  procedure is enabled for this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
  REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link=20
  Management Protocol, RFC =
xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;-- RFC Editor to fill in RFC number that will be assigned=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --=20
  [LMP]<BR>&nbsp;&nbsp; &nbsp;&nbsp; ::=3D { lmpTeLinkEntry 2 =
}</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; =
lmpTeLinkFaultManagement=20
  OBJECT-TYPE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TruthValue<BR>&nbsp;&nbsp;=20
  &nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  &nbsp;&nbsp; DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
  "This object indicates if the extended LMP fault=20
  management<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;=20
  procedure is enabled on this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
  REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link=20
  Management Protocol, RFC=20
  xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;-- RFC =
Editor=20
  to fill in RFC number that will be assigned=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --=20
  [LMP]<BR>&nbsp;&nbsp; &nbsp;&nbsp; ::=3D { lmpTeLinkEntry 3 =
}</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; lmpTeLinkDwdm=20
  OBJECT-TYPE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TruthValue<BR>&nbsp;&nbsp;=20
  &nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;"This=20
  object indicates if the extended LMP DWDM=20
  =
procedure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 is=20
  enabled on this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
  REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link=20
  Management Protocol, RFC=20
  xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;-- RFC =
Editor=20
  to fill in RFC number that will be assigned to<BR>&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --=20
  [LMP]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D { lmpTeLinkEntry 4 =
}</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>So, I searched in =
draft-ietf-ccamp-lmp-10.txt=20
  but couldn't find suitable references.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I assume that:</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- "extended LMP link=20
  verification&nbsp;procedure" means</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;"LMP link verification =
procedure"=20
  and that you have</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; used the word =
"extended" because=20
  it is an optional</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; procedure.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- Ditto for "extended LMP fault =
management=20
  procedure"</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- the "extended LMP DWMD procedure" =
is intended=20
  to </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;refer to the LMP-WDM =
extensions=20
  defined in </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; =
draft-ietf-ccamp-lmp-wdm-02.txt (in=20
  which case the</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; reference is =
wrong).</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Could you confirm or =
deny.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0008_01C43860.0F5D38C0--

Delivery-date: Wed, 12 May 2004 23:53:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Subject: Questions about draft-ietf-ccamp-lmp-mib-08.txt
Date: Thu, 13 May 2004 00:10:57 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0609_01C4387E.C3FE6380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

In the lmpTeLinkTable we have

   lmpTeLinkVerification OBJECT-TYPE
      SYNTAX        TruthValue
      MAX-ACCESS    read-create
      STATUS        current
      DESCRIPTION
          "This object indicates if the extended LMP link verification
           procedure is enabled for this TE link."
      REFERENCE
          "Link Management Protocol, RFC xxx"
         -- RFC Editor to fill in RFC number that will be assigned to
         -- [LMP]
      ::=3D { lmpTeLinkEntry 2 }

   lmpTeLinkFaultManagement OBJECT-TYPE
      SYNTAX        TruthValue
      MAX-ACCESS    read-create
      STATUS        current
      DESCRIPTION
          "This object indicates if the extended LMP fault management
           procedure is enabled on this TE link."
      REFERENCE
          "Link Management Protocol, RFC xxx"
          -- RFC Editor to fill in RFC number that will be assigned to
          -- [LMP]
      ::=3D { lmpTeLinkEntry 3 }

   lmpTeLinkDwdm OBJECT-TYPE
      SYNTAX        TruthValue
      MAX-ACCESS    read-create
      STATUS        current
      DESCRIPTION
          "This object indicates if the extended LMP DWDM procedure
           is enabled on this TE link."
      REFERENCE
          "Link Management Protocol, RFC xxx"
          -- RFC Editor to fill in RFC number that will be assigned to
          -- [LMP]
      ::=3D { lmpTeLinkEntry 4 }

So, I searched in draft-ietf-ccamp-lmp-10.txt but couldn't find suitable =
references.

I assume that:
- "extended LMP link verification procedure" means
  "LMP link verification procedure" and that you have
   used the word "extended" because it is an optional
  procedure.
- Ditto for "extended LMP fault management procedure"
- the "extended LMP DWMD procedure" is intended to=20
  refer to the LMP-WDM extensions defined in=20
  draft-ietf-ccamp-lmp-wdm-02.txt (in which case the
  reference is wrong).

Could you confirm or deny.

Thanks,
Adrian

------=_NextPart_000_0609_01C4387E.C3FE6380
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In the lmpTeLinkTable we =
have</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; lmpTeLinkVerification=20
OBJECT-TYPE<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
TruthValue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current<BR>&nbsp;&nbsp; =

&nbsp;&nbsp; DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
"This object indicates if the extended LMP link=20
verification<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;=20
procedure is enabled for this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link =
Management=20
Protocol, RFC xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;-- RFC=20
Editor to fill in RFC number that will be assigned=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- =
[LMP]<BR>&nbsp;&nbsp;=20
&nbsp;&nbsp; ::=3D { lmpTeLinkEntry 2 }</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; lmpTeLinkFaultManagement =

OBJECT-TYPE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TruthValue<BR>&nbsp;&nbsp;=20
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current<BR>&nbsp;&nbsp; =

&nbsp;&nbsp; DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
"This object indicates if the extended LMP fault=20
management<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; =
procedure=20
is enabled on this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link =
Management=20
Protocol, RFC xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;--=20
RFC Editor to fill in RFC number that will be assigned=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --=20
[LMP]<BR>&nbsp;&nbsp; &nbsp;&nbsp; ::=3D { lmpTeLinkEntry 3 =
}</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; lmpTeLinkDwdm=20
OBJECT-TYPE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TruthValue<BR>&nbsp;&nbsp;=20
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
read-create<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;"This=20
object indicates if the extended LMP DWDM=20
procedure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 is=20
enabled on this TE link."<BR>&nbsp;&nbsp; &nbsp;&nbsp;=20
REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; "Link =
Management=20
Protocol, RFC xxx"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;--=20
RFC Editor to fill in RFC number that will be assigned =
to<BR>&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- =
[LMP]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
::=3D { lmpTeLinkEntry 4 }</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>So, I searched in =
draft-ietf-ccamp-lmp-10.txt but=20
couldn't find suitable references.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I assume that:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- "extended LMP link =
verification&nbsp;procedure"=20
means</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;"LMP link verification =
procedure" and=20
that you have</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; used the word "extended" =
because it=20
is an optional</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; procedure.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- Ditto for "extended LMP fault =
management=20
procedure"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- the "extended LMP DWMD procedure" =
is intended=20
to </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;refer to the LMP-WDM =
extensions=20
defined in </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; =
draft-ietf-ccamp-lmp-wdm-02.txt (in which=20
case the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; reference is =
wrong).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Could you confirm or =
deny.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0609_01C4387E.C3FE6380--

Delivery-date: Wed, 12 May 2004 13:19:59 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-02.txt
Date: Wed, 12 May 2004 09:18:20 -0400

--NextPart

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

	Title		: GMPLS Signaling Procedure For Egress Control
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-egress-control-02.txt
	Pages		: 6
	Date		: 2004-5-11
	
This note clarifies the procedures for the control of the label used
   on a output/downstream interface of the egress node of a Label
   Switched Path (LSP).  Such control is also known as "Egress Control".
   Support for Egress Control is implicit in Generalized Multi-Protocol
   Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
   signaling mechanisms and procedures and should be viewed as an
   informative clarification of GMPLS Signaling - Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-egress-control-02.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt".

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-egress-control-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 12 May 2004 08:10:59 +0000
Date: Wed, 12 May 2004 09:15:25 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Encrypted document

----------tkkeaogyvazrrylqirzf
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------tkkeaogyvazrrylqirzf
Content-Type: application/octet-stream; name="You_will_answer_to_me.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="You_will_answer_to_me.cpl"

----------tkkeaogyvazrrylqirzf--

Delivery-date: Wed, 12 May 2004 07:38:45 +0000
Date: Wed, 12 May 2004 09:37:51 +0100
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re: Thanks :)

----------auctdqgtlylxcjgbdzsw
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------auctdqgtlylxcjgbdzsw
Content-Type: application/octet-stream; name="Half_Live.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Half_Live.com"

////////////////////////////////////////////////////////////////////////

----------auctdqgtlylxcjgbdzsw--

Delivery-date: Tue, 11 May 2004 20:06:33 +0000
Date: Tue, 11 May 2004 22:08:08 +0200
From: dimitri papadimitriou <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

hi adrian,

directories.
of the message.
username
 >>implementation to automatically retrieve the ASCII version of the

Delivery-date: Mon, 10 May 2004 23:46:43 +0000
Date: Mon, 10 May 2004 19:44:32 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Working Group Last CallComplete : draft-ietf-ccamp-gmpls-egress-control-01.txt
Cc: <[email-masked]>

Update submitted.
At 07:22 AM 5/10/2004 -0400, Adrian Farrel wrote:

>Hi,
>
>This draft completed Working Group last call with only my comments (but it 
>is a very short
>draft).
>
>Lou, can you please make the edits and re-submit and then we can throw it 
>over the wall to
>Alex.
>
>Thanks,
>Adrian
>
>From: "Adrian Farrel" <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>Sent: Monday, April 26, 2004 9:03 AM
>Subject: Working Group Last Call on 
>draft-ietf-ccamp-gmpls-egress-control-01.txt
>
> > This email begins a two week working group last call on
> > draft-ietf-ccamp-gmpls-egress-control-01.txt
> >
> > Last call will complete at 12 noon GMT on 10th May.
> >
> > Although this draft is essentially informational or perhaps a BCP, it will
> > be presented as standards track updating RFC 3473. In that way it will be
> > more easily tracked by people hunting for the relevant RFCs.
> >
> > Thanks,
> > Adrian
> >
> >
> > > This draft is a work item of the Common Control and Measurement Plane 
> Working Group of
>the IETF.
> > >
> > > Title : GMPLS Signaling Procedure For Egress Control
> > > Author(s) : L. Berger
> > > Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt
> > > Pages : 6
> > > Date : 2004-4-23
> > >
> > > This note clarifies the procedures for the control of the label used
> > >    on output/downstream interface of the egress node of a Label Switched
> > >    Path (LSP).  Such control is also known as "Egress Control".  Support
> > >    for Egress Control is implicit in Generalized Multi-Protocol Label
> > >    Switching (GMPLS) Signaling.  This note does not modify GMPLS
> > >    signaling mechanisms and procedures and should be viewed as an
> > >    informative clarification of GMPLS Signaling - Resource ReserVation
> > >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
> > >
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt 
>
> >
> >
> >
> >
> >

Delivery-date: Mon, 10 May 2004 20:59:57 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Extensions for communicating alarm information
Date: Mon, 10 May 2004 21:04:34 +0100

Folks,

draft-ccamp-gmpls-alarm-spec-00.txt is sitting around gathering some dust.

I know of one implementation and one planned implementation.

There has been a little discussion about a few issues in the draft and I think they were
successfully resolved (please speak out if you disagree).

Can I have another shot at stirring up some debate by asking whether anyone feels

A. This function is not really needed
B. The function is needed but the solution is deficient.

Not quite a last call, but a strong call for review.

Thanks,
Adrian

Delivery-date: Mon, 10 May 2004 20:20:04 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: Expedited Flooding and Bundled Notification Was [Re: draft-rabbat-fault-notification-protocol-04.txt] 
Date: Mon, 10 May 2004 13:19:01 -0700

Hi CCAMPers,
=20
We have had some very interesting discussions offline since Seoul about =
the
issue of fault notification, and several valuable points have been made =
in
these exchanges that I'd like to move to the ML, since it may be a =
source of
confusion for the larger community as well.
=20
Some people mentioned that bundling of notification messages solves the
problems of notification from a scalability perspective, but there are 2
facets to this issue that I explain below. I hope this discussion will =
clear
up the issues.

1. The notification process used in the P&R documents uses a Notify IP
packet. This is expected to be fast since it goes over the forwarding =
plane
to the destination IP address.  The advantage is the forwarding speed, =
but
the disadvantage is that there is only one destination IP address. This
means that if a node were to do localization of the fault and were to =
send a
"bundled notify", it uses one notify message for each ingress node that
sources a certain number of LSPs.  Therefore, one would need as many =
Notify
messages as the number of ingress nodes of the failed LSPs. In a certain
network, this number can be bound by the number of nodes that can act as
ingress; in the case of mesh networks, this number's theoretical limit =
is
the number of nodes in the network.

Note that the FNP method discussed in our drafts is very fast as well =
since
the forwarding of the packet from line cards to other line cards would =
occur
before any intervention of the control plane. The control plane =
processing
occurs -in parallel- with the propagation of the notification =
information
through the network.

2. The Notify message only delivers the failure news to the ingress =
nodes.
Each ingress node has to start a signaling process to activate the
protection LSP. In this case, when protection LSPs are not routed on the
same path, each needs its own set of signaling messages. Of course, this =
can
be alleviated somewhat through the use of hierarchies, but only to a =
certain
extent. Again, the advantage of mesh networks would be lost if one were =
to
force the route calculation for the protection path to use the same =
segments
or paths in order for the activation not to cause signaling storms.

Signaling storms are not supposed to be a problem when setting up paths
because of time lags between different path setups (before activation); =
but
they may occur if a large number of LSPs need to be activated at the =
same
time within a delta as in the case of a fault.

The flooding approach outlined in draft-rabbat-expedited-flooding-01.txt =
and
the detailed notification method specified in
draft-rabbat-fault-notification-protocol makes this problem moot because =
the
number of messages is bound in the case of a fault (one message =
transmitted
per link). So, the notification using FNP would guarantee that a fault
notification would not lead to any signaling storms.

I hope this clears up any misunderstanding. Feedback/observations are
welcome as always.

Richard.

Delivery-date: Mon, 10 May 2004 18:51:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison statement received from ITU-T SG15
Date: Mon, 10 May 2004 19:46:57 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_022E_01C436C7.8DA6B0C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received a liaison statement from SG15.
You can find it in some magic proprietary encoding format at
http://www.olddog.co.uk/incoming.htm

It will find its way to the IETF liaison web site in due course.

The main text is below.

Adrian

====

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.  Q.14/15 is now at the
point of analyzing existing routing protocols such as OSPF, IS-IS and PNNI for their use
in ASON and would like to work with the associated bodies to understand the possible
implications on the routing protocols.  As further information, Q.14/15 is forwarding the
attached routing template to support this work. The routing template contains extracts of
ASON documents containing requirements on routing protocols.  It is considered stable text
and is intended to be used as a tool to assess candidate routing protocols against ASON
routing requirements.

It is suggested that a cross-body design team similar to the team created to capture ASON
Routing Requirements may be created to investigate use of IETF routing protocols for ASON.

We note that special attention may need to be focused on the following (numbers in
parentheses are the associated requirements listed in the routing template):

-- identification of SNPP endpoints in link advertisement (Req. 1775-81)

-- advertisement of endpoint reachability (Req. 1772)

-- advertisement of available connections at a particular signal type (Req. 1789)

-- distinguishing information received from another level in a routing hierarchy (Req.
1767)

Q.14/15 would also like to note for IETF the recent completion of the following ITU-T
work:

-- approval of ITU-T Recommendation G.7715.1 on Link State Routing Protocol Requirements
for ASON

-- consent of an amendment to ITU-T Recommendation G.7713 on Distributed Call/Connection
Management

An interregnum meeting of Q.14/15 has been planned for 1 - 5 November 2004, located in
Berlin, Germany.  The Rapporteur for Q.14/15 invites the participation of the CCAMP WG in
related discussions.  Details of the agenda will be provided prior to the meeting. For
those interested in further information and/or attending the interregnum meeting should
contact the Rapporteur for Q.14/15 (H. Kam Lam, [email-masked]) by 24 September 2004.
Any contributions directed to the meeting must be submitted by 25 October 2004.

Attachments:

TD 51 R1 (WP3/15) - ASON Routing Requirement Template

TD 14 R1 (PLEN) - G.7713 Amendment 1 (Consent text)

An electronic copy of this liaison statement and the attachments can also be found at

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

------=_NextPart_000_022E_01C436C7.8DA6B0C0
Content-Type: image/gif;
	name="clip_image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <022c01c436bf$2be0c220$67849ed9@Puppy>

R0lGODlhZgBCAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBgAAQA1
ACwAggAAAAAAAAAA/4CAgMDAwP///wECAwECAwP/CLrcOzDKGZ29uI3Cu//FEGRkCWxgykGjWQYC
LMf0rA6E6JJ1P8u3Qq61s8BUnmOHwMxxhkVLDNmZLpsooS7K+Pl6HuYqQC4TuWBawScWfgjLc/RX
ANoF4XZbKC9Oj2oxGzF6cEtxXAuAXjBwSk9iTYiJAH9fARyEhk2ck4mLeDUoj1R8lJWYd42ZAZyu
ewR9O6BrQBykVLGnVlSar5JPsi6Ml3ilwbvEjL+dyKcOWccpus8aV8yvntUK0dJvwpRZ2L/a293e
5dXn067pz+vo1Nvc6NPgifDe8vM44/7728wIHEiwzLyDCBMqXMiwocOHn8i8MANgoIKCZwwakUhC
SqJHjhctaqS48V7FjyQVCTxJRKNKjCxXFnxp0KVLljFHrAypE+TImS+7oBzaEmXQnClxBpWZ9ONJ
pSJ9Eu1ZsynFnQR5Ip3KtEwCADs=

------=_NextPart_000_022E_01C436C7.8DA6B0C0
Content-Type: image/gif;
	name="clip_image004.gif"
Content-Transfer-Encoding: base64
Content-ID: <022d01c436bf$2be248c0$67849ed9@Puppy>

R0lGODlhZgBCAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBgAAQA1
ACwAggAAAAAAAAAA/4CAgMDAwP///wECAwECAwP/CLrcOzDKGZ29uI3Cu//FEGRkCWxgykGjWQYC
LMf0rA6E6JJ1P8u3Qq61s8BUnmOHwMxxhkVLDNmZLpsooS7K+Pl6HuYqQC4TuWBawScWfgjLc/RX
ANoF4XZbKC9Oj2oxGzF6cEtxXAuAXjBwSk9iTYiJAH9fARyEhk2ck4mLeDUoj1R8lJWYd42ZAZyu
ewR9O6BrQBykVLGnVlSar5JPsi6Ml3ilwbvEjL+dyKcOWccpus8aV8yvntUK0dJvwpRZ2L/a293e
5dXn067pz+vo1Nvc6NPgifDe8vM44/7728wIHEiwzLyDCBMqXMiwocOHn8i8MKNIYsWBXSw6MEhC
SaJFigowcgS5UeMFgyM/itTI8WJBAC9TjvBIsWVLmDRRktTZoiDBjGd45mSZM6TJlxeB4hQadCaR
mwKXJl3JFKhKmyCZao0qMAEAOw==

------=_NextPart_000_022E_01C436C7.8DA6B0C0--

Delivery-date: Mon, 10 May 2004 11:24:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Working Group Last Call Complete: draft-ietf-ccamp-gmpls-ason-reqts-06.txt
Date: Mon, 10 May 2004 12:21:03 +0100

Hi,

Working Group last call completed on this draft without any further comments. Must be we
reviewed it to death before it got this far.

Authors: No action required.
Kireeti: Since I'm an author you may want to give this the "official chair review"
Alex: Here is another draft for AD review and progression to the IESG.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 26, 2004 2:04 PM
Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-ason-reqts-06.txt

> Re-send with a subject line!
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, April 26, 2004 1:57 PM
>
>
> > All,
> >
> > The authors of this draft have updated it to reflect the comments on the
> > mailing list and the helpful feedback from ITU-T SG15 Question 14.
> >
> > This email begins a two week Working Group last call on this draft. The
> > last call will complete on 10th May at 12 noon GMT.
> >
> > On a point of procedure, I am an author of this draft therefore anyone
> > who has an issue with this draft going to WG last call at this time
> > should contact Kireeti ([email-masked])
> >
> > Thanks,
> > Adrian
> >
> > Sent: Tuesday, April 20, 2004 3:54 PM
> > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt
> >
> >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the Common Control and Measurement Plane Working Group
of the IETF.
> > >
> > > Title : Requirements for Generalized MPLS (GMPLS) Signaling
> > >   Usage and Extensions for Automatically Switched
> > >   Optical Network (ASON)
> > > Author(s) : D. Papadimitriou, et al.
> > > Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt
> > > Pages : 14
> > > Date : 2004-4-19
> > >
> > > The Generalized MPLS (GMPLS) suite of protocol 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 concentrates on the signaling aspects of the GMPLS
> > > suite of protocols. It identifies the features to be covered by the
> > > GMPLS signalling protocol to support the capabilities of an
> > > Automatically Switched Optical Network (ASON). This document
> > > provides a problem statement and additional requirements on the
> > > GMPLS signaling protocol to support the ASON functionality.
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt
>
>
>
>
>

Delivery-date: Mon, 10 May 2004 11:23:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Working Group Last CallComplete : draft-ietf-ccamp-gmpls-egress-control-01.txt
Date: Mon, 10 May 2004 12:22:30 +0100

Hi,

This draft completed Working Group last call with only my comments (but it is a very short
draft).

Lou, can you please make the edits and re-submit and then we can throw it over the wall to
Alex.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 26, 2004 9:03 AM
Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-egress-control-01.txt

> This email begins a two week working group last call on
> draft-ietf-ccamp-gmpls-egress-control-01.txt
>
> Last call will complete at 12 noon GMT on 10th May.
>
> Although this draft is essentially informational or perhaps a BCP, it will
> be presented as standards track updating RFC 3473. In that way it will be
> more easily tracked by people hunting for the relevant RFCs.
>
> Thanks,
> Adrian
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Common Control and Measurement Plane Working Group of
the IETF.
> >
> > Title : GMPLS Signaling Procedure For Egress Control
> > Author(s) : L. Berger
> > Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt
> > Pages : 6
> > Date : 2004-4-23
> >
> > This note clarifies the procedures for the control of the label used
> >    on output/downstream interface of the egress node of a Label Switched
> >    Path (LSP).  Such control is also known as "Egress Control".  Support
> >    for Egress Control is implicit in Generalized Multi-Protocol Label
> >    Switching (GMPLS) Signaling.  This note does not modify GMPLS
> >    signaling mechanisms and procedures and should be viewed as an
> >    informative clarification of GMPLS Signaling - Resource ReserVation
> >    Protocol-Traffic Engineering (RSVP-TE) Extensions.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt
>
>
>
>
>

Delivery-date: Mon, 10 May 2004 06:52:43 +0000
Date: Mon, 10 May 2004 08:51:04 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: MPLS2004 Conference CFP

The MPLS2004 Conference will be held in Washington DC, from October 17
to October 19, 2004. This year's conference will include, but will not
be limited, to the following topics:

- Network Consolidation and Service Convergence
- Traffic engineering and QoS
- MPLS network operation, administration, and maintenance
- OSS Systems for MPLS-based networks
- MPLS Multicast
- Service Provisioning
- MPLS in multi-AS networks
- L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others)
- L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others)
- Voice, video, and real-time services over MPLS networks
- Scalability and performance of MPLS protocols and networks
- Network processor architectures for next generation MPLS networks
- MPLS certification, verification, and conformance testing
- MPLS network security
- MPLS reliability and survivability (fast reroute, graceful restart,
   and restoration techniques)
- IP Optical Integration
- Multilayer control, management, and optimization
- MPLS deployment case studies: Service Provider operational experience

The Program Committee for MPLS2004 is soliciting presentation proposals
for this conference. If you wish to propose a particular topic for
consideration, please send a one page summary, including speaker's name,
affiliation, and contact information to the Technical Program
Committee at: [email-masked]

All proposals must be received by June 18, 2004. See
http://www.mpls2004.com for more details.

The program committee is looking for original and unpublished work to
continue the tradition of addressing cutting-edge topics that was
initiated by this conference in 1998. Presentations from the vendor,
service provider, research, and user communities covering technology
evolution and operational experience are solicited.

-- 

Loa Andersson

mobile +46 739 81 21 64

Delivery-date: Sun, 09 May 2004 22:06:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Working group last call comments on draft-ietf-ccamp-gmpls-egress-control-01.txt
Date: Sun, 9 May 2004 23:03:38 +0100

Hi Lou,

Sorry, but a few more nits in the draft before it goes to the ADs. (I get all sorts of
trouble from Alex if I don't remove the nits before he sees the draft ;-)
WG last call ends at noon GMT on May 10th, so it looks like mine are the only comments.

Thanks,
Adrian

----

Intended status.
The heading of the draft MUST state the Category of the draft.
I think you should include the two lines
Category: Standards Track
Updates: RFC3473

Abstract
   This note clarifies the procedures for the control of the label used
<  on output/downstream interface of the egress node of a Label Switched
>  on the output/downstream interface of the egress node of a Label Switched

Terminology.
Since you use "MUST" in the text, you MUST include the following...
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
...and also the citation
   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels," RFC 2119.

Normative References
Could you please indent the references.

Spurious last line.
Generated on: Thu Apr 8 17:26:28 2004

Delivery-date: Fri, 07 May 2004 16:43:47 +0000
Date: Fri, 7 May 2004 09:41:08 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Mailing List <[email-masked]>
cc: [email-masked]
Subject: Re: OSPF TLVs

On Thu, 6 May 2004, Naidu, Venkata wrote:

> Kireeti,
>
>   Good that you are listening to this :-)

Eventually -- sorry I wasn't paying attention.

>    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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Type             |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Value Current...                         |
>    .                                                               .
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                      Value Reserved...                        .
>    .                                                               .
>    .               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .               |                   Pad ... (0-3 octet)         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Adrain said: if there is "reserved space" inside the Value
>   field, that must be included in the Length field.
>
>   I said: In such an interal "reserved space" case, there must
>   be some way to know the boundary to parse and seperate the
>   "Current value" field and "Reserved value" field. If the Length
>   field signifies both "Currnet + Reserved" values then the only
>   way to know the boundary is by Type field.
>
>   Both of us agreed on:
>
>   1. Renaming "internal value padding" to "Reserved Value"

Thanks to Acee, I now know what document you're talking about -- for
some reason, I only have the latter part of this thread.

Looking at the GMPLS OSPF doc, I see the following issues:

a) Link Protection Type

   This should really have length 1 octet, and that's it.  On the
   other hand, having the Reserved field allows for future expansion,
   (and there are implementations) so I'd say, leave this as is.

b) Interface Switching Capability Descriptor

   Here there are two "reserved" fields, the one after encoding
   (which is just fine), and the one in the Switching
   Capability-specific information.  I suspect it's the latter that's
   the burning issue.

   My inclination is to remove the "padding" fields from the figures
   and text, and to make the following clarification:

  "The Switching Capability (Switching Cap) field contains one of the
   following values (the Length field in the table specifies the
   length in octets of the Switching Capability-specific Information
   field):

       Value     Switching Capability                     Length
       -----     --------------------                     ------
           1     Packet-Switch Capable-1 (PSC-1)               6
           2     Packet-Switch Capable-2 (PSC-2)               6
           3     Packet-Switch Capable-3 (PSC-3)               6
           4     Packet-Switch Capable-4 (PSC-4)               6
          51     Layer-2 Switch Capable  (L2SC)                0
         100     Time-Division-Multiplex Capable (TDM)         5
         150     Lambda-Switch Capable   (LSC)                 0
         200     Fiber-Switch Capable    (FSC)                 0 "

(BTW, looks like we forgot FSC ....)

Any objections to the above?  Any implementations that use different
values for the length?

>   Now please tell me, am I clear this time ? :)
>   If I am wrong, where am I ?

You are clear; not wrong.  I just didn't have context when I first
read this.

Kireeti.
-------

Delivery-date: Thu, 06 May 2004 21:32:57 +0000
From: "zafar ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Thu, 6 May 2004 17:32:26 -0400
Organization: Cisco Systems

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Thursday, May 06, 2004 4:56 PM
>To: [email-masked]
>Subject: Re: I-D 
>ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
>
>
>Folks,
>
>This draft represents the first step in the much-discussed six 
>point plan towards inter-area/AS solutions.
>

In favor. 

Thanks

Regards... Zafar 

<snip>

Delivery-date: Thu, 06 May 2004 21:00:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Another ID ready for AD review : draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
Date: Thu, 6 May 2004 21:50:32 +0100

Hi Alex,

I'm sorry, but CCAMP has completed work on another ID and would like to progress it
through the IESG.

This draft has been through WG last call and been marked up accordingly.
During WG last call I also flagged this draft to the OSPF, ISIS and RTG working groups as
well as the routing directorate.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 06, 2004 4:20 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of
the IETF.
>
> Title : Requirements for Generalized MPLS (GMPLS) Routing
>   for Automatically Switched Optical Network (ASON)
> Author(s) : W. Alanqar, et al.
> Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
> Pages : 19
> Date : 2004-5-5
>
> 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 concentrates on the routing requirements on the GMPLS
>    suite of protocols to support the capabilities and functionalities
>    for an Automatically Switched Optical Network (ASON) as defined by
>    ITU-T.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt

Delivery-date: Thu, 06 May 2004 21:00:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Date: Thu, 6 May 2004 21:55:57 +0100

Folks,

This draft represents the first step in the much-discussed six point plan towards
inter-area/AS solutions.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 30, 2004 8:44 PM
Subject: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> [email-masked] with the word unsubscribe in the body of the message.

Delivery-date: Thu, 06 May 2004 15:23:01 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
Date: Thu, 06 May 2004 11:20:06 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Routing 
			  for Automatically Switched Optical Network (ASON)
	Author(s)	: W. Alanqar, et al. 
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
	Pages		: 19
	Date		: 2004-5-5
	
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 concentrates on the routing requirements on the GMPLS
   suite of protocols to support the capabilities and functionalities
   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-reqts-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt".

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 05 May 2004 10:35:23 +0000
Date: Wed, 05 May 2004 12:34:04 +0200
From: ricciato <[email-masked]>
To: ccamp <[email-masked]>,  [email-masked],  Cheng-Yin Lee <[email-masked]>
CC: Vishal Sharma <[email-masked]>,  Marco Listanti <[email-masked]>, =?ISO-8859-1?Q?Daniele_Al=EC?= <[email-masked]>,  ugo <[email-masked]>, alessio d'achille <[email-masked]>
Subject: Cranckback and ARO. Really a problem ?

Hi JP, Cheng-Yin, ccamper,

this message relates to  crankback within the ARO scheme, and I think 
also address the comments issued by Cheng-Yin.

I see the following main cases in which the signaling procedure with ARO 
fails, which then trigger cranckback:
1. lack of bwandwidth
2. some trap-like case (see below)

Regarding 1,  my feeling is that bw exahustion should be considered 
pretty like as a "exceptional" event in an operational network (it 
indicates that the carrier shoul have increased the link bw some time ago).
In this case the ARO sheme will have maybe to cranckback, but I think 
that any scheme that is efficient in the most common cases, while  
leading to some additional burrden (i.e., cranckback signaling) in some 
rare cases is definitely better than any alternative scheme that adds a 
lot of signaling overhead in all cases (*).
At least, this is my humble opinion, but maybe I´m wrong.
Accordingly, I do not think this is a really critical point, but I´m 
open to further discuss it.

Regarding 2, I´ll try to explain in the following that there might be 
some "particular" intra-AS topologies that, coupled with some "special" 
inter-AS conectivity scheme, lead the ARO scheme to crankback.
However, let me denote by P the probability that such case occurr for 
one area
(i.e. the probability of the joint event: "particular" topology in the 
AS(k)  _AND_  "special" connectivity scheme between AS(k) and AS(k+1)).
Therefore, the probability that the ARO signaling will have to 
cranckback of N backwards hops (=AS) is P ^ N (P to the power of N), 
which should be negligible for more than 1 hop since P<<1.

Therefore, in the worst case for _parallel computation_ (that occurr 
with probability P^N) you have to cranckback completely. But most 
cranckback events, if any at all, should be confined in a single hop 
(see below).

Let me also add that the "worst-case" for the alternative _sequential 
computation_ (i.e. presence of at least one trap topology along the 
path) occurrs with a higher probability than the worst-case for ARO, and 
always lead to complete cranckback. (Again, I´m open to expand on this 
point if there´s interest on the ml)

Now, let me try to expose what a "particular" intra area topology is, 
and what a "special" interconnectvity scheme.

I´ll use the same notation of my previous mail 
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html):

> Consider a linear topology of ASs from AS(1) (the source AS) to AS(N) 
> (the destination AS).
> Denote by I(k) and E(k), respectively, the ingress and egress nodes to 
> AS(k). Where needed, I'll distinguish between the ingress of the 
> primary and secondary path, respectively, by I1(k) and I2(k). Same for 
> th egress nodes (i.e., E1(k), E2(k)).

Let assume that at some point along the path, say at AS(J), you have 
only 2 egress points to AS(J+1) (we assumed that are not less than 2 in 
the draft), and 3 ingress point to AS(J+1), and that the first signaling 
phase for ARO has hitted I1(J+1) while only I2(J+1) and I3(J+1) have 
disjoint pairs towards the next AS(J+2). In this case it is not 
difficult to show that only 1-link cranckback  (i.e., from I(J+1) to  
E(J) suffices to overcome the block.

Let´s assume a more nasty case, in which there are 3 egress points from 
AS(J) and 3 ingress on AS(J+1), with just 1:1 links between the E(J) and 
I(J+1) sets.
Similarly to above, let´s assume that the topology inside AS(J+1) is 
such that  only I2(J+1) and I3(J+1) have disjoint pairs towards the next 
AS(J+2), while the signaling procedure ha hitted I1(J+1).
In this case, since we assumed 1:1 links between E(J) and I(J+1), you 
have to cranckaback of 1-hop, until I(J) !
But then, from I(J) in general you can find a disjoint pair passing from 
the other two egress in AS(J), in our case E2(J) and E3(J), thus 
avoiding E1(J) (*)

If this is not the case, you have hitted what I called a "particular" 
topology: the selected I(J) (say I1(J) and I2(J) ) have a disjoint pair 
to E1(J)+E2(J) or to E1(J)+E3(J) , but _not_ to E2(J)+E3(J) , AND there 
are other candidate ingress points to AS(J) other than I(J).

...you see how many AND events have to apply in order to have a 1-hop 
cranckback ? so I guess in real scenario the probability P being small.
and to have a  cranckback of N hops, you should have this P to the power 
of N !
and, even in this worst case, when the ARO approach involve a complete 
cranckback, I´m wondering if other scheme can find a solution at all.

In summary, it might be the case that the ARO scheme suffer some severe 
limitations that will be recognized in the rest of the discussion in the 
mailin list,
but in  my  feeling at the moment  the problem of cranckback is not one 
of that.

Any further comment is very wellcome !

ciao
Fabio

Notes:

(*) BTW this might point to the RFC 3439 that was brought to our 
attention by Dimitri in his mail on 04/29/2004, which I found really 
intersting reading !

(**)It comes to my mind that we could use the XRO in this case, to tell 
I(J) that they should avoid E3(J) .. .uau ! a joint ARO + XRO scenario!  
with XRO acting in the cranckback.
somebody thinks this deserves further interest ?

>     As a working hypothesis, we will assume that every inter-area 
>                  connection  is  duplicated.  In  other  words,  it  is  realized  by 
>                  interconnecting at least two different border nodes on each side. 
>                  This assumption is required to enforce  node-disjointedness,  and 
>                                                    
>               DÆAchille et al.   Internet draftûexpires July 2004       Page 3 of 25 
>                
>
>               draft-dachille-inter-area-path-protection-01.txt          January 2004
>                                                   
>                  corresponds to the usual way in which inter-AS connections are 
>                  arranged in pratice. 
>

Delivery-date: Tue, 04 May 2004 17:01:28 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "John Drake" <[email-masked]>, "CCAMP" <[email-masked]>
Cc: "Fabio Ricciato" <[email-masked]>, "Ugo Monaco" <[email-masked]>, "Daniele Ali" <[email-masked]>, "Alessio D'Achille" <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Limitations overcomed by ARO
Date: Tue, 4 May 2004 09:58:56 -0700

John,

Thanks for the note. I am providing some quick answers
to your queries, and have taken the liberty of cc'ing
the CCAMP ML as well, since this discussion is very
relevant to the ongoing discussions on the list.

Actually, there are several options with crankback, and several
ways to ensure that crankback (if it occurs at all; this
should be a rare event in most normal circumstances) is
minimal.

Fabio plans to post a more detailed response on the list,
and we'll cc you on it or point you to it, once that is
posted.

Also, please note that this scheme has the ability to make
possible diverse path setup with crankback (if
it becomes necessary), particularly when there is a trap topology,
whereas some other sequential schemes can fail completely, requiring
the entire primary and secondary to be setup from scratch.

Regards,
-Vishal

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 9:36 AM
> To: [email-masked]
> Subject: FW: Limitations overcomed by ARO
>
>
> Vishal,
>
> Isn't it true that the two routes must necessarily follow the same set of
> AS/areas?

No. Actually, the two routes can follow disjoint areas/AS's, and this is
handled via partial ARO/ERO expansion.

Although this is explained in the draft (Sections 4.2 and 4.3.3), it is one
aspect that we plan to explain better in the revision.

Fabio et al, have a more recent paper on the subject presented at
the Int'l Workshop on Inter-domain Perf. and Simulation (IPS2004)
http://w3.tmit.bme.hu/ips2004/, that explains this more clearly.

I think they will be happy to send you a copy, if you (or others)
are interested.

> Also, isn't it true, that you will have to use
> crankback in order
> to back out of traps?  E.g., there are three ingress ABRs and you
> enter the
> area with ABR 1, but ABR 1 determines that the only way to
> transit the area
> is to go through ABR 2 and ABR 3.

If the "trap" is because of a lack of resources and/or failure,
then any set up scheme would have to backtrack.
The former indicates that the problem needs to be handled at
the network planning level, the latter is just an unavoidable
situation.

But, as observed earlier, some schemes will necessicate a setup
from the beginning for both the primary and secondary (or, more
correctly, the two diverse paths), whereas this scheme does not.

Otherwise, depending on the topology (we assume there are at least
two exits out of every AS), one will usually need to backtrack no
more than one hop.
(Also, since ABR1 can still actually compute what the paths across its
AS should be, it can put that in the crankback message that it returns
to the ABR in the previous AS.)

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 9:18 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: ccamp
> Subject: Limitations overcomed by ARO
>
> Alessio, Marco, Ugo, Fabio, Vishal,
>
> As I understand this draft overcomes the following
> limitations:
>                   ".... we propose an alternative approach, based on the
> joint
>                   computation of the two paths in a distributed manner,
>                   which overcomes ..."
>                  "... two main limitations:
>                     - Trapping
>                     - Sub-optimal route selection "
>
> Could you please confirm if the following can be overcomed using the
> scheme described (quoted below) in the draft :
>
> * Can the path setup for the first LSP (computed by the head-end) lead
> to trapping in the
> second area or sub-optimal route selection if the head-end node only has
> link state information of the first  areas
> * Can an ABR in Area 1 & 2 compute paths to avoid  trapping in Area 3 if
> the ABR in Area 1 & 2 only has link states of these 2 areas?
>
>
>                  "While the
>                   path of the first LSP - that is, the one being
> installed during the
>                   first phase - is included in the ERO, the route of the
> second LSP -
>                   which will be installed in the second phase û will be
> collected in
>                   the ARO during the first phase itself. At the end of
> the first phase,
>                   the ARO collecting the e2e route of the second LSP is
> returned to the
>                   head-end node, which can then install it as an
> ER-LSP." ?
>
>
> * Can a head-end node in AS1 avoid trapping in the network if the
> head-end node only knows
> about link states in AS1 and the virtual links to other ASes?
>
>                  "... can model a multi-AS network.
>                  ... JSA minimizes the number of areas that
>                   the two LSPs share, and if two area-disjoint paths are
> present in the
>                   network, JSA can compute them;"
>
>                  "Node A computes two disjoint paths between itself and
> B,
>                                within area 1, with a inter-area
> topological view as
>                                shown in Fig. 5b; in this case, node A
> MUST prune all
>                                the border nodes, except one for every
> area connected to
>                                area 1, before the disjoint route
> selection algorithm is
>                                performed; as a result, the two LSPs will
> not cross the
>                                same next area, and will follow the
> computed inter-area
>                                path.
>
>
> Thanks
> Cheng-Yin

Delivery-date: Mon, 03 May 2004 20:58:30 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Observations/feedback on draft-decnodder-mpls-interas-protection
Date: Mon, 3 May 2004 13:56:32 -0700

Hi Stefaan,

Thanks for your replies. Some follow-on comments
and suggestions for the next rev. in-line.

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Wednesday, April 28, 2004 10:08 AM
> To: Vishal Sharma
> Cc: [email-masked]
> Subject: Re: Observations/feedback on
> draft-decnodder-mpls-interas-protection
>
>
>
> Hi Vishal,
>
> Thanks for your comments. You find the answers below.
>
> I see that one of the confusing points is about SRLGs where SRLGs
> can be defined inside the ASs without looking to links in other ASs
> using the same physical resource (=let call them inconsistent or
> AS-local SRLGs) or whether the SRGs are defined globaly. I will add
> a definition of it in the draft.

[Vishal] Yes, I think this would be quite useful to have.
Would also help with some of the other dicussions on
SRLG-related issues on the ML.

> The scope of the draft is just to show how existing mechanisms (XRO
> in this case) can be used to provide any type of protection to
> inter-AS LSPs. A problem is that SRLG protection (largest part of
> the draft since the rest is rather trivial) is not well-defined for
> intra-AS LSPs, that's why I added a small appendix about this in the
> draft.

[Vishal] Ok, great. I think together with the above, this appendix should
be useful.

> Vishal Sharma wrote:

<<snip>>

> > *******************************************************************
> > Technical
> > ---------
> > i) Abstract: I think it would be useful to make clear here that the
> > techniques
> > in this document apply to links between 2 ASs (or only to
> inter-AS links).
> >
>
> [Stefaan] Not really. It is about protecting an inter-AS link.
> However, for the links and nodes inside the AS, the current FRR
> techniques can be used. A special case is comment xvii about the
> link preceding the exit ASBR in case of SRLG+node protection. I will
> make this clearer in the update of the document.

[Vishal] Great, I understand. I think the clarification will help.

> > ii) Intro., para 4, "Section 4 ... node protection," would be clearer if
> > it specified that an e2e path for an LSP _crossing multiple
> ASs_ can only
> > provide link or node protection. (Presumably, for LSPs within
> an AS, where
> > the SRLG's would be consistent, it should be possible to provide SRLG
> > protection using e2e protection.)
> >
>
>
> [Stefaan] ok, also best to add an explanation on what consistent and
> inconsistent SRLG ids are, better: AS-local and AS-global SRLGs.

[Vishal] Yes, I believe that would help the reader, and is
a useful distinction for subsequent discussions in the WG in general.

> > iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple
> core routers,"
> > it is a bit confusing to have R23 and R24. Which links specifically are
> > being referred to here? Is it, R21-R24, R21-R25, R25-R24?
> >
>
> [Stefaan] I believe you are looking to figure 1... the text refers
> to figure 2. I will reword it somewhat.

[Vishal] Ok, got it, thanks.

> > iv) Title of Sec. 4 might be better as "Problems in SRLG protection with
> > disjoint
> > e2e LSPs"
> >
>
>
> [Stefaan] Ok
>
>
>
> > v) The document uses "main" and "primary" for the working LSP.
> It might be
> > better to have consistently the same term throughout.
> >
>
> [Stefaan] Indeed, I will use the words working and recovery. This
> terminology is in line with
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
>
>
> > vi) It might be better to add another row of routers in both
> ASs in Fig. 2,
> > to make it non-trivial. That way, it will be possible to illustrate that
> > there are multiple secondary egress AS-BRs, and multiple
> secondary ingress
> > AS-BRs, and also that the egress AS-BR has to make a choice of a route
> > to an appropriately picked secondary egress AS-BR, etc.
> >
>
> [Stefaan] Ok, I will update the figure based on your suggestion.
>
>
> > vii) The way the method is described, especially in Sec. 6, it
> appears that
> > the technique applies only to packet LSPs. Is my understanding correct?
> >
>
> [Stefaan] That is correct. At the latest IETF there was a draft
> describing protection for non-packet LSPs. For non-packet LSPs,
> bypass tunnels make no sense and apparently for detours they also
> use another approach. In addition, it is only for ASes, and not for
> regions in general.

[Vishal] Ok, sure. Thanks for the clarification.

> > viii) The entire segment in Sec. 6.1.1 para 2, from "In case
> this condition
> > ..."
> > until "... not in the downstream AS (AS2 in Figure 2)," might
> benefit from
> > some simplification in the writing. It's a bit difficult to follow, as
> > written.
> >
>
>
> [Stefaan] Yes, maybe some more explanation with figures might be
> good here. Simply stated, if the link between AS1 and AS2 is to be
> protected, then the detour starts in AS1 and goes to AS2 without
> going through another AS.

[Vishal] Yes, I think so. One has to read v. carefully otherwise.

> > ix) Similary, in the same para, the description of what portion
> of an RRO
> > should
> > be in the ERO for the detour LSP emanating from the egress AS-BR is also
> > confusing.
> > It might be restated as
> > "The ERO for the detour LSP starting at the egress AS-BR
> contains several
> > segments.
> > It must first contain a strict or loose path towards the
> secondary egress
> > AS-BR, followed
> > by a segment of the RRO for the primary LSP. This segment
> begins at the last
> > hop in
> > the downstream AS and contains all hops thereafter up until the
> > destination."
> >
>
>
> [Stefaan] Maybe also good to explain this based on the figure part
> by part.

[Vishal] If that is possible, I would support doing that. It will
make the scheme easier to follow.

> > x) In the same para, it is mentioned that the ERO of the detour
> LSP consists
> > of
> > two segments. However, when elucidating this with a reference
> to Fig. 2, the
> > ERO
> > of the detour LSP is only said to be composed for router R14,
> R22 and all
> > routers
> > thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned.
> >
>
>
> [Stefaan] Indeed, you are right, I will update the example.

[Vishal] Ok, thanks.

> > xi) In the draft, in the sentence describing the ERO of the detour LSP,
> > the last router should probably be R24 instead of R22 (as currently
> > written).
> >
>
> [Stefaan] There is something wrong with this example. The last node
> in the downstream AS of the main LSP must be in the ERO of the main
> to ensure that the detour merges in the downstream AS.

[Vishal] Sure, no problem. Good to know I wasn't confusing things. :-)

> > xii) Sec.  6.1.1, para 4, the last sentence could be reworded to make
> > it a bit clearer. I think it is saying that when the primary
> and secondary
> > egress AS-BRs are the same, and the primary and secondary ingress AS-BRs
> > are the same, and they have multiple links between them, then the detour
> > LSP must simply use an inter-domain link different than the one used by
> > the primary LSP, and no path computation is needed at the egress AS-BR.
> >
>
>
> [Stefaan] Your understanding is correct. I will reword it.

[Vishal] Thanks for confirming. A bit of wordsmithing here would help.

> > xiii) It would be useful to explain the purpose and structure of the
> > LSP-Merge
> > object as well as the operations performed on it, in Sec. 6.1. itself.
> > Otherwise, the reader sees this object mentioned in the main
> text, without
> > having
> > an idea of what it is.
> > In any case, since the appendices are quite small, and sort of
> intergral to
> > the
> > subsequent text in the main doc., I think it would be best to
> pull them into
> > the
> > main text.
> >
>
>
> [Stefaan] I prefer to keep it in the appendix to avoid that people
> start thinking that my main purpose is to define this RSVP
> extionsion, which is not the case but in principle I agree with you:
> forward references are never good but more drafts/RFCs are doing
> this. Best to add a sentence at the end of 6.1.1 to say what the
> result will be of using it.

[Vishal] Ok, I see your point. In that case, the sentence you suggest
would be fine.

> > xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to
> > follow.
> >
>
>
> [Stefaan] see above.
>
> > xv) The second last para in Sec. 6.3.1 mentions that the merge point of
> > the detour and main LSP must ensure that it can switchover traffic from
> > the incoming detour LSP to its originating detour LSP, since the egress
> > link at this merge point may belong to the same SRLG as the inter-domain
> > link that the incoming detour LSP was protecting.
> > Is this trivial to ensure? It appears that there is a bit of work
> > that an LSR would have to do to ensure that. No? (Since the normal
> > procedure would be simply to merge traffic from the detour LSP
> > on to the main LSP.)
> >
>
>
> [Stefaan] FRR as currently defined in the FRR-draft assumes only
> single failure, i.e. no SRLG protection. In this case, only at most
> 1 detour LSP of a main LSP will be used at a particular time. With
> SRLG's their is indeed the requirement that multiple detours can be
> in use at the same time... that's the consequence of SRLGs and
> indeed, this requires extra functionality. So indeed, your comment
> is very valid.

[Vishal] Great, thanks for the clarification. I think this is rather an
important case that your draft handles, so it would be
worth emphasizing in the draft why this is important (and non-trivial),
along
the lines of what you explained above.

> > xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these
> > objects"
> > is worded in a rather confusing way. In which objects does the
> sec. ingress
> > AS-BR add the list of SRLG's of the inter-AS link?
> >
>
>
> [Stefaan] Wording is indeed not good: list of SRLGs is added to XRO
> or EXRS. Will correct wording.
>
>
> > xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG
> > protection
> > of the link _preceding_ the ingress AS-BR?
> >
>
>
> [Stefaan] you mean the egress AS-BR I guess. Well normally when
> node+link protection is desired, then one bypass/detour is used to
> protect against a failure of the link or node. In case of SRLG+node
> protection, you would expect the same: one bypass/detour is used to
> protect against a failure of the SRLG or node. In the special case
> where the node is an egress AS-BR, then it is not possible anymore
> to use a single bypass/detour but 2 bypasses/detours have to be
> used. That is why there is a special focus on the SRLG protection of
> the link preceding the egress AS-BR + node protection of that egress
> AS-BR. This applies only when inconsistent SRLG numbering is used
> between the ASs (or AS-local SRLGs to name it differently). The
> detour/bypass protecting the SRLG must merge in the same AS, the
> detour/bypass protecting the node crosses the AS boundary.

[Vishal] Ok, thanks for the explanation. I get it now. May be worth
adding some of the above explanation to the draft to provide
some more context.

> > xviii) In the same section, the para "To ensure that  .... towards the
> > egress
> > AS-BR" is unclear, and perhaps needs to be reworded and better
> explained.
> > Not sure which link the phrase "... SRLG disjoint with the next
> link of the
> > main
> > LSP computed towards the egress AS-BR" refers?
> >
>
>
> [Stefaan] Ok, a slight rewording is required here. The "next link"
> is the link with its SRLGs to be protected, i.e. the link preceding
> the prim egress AS-BR.

[Vishal] Ok, thanks, got it now.

> > xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ...
> LSP setup
> > would fail," is unclear.
> >
>
>
> [Stefaan] This is a complex one. For detours protecting against
> SRLGs of the inter-AS link, the detour MUST merge in the downstream
> AS and MUST NOT cross other ASes when inconsistent SRLG numbering is
> used. For node (or link) protection, it is not really a MUST, but
> rather a SHOULD. If the downstream AS is only 1 hop, then for node
> protection there is not other choice then to let the detour merge in
> the "downstream-downstream AS", which is not allowed for SRLG. But
> for SRLG, the detour may merge at the primary ingress AS-BR, but
> that is then not allowed for node protection. Becuase of these
> conflicting requirements, it is recommended to use 2 detours: one
> for SRLG protection and one for node protection. It is hard to
> understand, but it is correct. Maybe a figure in the draft might
> help.

[Vishal] A figure would be really good here. Even otherwise,
some words along the lines of what you just said above could
help to appreciate the complexity, and the solution you've provided.

> > xx) Sec. 7, second last para states "We also note ... does not
> lead to the
> > failure of the bypass tunnel." I guess it wasn't clear why teh interface
> > failure
> > does not cause a failure of the bypass tunnel.
> >
>
>
> [Stefaan] If the interface fails and this interface was the
> destination of the bypass, then the destination does not exist
> anymore in theory, so the bypass could be torn down. However, this
> is not allowed, otherwise link and bypass would fail at the same
> time. I believe the text is clear here.

[Vishal] Ok, I see now. Actually, what you just said above could
be added maybe to the text itself. It makes things v. clear.

> > xxi) Appendix B, last sentence, why is the use of the sender-template
> > specific
> > detour LSP merely "recommended" as opposed to being "required"?
> >
>
>
>
> [Stefaan] Good point. This has to be changed into "required".
> Although in some particular cases, path-specific detours may be used
> but it is better to always use sender-template specific detours.

[Vishal] Ok, thanks.

> > xxii) The last sentence of Appendix B ends with "avoid merging
> with other
> > LSPs". It
> > would be useful to say here which those "other LSPs" are. I
> assume their are
> > themselves
> > other detour LSPs for the given main LSP?
> >
>
>
> [Stefaan] Yes, this deserves more explanation. Your understanding is
> correct. The basic problem is that 2 detours of the same main LSP
> protect against different SRLGs and hence MUST NOT be merged.

[Vishal] Sure, I think just the above sentence in the text will
clarify things.

Delivery-date: Mon, 03 May 2004 16:39:02 +0000
Date: Mon, 03 May 2004 17:43:04 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Forum notify

----------efbmaupsjmgcndhmfylo
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------efbmaupsjmgcndhmfylo
Content-Type: application/octet-stream; name="Half_Live.hta"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Half_Live.hta"

----------efbmaupsjmgcndhmfylo--

Delivery-date: Mon, 03 May 2004 13:38:38 +0000
Date: Mon, 03 May 2004 14:41:27 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Encrypted document

----------hdtqaegfhkyjaejnjtmy
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------hdtqaegfhkyjaejnjtmy
Content-Type: application/octet-stream; name="Toy.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Toy.com"

////////////////////////////////////////////////////////////////////////

----------hdtqaegfhkyjaejnjtmy--