Subject: Incoming liaisons from ITU-T SG15 Q14

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 01 Mar 2004 00:15:29 +0000

We have received several liaisons form ITU-T Study Group 15 Question 14 on 
ASON signaling and routing. 

These will be published on the IETF's site in due course. Until then, you 
can find them at http://www.olddog.co.uk/incoming.htm 

Please read and digest before the meeting on Thursday. 

Thanks,
Adrian

Delivery-date: Sat, 28 Feb 2004 07:00:13 +0000
Date: Sat, 28 Feb 2004 15:57:48 +0900
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
CC: [email-masked]
Subject: Re: Missing IDs

The problem has been fixed.
-- 
Alex
http://www.psg.com/~zinin/

Thursday, February 26, 2004, 2:51:54 AM, Adrian Farrel wrote:
> All,

> A few IDs got submitted and ack'd before the deadline but seem not to have made it to the
> repository.

> draft-ietf-ccamp-gmpls-tc-mib-04.txt
> draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> draft-vasseur-ccamp-loose-path-reopt-00.txt
> draft-vasseur-ccamp-isis-te-caps-00.txt

> You can find them at http://www.olddog.co.uk/missing.htm

> Cheers,
> Adrian

Delivery-date: Fri, 27 Feb 2004 15:56:10 +0000
Date: Sat, 28 Feb 2004 00:54:37 +0900
From: Kenji Kumaki <[email-masked]>
To: [email-masked]
Subject: Re: Missing IDs

Hi all,

I am one of the co-authors of inter-area/AS requirement draft.
These two drafts meet inter-area/AS requirement and are very useful 
when inter-area/AS LSPs are established.

So I would like to support these two drafts.

Regards,
Kenji

On Fri, 27 Feb 2004 10:00:04 -0500
Jean Philippe Vasseur <[email-masked]> wrote:

> Hi,
> 
> First of all, thanks Adrian for making the drafts (not yet on the IETF 
> repository) available.
> 
> Just to mention that draft-vasseur-ccamp-loose-path-reopt-00.txt (which is 
> actually the next revision of draft-vasseur-mpls-loose-path-reopt-02) 
> addresses an item of draft-vasseur-ccamp-inter-area-as-te-00, namely, how 
> to reoptimize a TE LSP configured as a set of loose hops (with per-area/AS 
> path computation).
> 
> Comments are very welcome.
> 
> JP.
> 
> >Reply-To: "Adrian Farrel" <[email-masked]>
> >From: "Adrian Farrel" <[email-masked]>
> >To: <[email-masked]>
> >Subject: Missing IDs
> >Date: Wed, 25 Feb 2004 17:51:54 -0000
> >X-Mailer: Microsoft Outlook Express 6.00.2800.1158
> >X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
> >X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_01,RCVD_IN_SORBS
> >         autolearn=no version=2.63
> >Sender: [email-masked]
> >X-PMX-Version: 4.1.1.86173
> >X-from-outside-Cisco: 128.107.250.144
> >
> >All,
> >
> >A few IDs got submitted and ack'd before the deadline but seem not to have 
> >made it to the
> >repository.
> >
> >draft-ietf-ccamp-gmpls-tc-mib-04.txt
> >draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> >draft-vasseur-ccamp-loose-path-reopt-00.txt
> >draft-vasseur-ccamp-isis-te-caps-00.txt
> >
> >You can find them at http://www.olddog.co.uk/missing.htm
> >
> >Cheers,
> >Adrian
> 

-- 
Kenji Kumaki <[email-masked]>

Delivery-date: Fri, 27 Feb 2004 15:01:06 +0000
Date: Fri, 27 Feb 2004 10:00:04 -0500
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Fwd: Missing IDs

Hi,

First of all, thanks Adrian for making the drafts (not yet on the IETF 
repository) available.

Just to mention that draft-vasseur-ccamp-loose-path-reopt-00.txt (which is 
actually the next revision of draft-vasseur-mpls-loose-path-reopt-02) 
addresses an item of draft-vasseur-ccamp-inter-area-as-te-00, namely, how 
to reoptimize a TE LSP configured as a set of loose hops (with per-area/AS 
path computation).

Comments are very welcome.

JP.

>Reply-To: "Adrian Farrel" <[email-masked]>
>From: "Adrian Farrel" <[email-masked]>
>To: <[email-masked]>
>Subject: Missing IDs
>Date: Wed, 25 Feb 2004 17:51:54 -0000
>X-Mailer: Microsoft Outlook Express 6.00.2800.1158
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
>X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_01,RCVD_IN_SORBS
>         autolearn=no version=2.63
>Sender: [email-masked]
>X-PMX-Version: 4.1.1.86173
>X-from-outside-Cisco: 128.107.250.144
>
>All,
>
>A few IDs got submitted and ack'd before the deadline but seem not to have 
>made it to the
>repository.
>
>draft-ietf-ccamp-gmpls-tc-mib-04.txt
>draft-ietf-ccamp-gmpls-lsr-mib-04.txt
>draft-vasseur-ccamp-loose-path-reopt-00.txt
>draft-vasseur-ccamp-isis-te-caps-00.txt
>
>You can find them at http://www.olddog.co.uk/missing.htm
>
>Cheers,
>Adrian

Delivery-date: Fri, 27 Feb 2004 14:35:11 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: On line agenda
Date: Fri, 27 Feb 2004 14:31:41 +0000

URL fixed. Sorry. 

http://www.olddog.co.uk/ccamp-agenda.htm 

Adrian 

PS Where are all the slides?
I am serious about no slides == no agenda slot
Deadline is close of business Tuesday.

Delivery-date: Fri, 27 Feb 2004 00:57:58 +0000
From: "Vishal Sharma" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "George Newsome" <[email-masked]>, <[email-masked]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 16:56:43 -0800

Hi Deborah,

Thanks for your thoughts.

-- I have just sent an email to George and the list, providing the
complete set of documents that systematically discuss different
aspects of this work.

Since some of the latest versions of the drafts were in the list
of "missing IDs", I think you may not had time to see them yet.
So, please look over the note to the list, and read through the
latest versions of some of the documents, as they will clarify
several of the points. 

(We have, for instance, discussed both misconnections and the issue 
of network stability. The experimental draft referred to in my email 
to the list will also be quite useful for future discussions.)

-- For example, it appears from your note below that there is a
considerable difference between your understanding of FNP and how
it actually works.

In reality, FNP employs a very carefully coordinated use of the 
protection path. (It turns out that the coordination is largely 
accomplished during path setup itself.) 
This might also explain your suggestion that "FNP guarantees user 
traffic will be misconnected," which quite obviously is not a 
goal of FNP! :-)

Also, just to clarify again, this work is not proposing that 
this be _the_ way to perform notification. Rather it is _a_ scheme to 
do so, that is particularly applicable under restoration 
time-constraints (because that is what it is designed for).

In this, it is v. complementary to the other approaches to the
notification and activation task, including the signaling approach
highlighted by the DT.

-- Obviously, we are well aware of the importance of misconnections,
and have considered it in several of the new documents (the
requirements drafts, and the revised expedited flooding draft).
We are also contemplating a squelching functionality, based on
suggestions received from other colleagues, that would enhance
the solutions/proposals we already have for this.

Again, if you will be at Seoul, we will be glad to sit down with
you and continue our discussions from Minneapolis. Hopefully, we
will be able to explain again the operation and purpose of this
scheme, and get other inputs.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Thursday, February 26, 2004 1:32 PM
> To: George Newsome; [email-masked]
> Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
> 
> 
> George,
> 
> Good to see your attention is activated;-)
> 
> I've been discussing privately with the authors my concerns over 
> the last several meetings.
> 
> The fatal negative with the FNP approach is that the use of the 
> protection path is not coordinated - no handshake between the two 
> ends (and intermediate nodes) for use of the protection path. 
> "All nodes notified of the failure will activate the recovery 
> path by performing the required hardware reconfiguration". And 
> the ingress node starts sending user traffic after an elapsed 
> time window. This uncoordinated use of the protection path 
> guarantees user traffic will be misconnected - unacceptable for 
> an operator.
> 
> The key requirement in the P&R DT work was that misconnections 
> are not allowed, and is why the DT's approach uses coordinated 
> signaling to notify all nodes along the path. The DT's approach 
> is referred in this draft as incurring "lengthy delay" vs. FNP.
> 
> Another draft for your attention is 
> draft-rabbat-optical-recovery-reqs. Requirement 8 states "A 
> recovery scheme SHOULD make sure that recovery actions correctly 
> move traffic from failed paths to their respective recovery 
> paths, such that the recovery actions do not result in long-term 
> misconnections". This requirement needs to be reworded to "SHALL" 
> and "long-term misconnections" to "any misconnections".
> 
> Deborah
>  
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of George Newsome
> Sent: Tuesday, February 24, 2004 8:41 PM
> To: [email-masked]
> Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
> 
> 
> All,
> 
> My attention was drawn to
> draft-rabbat-fault-notification-protocol-04.txt, which provokes the
> following comments.
> 
> 1) There seems to be some notion that the time taken to restore is a
> crucial element of high availability, yet overall availability is
> controlled by unprotected elements failure rate and by mean time to
> repair, rather than by switching time. (A 1 second switch is less
> 1/10000 of the generally accepted MTTR of 4 hrs)
> 
> 2) This draft seems to address the relatively simple problem of setting
> up the restoration path. It seems to completely ignore the much harder
> problem of allocating resources to the shared restoration path, and of
> actually locating the fault in an optical network to a single span in a
> time that is useful to restoration. It makes no mention of the
> inaccuracies in network planning databases, which make one wonder
> whether precomputation of restoration paths will actually lead to faster
> restoration times. Finally, it seems to presuppose that a network
> operator would make such a facilities database available to route
> computation at all. The suggestion in sect 6.2 that the physical length
> of the fibers be available for route computation is very unlikely in any
> network I have ever worked on.
> 
> 3) One must wonder whether a flooding approach is actually best anyway. 
> The assumption seems to be that a flooding protocol PDU can be forced 
> onto the front of the send queue, thereby incurring minimum delay. An 
> additional assumption seems to be that there is only one fault in the 
> network, and all bets are off if that is not true. There seem to be 
> problems with both these assumptions. It seems to me that there are no 
> mechanisms for truncating the PDU that is being sent, so there is a 
> finite chance that a significant extra delay is incurred. Perhaps more 
> serious is the assumption that all bets are off if there are multiple 
> faults in the network. In general, multiple faults are those that lead 
> to service outage. Two faults that do not interact, in that they do not 
> contend for the same network resources, will be coupled by the flooding. 
> In addition, unsupressed restoration requests, which occur  when the 
> fault cannot be rapidly located to a single span, will also generate 
> restoration messages. It also seems to me that routing changes may well 
> start to be flooded at the same time scale as restoration activity is 
> taking place. There is no mention of possible interactions with this.
> 
> 4) Assuming that this problem is worth solving, and that a flooding 
> protocol is the best solution, is it a good idea to generate  yet 
> another protocol that floods, and is LMP the vehicle of choice to embed 
> yet another protocol? It seems to me that restoration has a strong 
> interaction with routing change announcment, so it seems to me to make 
> more sense to use those mechanisms rather than invent new ones.
> 
> 5) Until the effect of network database inaccuracies on the 
> effectiveness of  precomputed restoration is better understood, the 
> problem of allocating  resources in shared mesh networks is solved, and 
> it is certain that all faults will be located to the correct span in a 
> time useful to restoration, it seems to be premature to be proposing a 
> solution to the final piece of the problem.
> 
> 
> Regards
> 
> 	George
> 
> 
> 

Delivery-date: Fri, 27 Feb 2004 00:21:59 +0000
From: "Vishal Sharma" <[email-masked]>
To: "George Newsome" <[email-masked]>, <[email-masked]>
Cc: "Richard Rabbat" <[email-masked]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 16:20:41 -0800

Hi George,

Thanks for your interest in this work.

However, before we can have a meaningful discussion on the subject,
I think it is important that you read through the complete set
of drafts that are related to notification.

You will find that a majority of your questions are already
considered in these documents.
(Those that remain are not specific to this approach, and will
come up in any restoration scheme, so they will have to be addressed
in a general way regardless.)

I would highly recommend that you also look at the proceedings from
the Yokohama, San Fransisco, Vienna, and Minneapolis IETF's, as some of the
presentations/discussions at these CCAMP meetings are v. useful to
more fully understand this work.

Once you've done that, we will be ready to discuss further details.
(If you're going to be at Seoul, we can always clarify things
in person, it's a bit easier with a pen and paper handy.)

BTW, these documents are actually the result of numerous fruitful
discussions at several IETF meetings and on-line (cf. mailing list
archives from 2003) and form a logical sequence that sets the right
context for this work and takes one systematically through it.

Just to help you (and others who are interested in this work),
here is the recommended sequence.

i) There is a basic requirements draft that highlights requirements for
control-plane based recovery of data-plane failures in optical transport
networks.
(This was the result of a request from the CCAMP Chairs, way back
in Yokohama 2002, to have a document that collates requirements. It has
actually been refined several times, and for the last two times was
republished with a different name, thus an 01 version.)

Optical Transport Network Failure Recovery Requirements
http://www.ietf.org/internet-drafts/draft-rabbat-optical-recovery-reqs-01.tx
t

ii) This is followed by a more in-depth document, that is implementation
agnostic, and that discusses very meticulously both signaling and
flooding solutions. It then details requirements for time-bounded
notification in optical transport networks, and the need for an expedited
flooding mechanism to do so.

Expedited Flooding for Restoration in Shared-Mesh Transport Networks
http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-01.txt

It also talks of multiple failures and ways to handle them.

(I think it is important to mention here that the proposal makes clear
that both flooding and signaling have a role, and does not exclude either
as a way of doing notification and recovery path activation.)

iii) There is then the _protocol-agnostic_ specification of a flooding-based
solution to the time-bounded notification problem

Fault Notification Protocol for GMPLS-Based Recovery
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol
-04.txt

Just to re-iterate, this draft only lays out protocol operation and required
messaging and formats, and does not mandate (by design) any specific
implementation of FNP.

Several protocols can be used for this, and this is reflected in the
experimental draft next, which highlights two ways of implementing flooding,
at the two network layers of interest.

iv) There is then an experimental track document, which I believe is
extremely useful, because it presents real results and experiences from
two independent testbed implementations of flooding for fault notification.
It also provides the protocol enhancements that the implementors made
to LMP and OSPF-TE to realize the flooding function, and has an excellent
discussion of many issues.

(It was the direct product of many discussions at Minneapolis, where it
was suggested that these experiences and results be shared with the IETF
community under an experimental track doc.)

Implementation and Performance of Flooding-based Fault Notification
http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-perf-flooding-notific
ation-exp-00.txt

v) Finally, there is a draft that discusses the applicability of
FNP in the context of optical transport networks. This was done to
address, in one place, questions about the network, fault, etc. model
to which FNP applies, which we addressed in many ML discussions last
year.

Observations on the Applicability of the Fault Notification Protocol
http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of George Newsome
> Sent: Tuesday, February 24, 2004 5:41 PM
> To: [email-masked]
> Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
>
>
> All,
>
> My attention was drawn to
> draft-rabbat-fault-notification-protocol-04.txt, which provokes the
> following comments.
>
> 1) There seems to be some notion that the time taken to restore is a
> crucial element of high availability, yet overall availability is
> controlled by unprotected elements failure rate and by mean time to
> repair, rather than by switching time. (A 1 second switch is less
> 1/10000 of the generally accepted MTTR of 4 hrs)
>
> 2) This draft seems to address the relatively simple problem of setting
> up the restoration path. It seems to completely ignore the much harder
> problem of allocating resources to the shared restoration path, and of
> actually locating the fault in an optical network to a single span in a
> time that is useful to restoration. It makes no mention of the
> inaccuracies in network planning databases, which make one wonder
> whether precomputation of restoration paths will actually lead to faster
> restoration times. Finally, it seems to presuppose that a network
> operator would make such a facilities database available to route
> computation at all. The suggestion in sect 6.2 that the physical length
> of the fibers be available for route computation is very unlikely in any
> network I have ever worked on.
>
> 3) One must wonder whether a flooding approach is actually best anyway.
> The assumption seems to be that a flooding protocol PDU can be forced
> onto the front of the send queue, thereby incurring minimum delay. An
> additional assumption seems to be that there is only one fault in the
> network, and all bets are off if that is not true. There seem to be
> problems with both these assumptions. It seems to me that there are no
> mechanisms for truncating the PDU that is being sent, so there is a
> finite chance that a significant extra delay is incurred. Perhaps more
> serious is the assumption that all bets are off if there are multiple
> faults in the network. In general, multiple faults are those that lead
> to service outage. Two faults that do not interact, in that they do not
> contend for the same network resources, will be coupled by the flooding.
> In addition, unsupressed restoration requests, which occur  when the
> fault cannot be rapidly located to a single span, will also generate
> restoration messages. It also seems to me that routing changes may well
> start to be flooded at the same time scale as restoration activity is
> taking place. There is no mention of possible interactions with this.
>
> 4) Assuming that this problem is worth solving, and that a flooding
> protocol is the best solution, is it a good idea to generate  yet
> another protocol that floods, and is LMP the vehicle of choice to embed
> yet another protocol? It seems to me that restoration has a strong
> interaction with routing change announcment, so it seems to me to make
> more sense to use those mechanisms rather than invent new ones.
>
> 5) Until the effect of network database inaccuracies on the
> effectiveness of  precomputed restoration is better understood, the
> problem of allocating  resources in shared mesh networks is solved, and
> it is certain that all faults will be located to the correct span in a
> time useful to restoration, it seems to be premature to be proposing a
> solution to the final piece of the problem.
>
>
> Regards
>
> 	George
>
>

Delivery-date: Thu, 26 Feb 2004 21:33:10 +0000
content-class: urn:content-classes:message
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 15:31:44 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "George Newsome" <[email-masked]>, <[email-masked]>

George,

Good to see your attention is activated;-)

I've been discussing privately with the authors my concerns over the =
last several meetings.

The fatal negative with the FNP approach is that the use of the =
protection path is not coordinated - no handshake between the two ends =
(and intermediate nodes) for use of the protection path. "All nodes =
notified of the failure will activate the recovery path by performing =
the required hardware reconfiguration". And the ingress node starts =
sending user traffic after an elapsed time window. This uncoordinated =
use of the protection path guarantees user traffic will be misconnected =
- unacceptable for an operator.

The key requirement in the P&R DT work was that misconnections are not =
allowed, and is why the DT's approach uses coordinated signaling to =
notify all nodes along the path. The DT's approach is referred in this =
draft as incurring "lengthy delay" vs. FNP.

Another draft for your attention is draft-rabbat-optical-recovery-reqs. =
Requirement 8 states "A recovery scheme SHOULD make sure that recovery =
actions correctly move traffic from failed paths to their respective =
recovery paths, such that the recovery actions do not result in =
long-term misconnections". This requirement needs to be reworded to =
"SHALL" and "long-term misconnections" to "any misconnections".

Deborah
=20
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of George Newsome
Sent: Tuesday, February 24, 2004 8:41 PM
To: [email-masked]
Subject: Re: draft-rabbat-fault-notification-protocol-04.txt

All,

My attention was drawn to
draft-rabbat-fault-notification-protocol-04.txt, which provokes the
following comments.

1) There seems to be some notion that the time taken to restore is a
crucial element of high availability, yet overall availability is
controlled by unprotected elements failure rate and by mean time to
repair, rather than by switching time. (A 1 second switch is less
1/10000 of the generally accepted MTTR of 4 hrs)

2) This draft seems to address the relatively simple problem of setting
up the restoration path. It seems to completely ignore the much harder
problem of allocating resources to the shared restoration path, and of
actually locating the fault in an optical network to a single span in a
time that is useful to restoration. It makes no mention of the
inaccuracies in network planning databases, which make one wonder
whether precomputation of restoration paths will actually lead to faster
restoration times. Finally, it seems to presuppose that a network
operator would make such a facilities database available to route
computation at all. The suggestion in sect 6.2 that the physical length
of the fibers be available for route computation is very unlikely in any
network I have ever worked on.

3) One must wonder whether a flooding approach is actually best anyway.=20
The assumption seems to be that a flooding protocol PDU can be forced=20
onto the front of the send queue, thereby incurring minimum delay. An=20
additional assumption seems to be that there is only one fault in the=20
network, and all bets are off if that is not true. There seem to be=20
problems with both these assumptions. It seems to me that there are no=20
mechanisms for truncating the PDU that is being sent, so there is a=20
finite chance that a significant extra delay is incurred. Perhaps more=20
serious is the assumption that all bets are off if there are multiple=20
faults in the network. In general, multiple faults are those that lead=20
to service outage. Two faults that do not interact, in that they do not=20
contend for the same network resources, will be coupled by the flooding. =

In addition, unsupressed restoration requests, which occur  when the=20
fault cannot be rapidly located to a single span, will also generate=20
restoration messages. It also seems to me that routing changes may well=20
start to be flooded at the same time scale as restoration activity is=20
taking place. There is no mention of possible interactions with this.

4) Assuming that this problem is worth solving, and that a flooding=20
protocol is the best solution, is it a good idea to generate  yet=20
another protocol that floods, and is LMP the vehicle of choice to embed=20
yet another protocol? It seems to me that restoration has a strong=20
interaction with routing change announcment, so it seems to me to make=20
more sense to use those mechanisms rather than invent new ones.

5) Until the effect of network database inaccuracies on the=20
effectiveness of  precomputed restoration is better understood, the=20
problem of allocating  resources in shared mesh networks is solved, and=20
it is certain that all faults will be located to the correct span in a=20
time useful to restoration, it seems to be premature to be proposing a=20
solution to the final piece of the problem.

Regards

	George

Delivery-date: Thu, 26 Feb 2004 13:49:46 +0000
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
From: [email-masked]
Date: Thu, 26 Feb 2004 14:48:03 +0100

When being made aware of this draft, I couldn't help to remember the large 
amount of correspondence we had in 2001 on 
draft-mannie-ccamp-gmpls-lbm-tdm (GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH). Refer to http://ops.ietf.org/lists/ccamp/ccamp.2001/.

Virtual concatenation's first application was to get around the problem 
SDH networks at that moment had to transport VC-4-4c signals that the ATM 
people were using in their STM-4 (OC-12) interfaces. The first generation 
SDH/SONET HO networks supported VC-4 and STS-1/STS-3c connections, and 
were not capable to support VC-4-Xc. With many 2nd generation SDH networks 
around these days that support VC-4-Xc (X=4,16,64) the original need is 
not so recognised anylonger. 

Today virtual concatenation (VC-n-Xv, n=4,3,12,11) is associated with a 
finer connection bandwidth granularity in the SDH transport networks. This 
is most important today for the Ethernet and SAN private line services. 
Soon after this etherent private line application was identified, people 
started to consider the development of a means to hitless 
increase/decrease the EPL's connection bandwidth. LCAS was born... and 
once under development it became obvious that LCAS could do more than just 
hitless inc/dec of connection bandwidth... i.e. it could bring 
survivability to the EPL, such that the connection could still be alive 
when a subset of the VC-n connections failed (but with reduced bandwidth).

So today it is assumed that an EPL connection gets at least 50% of its 
VC-n's routed via one route and the other 50% via an other - diverse - 
route.

Example:

==> Call Request for EPL of 10 Mbit/s, 
    with survivable bandwidth of 60%

==> EPL ingress/egress ports on the network
    support VC-12 based VCAT with Xmax = 10.

==> Network Call Controller (NCC) or NMS concludes
    that a VC-12-6v is required, of which 3 VC-12s
    are routed between X and Y via via nodes A-B-C-D
    (route 1) an the other 3 VC-12s are routed via
    E-F-G (route 2).

==> NCC (?) or NMS configures both X and Y 
    endpoints for VC-12-6v (refer to 10.1/G.806 (01/2004)
    and 12.5.3/G.783 (01/2004) for details). The LCAS processes
    at X and Y are now waiting for the 6 VC-12 endpoints to
    clear their Signal Fail condition. Once SF clears after 
    VC-12 connection is setup, LCAS will kick in and will
    coordinate between X and Y the moment that the 
    VC-12 paylaod bandwidth will be taken into service 
    in the EPL connection.

==> NCC (?) or NMS will configure the ETH
    traffic conditioning function (refer to G.8010) with
    the appropriate parameters; e.g. bandwidth of 10M.

==> Connection Controller creates two groups of 3 VC-12
    connections (trails) between X and Y.

==> if EPL bandwidth is to be increased at a later time
    to e.g. 16 Mbit/s with 60% survivability, then a
    VC-12-10v would be required of which 5 VC-12's should
    go via route 1 and the other 5 via route 2.

==> the NCC (?) or NMS configures the
    two X and Y endpoints of the EPL for VC-12-10v
    and orders the Connection controller to extend
    the two groups of 3 VC-12 connections to two
    groups of 5 VC-12 connections.

==> also the ETH traffic conditioning function is to
    be reconfigured; now it should allow 16M.

==> once one fo the 4 additional VC-12 connections is setup,
    the LCAS processes in the two endpoitns X and Y will add the
    its associated paylaod bandwidth to the EPL bandwidth.

Summary: The creation or modification of an EPL requires
to configure the atomic functions (see G.783/G.806) in 
the "EPL ports" at the two endpoints and typically the setup 
of two or more groups of diversely routed VC-n connections (trails).

You state:
> My point in the draft is to enough apply the advantages
> of the GMPLS signaling protocol in order to simplify
> the LCAS operations.

I hope it has become clear that LCAS operation is independent
of GMPLS signalling protocol and GMPLS can't simplify it.
LCAS is a data plane protocol which informs a receiver (sink)
about the exact bit position when it should start (or stop)
reading bits from the payload of a VC-n signal. As such it 
synchronises a receiver with its upstream transmitter.

Note: LCAS only works when there is a bidirectional connection 
present. Nevertheless, LCAS takes the payload bandwidth 
of a VC-n for each direction independent into service. 

It will be common that two EPL ports have different XMT 
(see 10.1/G.806) values; e.g. one port has 10 VC-12 
termination functions, whereas the other port has 
15 VC-12 termination functions. This is independent of
LCAS, it is VCAT related. 

VCAT ports may appear in different architectures: 
A) a dedicated group of XMT VC-n termination functions per port
B) a shared group of N VC-n termination functions for M ports;
   N <= XMT_1 + XMT_2 + .. + XMT_M

If two ports X and Y are to be connected, four situations are possible:
1) X: A-type port with XMT=i,
   Y: A-type port with XMT=j
2) X: A-Type port with XMT=i
   Y: B-type port with XMT_Y=j and N = ...
3) X: B-type port with XMT_X=i and N = ...
   Y: A-Type port with XMT=j
4) X: B-type port with XMT_X=i and N = ...
   Y: B-type port with XMT_Y=j and N = ...

If i and j are not equal then a VCAT connection setup
is limited to min(i,j).

If i and j are equal and one or both ports are B-type ports,
then a VCAT connection adjustment (bandwidth increase)
may fail if all N VC-n termination functions are already
in use by the M ports. I.e. N < XMT_1 + .. + XMT_M.

For the case there is no higher authority that is aware of the
particular XMT and N values of the two ports, or if this
information isn't shared after a VCAT connection is
created, then a request to increase the bandwidth of the
VCAT connection may fail under the above conditions.
But again, this has nothing to do with LCAS.

Up to so far.

Regards,
Maarten
PS. Appendix VII/G.806 01/2004 provides "Examples for the operation 
of the processes within LCAS-capable adaptation functions". Reading
is recommended.

---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:[email-masked]

[email-masked]
Sent by: [email-masked]
26-02-2004 04:51

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt

Please, see in-line comments. 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> All, 
> My attention was drawn to 
> draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the 
> following comments. 
> 1) It is not clear to me why there should be any interaction between 
> connections being provided for the purpose of Virtual Concatenation 
> (VCAT) and connections being used for any other purpose. The existence 
> of VCAT is invisible within the network, and should also be invisible to 

> the connection protocol. 
> You are quite right when you point out that its perhaps a good idea to 
> identically route each leg, and explicit routing seems to meet that 
> need. However, when the goal of VCAT and LCAS is diversity and graceful 
> degradation, identical routing of each leg is useless. In this case, 
> there is no other solution than treating each leg as an independent 
> connection request. That being the case, each leg should always be 
> treated as an independent connection request, and there can be no single 

> end to end session associated with that set of connections. 
My draft does not handle VCAT at all. In reference, as described in 
G.7042,  the goal (maybe use) of LCAS is to 
to increase or decrease the capacity of a container that is transported in 
an SDH/OTN network using Virtual Concatenation..
I couldn't find a word in G.7042 that the goal of VCAT and LCAS  is 
diversity and graceful and graceful degradation. 
I think your goal of VCAT and LCAS may be a small usage example for 
diversity and graceful and graceful degradation, 
but, it is not the goal of VCAT and LCAS. As most of people know, VCAT and 
LCAS are ones of key factors for EoS. 
What do you think of the goal of EoS. I think VCAT and LCAS are factors 
for supporting the EoS. 
> 2) The entity that actually controls LCAS is an application; in 
> particular it is the application that takes the request for a particular 

> capacity and translates that request in a set of connection requests. In 

> ITU parlance, that is call processing. As you say, that application can 
> run on either a network element or a Management System. As connections 
> can be set up bi-directionally, bi-directional operation of the VCAT 
> group is a function of call processing; not of the individual connection 

> requests. 
> 3) LCAS and VCAT groups provide a vivid illustration of the separation 
> of call processing from connection signaling. As VCAT groups will be 
> operated for many different purposes, including diverse routing for 
> graceful degradation, it is not possible to burden the signaling 
> protocol with LCAS management as there are many signaling sessions - one 

> for each leg of the VCAT group. 
> It therefore seems incorrect to consider adding VCAT/LCAS details into 
> the connection protocol. 
> Regards 
>           George 
I think I couldn't still find the traditional or original separation of 
call processing and connection signaling in IETF.
In addition, there might be a complicated mechanism for the pure 
separation of call processing and connection. 
For call processing, a signaling protocol has to identify the 
characteristics of end users which are calling and called parties. 
However, there is no concept in the current signaling protocols. 
If you insist upon it, I think that LCAS and RSVP-TE are protocols for 
connection control because these are run 
on connection resources. 
In any case, the separation of call processing and connection is out of 
scope in my draft. 
My point in the draft is to enough apply the advantages of the GMPLS 
signaling protocol in order to simplify the LCAS operations.
I think whether my draft is valid or not depends on the possibility of 
bidirectionality on the same route. 
I'm looking for supporters and also reviewing by myself for this part. 
Also, I think my draft has in current no detail about LCAS/VCAT except for 
the information for LCAS operation indication 
and response(a single bit representation for the indication and error 
codes for the response) in case of LCAS. 
If you want other references for my draft, please see the following 
papers. 
- Generic Framing Procedure (GFP): The Catalyst for Efficient Data over 
Transport,  IEEE Comm. Mag. May 2002., pp 72 ~ pp79.
- Next Transport Service for Next-Generation SONET/SDH Systems, IEEE Comm. 
Mag. May 2002., pp 80 ~ pp87. 

Delivery-date: Thu, 26 Feb 2004 03:50:17 +0000
From: [email-masked]
To: [email-masked], [email-masked]
Subject: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Thu, 26 Feb 2004 12:51:02 +0900

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_001_01C3FC1B.C095F338
Content-Type: text/plain;
	charset="euc-kr"

Please, see in-line comments.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> All,
> My attention was drawn to 
> draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the 
> following comments.
> 1) It is not clear to me why there should be any interaction between 
> connections being provided for the purpose of Virtual Concatenation 
> (VCAT) and connections being used for any other purpose. The existence 
> of VCAT is invisible within the network, and should also be invisible to 
> the connection protocol.
> You are quite right when you point out that its perhaps a good idea to 
> identically route each leg, and explicit routing seems to meet that 
> need. However, when the goal of VCAT and LCAS is diversity and graceful 
> degradation, identical routing of each leg is useless. In this case, 
> there is no other solution than treating each leg as an independent 
> connection request. That being the case, each leg should always be 
> treated as an independent connection request, and there can be no single 
> end to end session associated with that set of connections.

My draft does not handle VCAT at all. In reference, as described in G.7042,
the goal (maybe use) of LCAS is to
to increase or decrease the capacity of a container that is transported in
an SDH/OTN network using Virtual Concatenation..
I couldn't find a word in G.7042 that the goal of VCAT and LCAS  is
diversity and graceful and graceful degradation.
I think your goal of VCAT and LCAS may be a small usage example for
diversity and graceful and graceful degradation, 
but, it is not the goal of VCAT and LCAS. As most of people know, VCAT and
LCAS are ones of key factors for EoS.
What do you think of the goal of EoS. I think VCAT and LCAS are factors for
supporting the EoS.

> 2) The entity that actually controls LCAS is an application; in 
> particular it is the application that takes the request for a particular 
> capacity and translates that request in a set of connection requests. In 
> ITU parlance, that is call processing. As you say, that application can 
> run on either a network element or a Management System. As connections 
> can be set up bi-directionally, bi-directional operation of the VCAT 
> group is a function of call processing; not of the individual connection 
> requests.

> 3) LCAS and VCAT groups provide a vivid illustration of the separation 
> of call processing from connection signaling. As VCAT groups will be 
> operated for many different purposes, including diverse routing for 
> graceful degradation, it is not possible to burden the signaling 
> protocol with LCAS management as there are many signaling sessions - one 
> for each leg of the VCAT group.
> It therefore seems incorrect to consider adding VCAT/LCAS details into 
> the connection protocol.
> Regards
> 	    George

I think I couldn't still find the traditional or original separation of
call processing and connection signaling in IETF.
In addition, there might be a complicated mechanism for the pure separation
of call processing and connection.
For call processing, a signaling protocol has to identify the
characteristics of end users which are calling and called parties. 
However, there is no concept in the current signaling protocols.
If you insist upon it, I think that LCAS and RSVP-TE are protocols for
connection control because these are run 
on connection resources.
In any case, the separation of call processing and connection is out of
scope in my draft.
My point in the draft is to enough apply the advantages of the GMPLS
signaling protocol in order to simplify the LCAS operations.
I think whether my draft is valid or not depends on the possibility of
bidirectionality on the same route.
I'm looking for supporters and also reviewing by myself for this part.
Also, I think my draft has in current no detail about LCAS/VCAT except for
the information for LCAS operation indication 
and response(a single bit representation for the indication and error codes
for the response) in case of LCAS.
If you want other references for my draft, please see the following papers.

- Generic Framing Procedure (GFP): The Catalyst for Efficient Data over
Transport,  IEEE Comm. Mag. May 2002., pp 72 ~ pp79.
- Next Transport Service for Next-Generation SONET/SDH Systems, IEEE Comm.
Mag. May 2002., pp 80 ~ pp87.

------_=_NextPart_001_01C3FC1B.C095F338
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please, see in-line comments.</FONT>
</P>

<P><FONT =
SIZE=3D2>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++++</FONT>
</P>

<P><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; My attention was drawn to </FONT>
<BR><FONT SIZE=3D2>&gt; =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the =
</FONT>
<BR><FONT SIZE=3D2>&gt; following comments.</FONT>
<BR><FONT SIZE=3D2>&gt; 1) It is not clear to me why there should be =
any interaction between </FONT>
<BR><FONT SIZE=3D2>&gt; connections being provided for the purpose of =
Virtual Concatenation </FONT>
<BR><FONT SIZE=3D2>&gt; (VCAT) and connections being used for any other =
purpose. The existence </FONT>
<BR><FONT SIZE=3D2>&gt; of VCAT is invisible within the network, and =
should also be invisible to </FONT>
<BR><FONT SIZE=3D2>&gt; the connection protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; You are quite right when you point out that its =
perhaps a good idea to </FONT>
<BR><FONT SIZE=3D2>&gt; identically route each leg, and explicit =
routing seems to meet that </FONT>
<BR><FONT SIZE=3D2>&gt; need. However, when the goal of VCAT and LCAS =
is diversity and graceful </FONT>
<BR><FONT SIZE=3D2>&gt; degradation, identical routing of each leg is =
useless. In this case, </FONT>
<BR><FONT SIZE=3D2>&gt; there is no other solution than treating each =
leg as an independent </FONT>
<BR><FONT SIZE=3D2>&gt; connection request. That being the case, each =
leg should always be </FONT>
<BR><FONT SIZE=3D2>&gt; treated as an independent connection request, =
and there can be no single </FONT>
<BR><FONT SIZE=3D2>&gt; end to end session associated with that set of =
connections.</FONT>
</P>

<P><FONT SIZE=3D2>My draft does not handle VCAT at all. In reference, =
as described in G.7042,&nbsp; the goal (maybe use) of LCAS is to</FONT>
<BR><FONT SIZE=3D2>to increase or decrease the capacity of a container =
that is transported in an SDH/OTN network using Virtual =
Concatenation..</FONT></P>

<P><FONT SIZE=3D2>I couldn't find a word in G.7042 that the goal of =
VCAT and LCAS&nbsp; is diversity and graceful and graceful =
degradation.</FONT>
<BR><FONT SIZE=3D2>I think your goal of VCAT and LCAS may be a small =
usage example for diversity and graceful and graceful degradation, =
</FONT>
<BR><FONT SIZE=3D2>but, it is not the goal of VCAT and LCAS. As most of =
people know, VCAT and LCAS are ones of key factors for EoS.</FONT>
<BR><FONT SIZE=3D2>What do you think of the goal of EoS. I think VCAT =
and LCAS are factors for supporting the EoS.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 2) The entity that actually controls LCAS is an =
application; in </FONT>
<BR><FONT SIZE=3D2>&gt; particular it is the application that takes the =
request for a particular </FONT>
<BR><FONT SIZE=3D2>&gt; capacity and translates that request in a set =
of connection requests. In </FONT>
<BR><FONT SIZE=3D2>&gt; ITU parlance, that is call processing. As you =
say, that application can </FONT>
<BR><FONT SIZE=3D2>&gt; run on either a network element or a Management =
System. As connections </FONT>
<BR><FONT SIZE=3D2>&gt; can be set up bi-directionally, bi-directional =
operation of the VCAT </FONT>
<BR><FONT SIZE=3D2>&gt; group is a function of call processing; not of =
the individual connection </FONT>
<BR><FONT SIZE=3D2>&gt; requests.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 3) LCAS and VCAT groups provide a vivid =
illustration of the separation </FONT>
<BR><FONT SIZE=3D2>&gt; of call processing from connection signaling. =
As VCAT groups will be </FONT>
<BR><FONT SIZE=3D2>&gt; operated for many different purposes, including =
diverse routing for </FONT>
<BR><FONT SIZE=3D2>&gt; graceful degradation, it is not possible to =
burden the signaling </FONT>
<BR><FONT SIZE=3D2>&gt; protocol with LCAS management as there are many =
signaling sessions - one </FONT>
<BR><FONT SIZE=3D2>&gt; for each leg of the VCAT group.</FONT>
<BR><FONT SIZE=3D2>&gt; It therefore seems incorrect to consider adding =
VCAT/LCAS details into </FONT>
<BR><FONT SIZE=3D2>&gt; the connection protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; George</FONT>
</P>

<P><FONT SIZE=3D2>I think I couldn't still find the traditional or =
original separation of call processing and connection signaling in =
IETF.</FONT></P>

<P><FONT SIZE=3D2>In addition, there might be a complicated mechanism =
for the pure separation of call processing and connection.</FONT>
<BR><FONT SIZE=3D2>For call processing, a signaling protocol has to =
identify the characteristics of end users which are calling and called =
parties. </FONT></P>

<P><FONT SIZE=3D2>However, there is no concept in the current signaling =
protocols.</FONT>
<BR><FONT SIZE=3D2>If you insist upon it, I think that LCAS and RSVP-TE =
are protocols for connection control because these are run </FONT>
<BR><FONT SIZE=3D2>on connection resources.</FONT>
<BR><FONT SIZE=3D2>In any case, the separation of call processing and =
connection is out of scope in my draft.</FONT>
<BR><FONT SIZE=3D2>My point in the draft is to enough apply the =
advantages of the GMPLS signaling protocol in order to simplify the =
LCAS operations.</FONT></P>

<P><FONT SIZE=3D2>I think whether my draft is valid or not depends on =
the possibility of bidirectionality on the same route.</FONT>
<BR><FONT SIZE=3D2>I'm looking for supporters and also reviewing by =
myself for this part.</FONT>
<BR><FONT SIZE=3D2>Also, I think my draft has in current no detail =
about LCAS/VCAT except for the information for LCAS operation =
indication </FONT></P>

<P><FONT SIZE=3D2>and response(a single bit representation for the =
indication and error codes for the response) in case of LCAS.</FONT>
<BR><FONT SIZE=3D2>If you want other references for my draft, please =
see the following papers.</FONT>
</P>

<P><FONT SIZE=3D2>- Generic Framing Procedure (GFP): The Catalyst for =
Efficient Data over Transport,&nbsp; IEEE Comm. Mag. May 2002., pp 72 ~ =
pp79.</FONT></P>

<P><FONT SIZE=3D2>- Next Transport Service for Next-Generation =
SONET/SDH Systems, IEEE Comm. Mag. May 2002., pp 80 ~ pp87.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FC1B.C095F338--

Delivery-date: Wed, 25 Feb 2004 18:43:26 +0000
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Missing IDs
Date: Wed, 25 Feb 2004 13:42:47 -0500
Organization: Cisco Systems, inc.

	Not again. We had this same problem during
the last I-D cut-off. Can the Ads/chairs get in touch
with the I-D editor folks to check this out?
Last time there was some general issue with the
repository server that no one seemed to notice
until after the meeting.

	--Tom

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, February 25, 2004 12:52 PM
> To: [email-masked]
> Subject: Missing IDs
> 
> 
> All,
> 
> A few IDs got submitted and ack'd before the deadline but 
> seem not to have made it to the
> repository.
> 
> draft-ietf-ccamp-gmpls-tc-mib-04.txt
> draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> draft-vasseur-ccamp-loose-path-reopt-00.txt
> draft-vasseur-ccamp-isis-te-caps-00.txt
> 
> You can find them at http://www.olddog.co.uk/missing.htm
> 
> Cheers,
> Adrian
> 
> 
> 

Delivery-date: Wed, 25 Feb 2004 18:24:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda on line
Date: Wed, 25 Feb 2004 18:20:30 -0000

http://www.olddog.co.uk/ccamp-agenda.htm contains a friendly html agenda with links to the
drafts that will be discussed.

As slides reach me I will also add them in.

Please take this as a reminder to send me your slides!

Thanks,
Adrian

Delivery-date: Wed, 25 Feb 2004 17:57:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Missing IDs
Date: Wed, 25 Feb 2004 17:51:54 -0000

All,

A few IDs got submitted and ack'd before the deadline but seem not to have made it to the
repository.

draft-ietf-ccamp-gmpls-tc-mib-04.txt
draft-ietf-ccamp-gmpls-lsr-mib-04.txt
draft-vasseur-ccamp-loose-path-reopt-00.txt
draft-vasseur-ccamp-isis-te-caps-00.txt

You can find them at http://www.olddog.co.uk/missing.htm

Cheers,
Adrian

Delivery-date: Wed, 25 Feb 2004 16:20:24 +0000
Date: Wed, 25 Feb 2004 11:18:09 -0500
From: George Newsome <[email-masked]>
To: [email-masked]
Subject: Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt

All,

My attention was drawn to
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the
following comments.

1) It is not clear to me why there should be any interaction between
connections being provided for the purpose of Virtual Concatenation
(VCAT) and connections being used for any other purpose. The existence
of VCAT is invisible within the network, and should also be invisible to
the connection protocol.

You are quite right when you point out that its perhaps a good idea to
identically route each leg, and explicit routing seems to meet that
need. However, when the goal of VCAT and LCAS is diversity and graceful
degradation, identical routing of each leg is useless. In this case,
there is no other solution than treating each leg as an independent
connection request. That being the case, each leg should always be
treated as an independent connection request, and there can be no single
end to end session associated with that set of connections.

2) The entity that actually controls LCAS is an application; in
particular it is the application that takes the request for a particular
capacity and translates that request in a set of connection requests. In
ITU parlance, that is call processing. As you say, that application can
run on either a network element or a Management System. As connections
can be set up bi-directionally, bi-directional operation of the VCAT
group is a function of call processing; not of the individual connection
requests.

3) LCAS and VCAT groups provide a vivid illustration of the separation
of call processing from connection signaling. As VCAT groups will be
operated for many different purposes, including diverse routing for
graceful degradation, it is not possible to burden the signaling
protocol with LCAS management as there are many signaling sessions - one
for each leg of the VCAT group.

It therefore seems incorrect to consider adding VCAT/LCAS details into
the connection protocol.

Regards

	George

Delivery-date: Wed, 25 Feb 2004 01:42:15 +0000
Date: Tue, 24 Feb 2004 20:40:50 -0500
From: George Newsome <[email-masked]>
To: [email-masked]
Subject: Re: draft-rabbat-fault-notification-protocol-04.txt

All,

My attention was drawn to
draft-rabbat-fault-notification-protocol-04.txt, which provokes the
following comments.

1) There seems to be some notion that the time taken to restore is a
crucial element of high availability, yet overall availability is
controlled by unprotected elements failure rate and by mean time to
repair, rather than by switching time. (A 1 second switch is less
1/10000 of the generally accepted MTTR of 4 hrs)

2) This draft seems to address the relatively simple problem of setting
up the restoration path. It seems to completely ignore the much harder
problem of allocating resources to the shared restoration path, and of
actually locating the fault in an optical network to a single span in a
time that is useful to restoration. It makes no mention of the
inaccuracies in network planning databases, which make one wonder
whether precomputation of restoration paths will actually lead to faster
restoration times. Finally, it seems to presuppose that a network
operator would make such a facilities database available to route
computation at all. The suggestion in sect 6.2 that the physical length
of the fibers be available for route computation is very unlikely in any
network I have ever worked on.

3) One must wonder whether a flooding approach is actually best anyway. 
The assumption seems to be that a flooding protocol PDU can be forced 
onto the front of the send queue, thereby incurring minimum delay. An 
additional assumption seems to be that there is only one fault in the 
network, and all bets are off if that is not true. There seem to be 
problems with both these assumptions. It seems to me that there are no 
mechanisms for truncating the PDU that is being sent, so there is a 
finite chance that a significant extra delay is incurred. Perhaps more 
serious is the assumption that all bets are off if there are multiple 
faults in the network. In general, multiple faults are those that lead 
to service outage. Two faults that do not interact, in that they do not 
contend for the same network resources, will be coupled by the flooding. 
In addition, unsupressed restoration requests, which occur  when the 
fault cannot be rapidly located to a single span, will also generate 
restoration messages. It also seems to me that routing changes may well 
start to be flooded at the same time scale as restoration activity is 
taking place. There is no mention of possible interactions with this.

4) Assuming that this problem is worth solving, and that a flooding 
protocol is the best solution, is it a good idea to generate  yet 
another protocol that floods, and is LMP the vehicle of choice to embed 
yet another protocol? It seems to me that restoration has a strong 
interaction with routing change announcment, so it seems to me to make 
more sense to use those mechanisms rather than invent new ones.

5) Until the effect of network database inaccuracies on the 
effectiveness of  precomputed restoration is better understood, the 
problem of allocating  resources in shared mesh networks is solved, and 
it is certain that all faults will be located to the correct span in a 
time useful to restoration, it seems to be premature to be proposing a 
solution to the final piece of the problem.

Regards

	George

Delivery-date: Tue, 24 Feb 2004 19:40:50 +0000
Date: Tue, 24 Feb 2004 14:38:31 -0500 (EST)
From: Arun Satyanarayana <[email-masked]>
Reply-To: <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: <[email-masked]>, 'Anca Zamfir' <[email-masked]>, <[email-masked]>, Lou Berger <[email-masked]>, <[email-masked]>, <[email-masked]>, Arun Satyanarayan <[email-masked]>
Subject: Re: RSVP Graceful Restart Extensions

Adrian,

The following is the problem space as we see it (this includes GMPLS):

  - Recovery of *full* signaling state on ingress nodes after a restart.

  - Recovery of *full* signaling state transit nodes after a restart. (Egress
    is already covered by existing mechanisms.)

  - Full signaling state includes: dynamically computed objects such as
    ERO/RRO; HOP when forwarding state is not saved across a restart; and any
    other objects including transparently processed objects.

  - Perform all such recovery without perturbing the signaling state on any of
    the other nodes participating in the LSP.

  - Maintaining backwards compatibility:
    - Notably with existing hello mechanisms as defined in rfc3209 and
      rfc3473.

The following parts of the problem space are being addressed in
draft-aruns-ccamp-rsvp-restart-ext-00.txt:

  - Address single node restarts under all conditions including when the
    restarting node is the ingress, and, when the ingress does not save full
    or partial forwarding state across the restart. Note that this does not
    require any signaling state beyond interface configuration to be restored
    after a restart. Also covered is the case where the restarting node
    dynamically adds/computes/changes any objects in the received Path
    message.

  - Achieve recovery without perturbing the signaling state on the remaining
    participating nodes of the LSP.

  - Fully backwards compatible with existing implementations.

We see the following limitations with the alternate solution in
draft-rahman-rsvp-restart-extensions-00.txt:

  - Ingress node restarts are not addressed (or, require some signaling state
    saved across the restart).

  - There could be backward compatibility issues with the change to the Hello
    message contents (Restart Caps object contents, specifically).

  - The change to Hellos, is to address adjaceny node restarts, which is in
    itself limited to two adjacent nodes. Beyond this, the solution is the
    same as in rfc3473. The following example explains the situation (as
    applicable to draft-rahman-rsvp-restart-extensions-00.txt):

           R1-------R2-------R3-------R4

    An LSP spans across R1-R2-R3-R4. If R2, R3 and R4 restart simultaneously,
    without locally saved signaling state on at least R3 (i.e., R3 is able to
    recover mandatory signaling state on its own) the following happens: R1
    sends a Path with Recovery Label to R2. R2 may at best recover the
    outgoing interface information from the forwarding state. R2 then sends a
    Path with a minimal Recovery ERO (eg: incoming interface on R2, R4 as
    loose). R3 does the same. Effectively, this is the same behaviour as
    defined in RFC3473 (with clarification regarding contents of the
    transmitted [Recovery] ERO).

    (Please see section 9.5.2, paragraph 4 "When a node receives a Path
    message during the Recovery Period, ..." which covers the adjacent node
    restart case, when a Path message could be received by the downstream
    restarting node without a Recovery Label).

Thanks,
_arun_
============================================================
On Sat, 21 Feb 2004, Adrian Farrel wrote:

> Date: Sat, 21 Feb 2004 22:13:31 -0000
> From: Adrian Farrel <[email-masked]>
> To: [email-masked], 'Anca Zamfir' <[email-masked]>, [email-masked],
>      [email-masked], Lou Berger <[email-masked]>,
>      [email-masked]
> Cc: [email-masked]
> Subject: RSVP Graceful Restart Extensions
>
> Hi all,
>
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
> draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.
>
> I would appreciate your views on how the problem (rather than the solution differs).
>
> If the overlap between the problems is significant, can you tell me whether is likelihood
> of persuading you to merge the drafts or whether the solutions are so radically different
> that the WG must select one solution or the other.
>
> Thanks,
> Adrian

Delivery-date: Mon, 23 Feb 2004 14:43:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Lou Berger" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RSVP Graceful Restart Extensions
Date: Sat, 21 Feb 2004 22:13:31 -0000

Hi all,

draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.

I would appreciate your views on how the problem (rather than the solution differs).

If the overlap between the problems is significant, can you tell me whether is likelihood
of persuading you to merge the drafts or whether the solutions are so radically different
that the WG must select one solution or the other.

Thanks,
Adrian

Delivery-date: Mon, 23 Feb 2004 14:42:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: CCAMP Agenda for Seoul
Date: Fri, 20 Feb 2004 16:14:22 -0000

Folks,

Here is the agenda for Seoul.

As usual, we are heavily subscribed with requests for new
work - either 00 drafts, or material that is not explicitly
on the charter. As usual, this means that we have to make
hard choices about what is included.

The priorities are clearly as follows:
- charter milestones
- working group drafts
- urgent charter items
- other charter items
- new work.

If your pet project is not included then sorry. Please take
the draft to the mailing list and start/continue the
discussion.

CCAMP Agenda: Seoul March 2004.
Total 150 minutes.

Group Admin 
  Chairs
  Admin (5 mins)
  Agenda bash (5 mins)
  Status of WG drafts and milestones (10 mins)
  - RFC editor queue
  - status of IANA for SONET/SDH
  - future allocation of "experimental" values

Liaisons
  Marco Carugi (5 mins)
  SG13 liaison

  Lyndon Ong (10 mins)
  SG15 liaison

ASON Requirements and Solutions
  Dimitri Papadimitriou (5 mins)
    ASON Signaling Requirements
      draft-ietf-ccamp-gmpls-ason-reqts-05.txt

  Dimitri Papadimitriou (10 mins)
    ASON Signaling Solutions
      draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

  Lou Berger (5 mins)
    Egress control
      draft-berger-gmpls-egress-control-01.txt

  Lyndon Ong (5 mins)
    ASON Routing Requirements
      draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

Tunnel Trace
  Ron Bonica (10 mins)
    draft-bonica-tunproto-05.txt

Protection and Restoration
  Dimitri Papadimitriou (10 mins)
    Protection and Restoration Team
      draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
      draft-ietf-ccamp-gmpls-recovery-functional-01.txt
      draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
      draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

  Lou Berger (5 mins)
    Segment Recovery
      draft-berger-ccamp-gmpls-segment-recovery-00.txt

Inter-Area/AS
  Arthi Ayyangar (10 mins)
    Inter-area/AS
      draft-vasseur-ccamp-inter-area-as-te-00.txt

  Fabio Ricciato (10 mins)
    Inter-area path protection
      draft-dachille-inter-area-path-protection-00.txt

Control Pane Resilience, Hello Protocol and Graceful Restart
  Young Hwa Kim (5 mins)
    Requirements for the Resilience of Control Plane in GMPLS
      draft-kim-ccamp-cpr-reqts-00.txt

  Lou Berger (5 mins)
    Extensions to GMPLS RSVP Graceful Restart
      draft-aruns-ccamp-rsvp-restart-ext-00

  Zafar Ali (10 mins)
    Extensions to GMPLS RSVP Graceful Restart
      draft-rahman-ccamp-rsvp-restart-extensions-00.txt
    Modifications to Hello procedures
      draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
      draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

Everything Else
  Emmanuel Dotaro (5 mins)
    Multi-region protection
      draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt

  Seisho Yasukawa / Jean-Louis Le Roux (10 mins)
    Advertizing TE Capabilities in IGPs
      draft-vasseur-ccamp-ospf-te-caps-00.txt
      draft-vasseur-ccamp-isis-te-caps-00.txt

  Zafar Ali (5 mins)
    Explicit Resource Control and Tracking
      draft-zamfir-explicit-resource-control-bundle-03.txt

  Lou Berger (5 mins)
    Alarm Reporting
      draft-berger-ccamp-gmpls-alarm-spec-01.txt

Delivery-date: Mon, 23 Feb 2004 14:42:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Advice and requirements to presenters at CCAMP in Seoul
Date: Fri, 20 Feb 2004 17:18:02 -0000

In view of the tight schedule in Seoul, and the likelihood of a very high percentage of
non-native English speakers in the room, here are some requirements on "presenters".

- Assume that your draft has been read
   - Do not present the function or procedures of
      your draft

- Do state the schedule, milestones and proposals
   for your draft

- Do state the major changes since the last version

- Do state the remaining work items

- Do state any contentious issues of hard problems
  where you would welcome help or input.

In order to present at the meeting, you MUST submit your slides to me by Tuesday March 4th
10pm Korean time. This gives me time to put them on a web site so that the room can read
the slides in advance, and follow along with the slides at their own speed. This is a
necessary courtesy to the non-native English speakers. So...
No slides == no agenda slot!

For those who haven't done this much before, a few factors to consider...
- a slide is too full if it has more than ten lines on it
- you need 1 to 2 minutes per slide
- you may want to leave time for discussion after your slides
  (your timeslot includes any discussion)

A set of slides that you may want to use as a template can be found at
www.olddog.co.uk/ccamp-template.ppt

Thanks,
Adrian

Delivery-date: Fri, 20 Feb 2004 04:20:13 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D Action : draft-kim-ccamp-cpr-reqts-00.txt
Date: Fri, 20 Feb 2004 13:22:51 +0900

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_001_01C3F769.33D1F872
Content-Type: text/plain;
	charset="euc-kr"

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Requirements for the Resilience of Control Plane
in GMPLS
	Author(s)	: Y. Kim
	Filename	: draft-kim-ccamp-cpr-reqts-00.txt
	Pages		: 15
	Date		: 2004-2-9
	
This document describes requirements for providing the resilience 
   capability of control plane (in other words, control network) in 
   GMPLS. As known in generally, control plane consist of control 
   entities, control channels, and control nodes. This contribution, as 
   a document that proposes a framework to provide the resilience 
   capability of control plane, include terminologies, basic concepts of 
   control networks, possible configurations, necessities and 
   requirements, additional considerations including the relationship 
   with other protocol such as LMP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kim-ccamp-cpr-reqts-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-kim-ccamp-cpr-reqts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt>

------_=_NextPart_001_01C3F769.33D1F872
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>I-D Action : draft-kim-ccamp-cpr-reqts-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Requirements for the Resilience of Control Plane in GMPLS</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Kim</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-kim-ccamp-cpr-reqts-00.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
15</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-2-9</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This document describes requirements for providing =
the resilience </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; capability of control plane (in other =
words, control network) in </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; GMPLS. As known in generally, control =
plane consist of control </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; entities, control channels, and control =
nodes. This contribution, as </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; a document that proposes a framework to =
provide the resilience </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; capability of control plane, include =
terminologies, basic concepts of </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; control networks, possible =
configurations, necessities and </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; requirements, additional considerations =
including the relationship </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; with other protocol such as LMP.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-kim-ccamp-cp=
r-reqts-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>To remove yourself from the IETF Announcement list, =
send a message to </FONT>
<BR><FONT SIZE=3D2>ietf-announce-request with the word unsubscribe in =
the body of the message.</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-kim-ccamp-cpr-reqts-00.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>Send a message to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>[email-masked].</FONT>
<BR><FONT SIZE=3D2>In the body type:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;FILE =
/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt&quot;.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
return the document in</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
different behavior, especially when dealing with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
been split</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
multiple messages), so check your local documentation on</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
manipulate these messages.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>
<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>
<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;<A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.=
txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr=
-reqts-00.txt</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3F769.33D1F872--

Delivery-date: Fri, 20 Feb 2004 04:18:53 +0000
From: [email-masked]
To: [email-masked]
Subject: I-D Action : draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Fri, 20 Feb 2004 13:19:51 +0900

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_001_01C3F768.C8430240
Content-Type: text/plain;
	charset="euc-kr"

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Interaction between GMPLS RSVP-TE and LCAS
	Author(s)	: Y. Kim
	Filename	: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
	Pages		: 12
	Date		: 2004-2-16
	
This document describes interaction aspects between a signaling 
   protocol and the LCAS. The signaling protocol handled by IETF could 
   be GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. 
   The LCAS protocol handled by ITU-T is a protocol that is used to 
   change the bandwidth capacity of a virtual concatenated signal used 
   by transport networks (i.e. SDH and OTN), which should be initiated
   only in a unidirection by EMS or NMS systems. However, the GMPLS 
   signaling protocol have a feature of being capable of controlling bi-
   directional connections on a LSP. In current, there is no interaction 
   between the signaling protocol and the LCAS. In this document, when a 
   signaling protocol such as the GMPLS RSVP-TE and the LCAS are used 
   together within a single node and a bi-directional connection is 
   required on the same route, relevant requirements and encoding 
   methods are identified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-
lcas-01.txt

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-
01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-
lcas-01.txt>

------_=_NextPart_001_01C3F768.C8430240
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>I-D Action : =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Interaction between GMPLS RSVP-TE and LCAS</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Kim</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
12</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-2-16</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This document describes interaction aspects between =
a signaling </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; protocol and the LCAS. The signaling =
protocol handled by IETF could </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; be GMPLS RSVP-TE. GMPLS CR-LDP requires =
further study for this draft. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; The LCAS protocol handled by ITU-T is a =
protocol that is used to </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; change the bandwidth capacity of a =
virtual concatenated signal used </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; by transport networks (i.e. SDH and =
OTN), which should be initiated</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; only in a unidirection by EMS or NMS =
systems. However, the GMPLS </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; signaling protocol have a feature of =
being capable of controlling bi-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; directional connections on a LSP. In =
current, there is no interaction </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; between the signaling protocol and the =
LCAS. In this document, when a </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; signaling protocol such as the GMPLS =
RSVP-TE and the LCAS are used </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; together within a single node and a =
bi-directional connection is </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; required on the same route, relevant =
requirements and encoding </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; methods are identified.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-=
grsvpte-lcas-01.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-kim-ccamp-in=
teraction-grsvpte-lcas-01.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>To remove yourself from the IETF Announcement list, =
send a message to </FONT>
<BR><FONT SIZE=3D2>ietf-announce-request with the word unsubscribe in =
the body of the message.</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>Send a message to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>[email-masked].</FONT>
<BR><FONT SIZE=3D2>In the body type:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;FILE =
/internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-01.txt&quot;.<=
/FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
return the document in</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
different behavior, especially when dealing with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
been split</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
multiple messages), so check your local documentation on</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
manipulate these messages.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>
<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>
<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;<A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-interaction-g=
rsvpte-lcas-01.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-int=
eraction-grsvpte-lcas-01.txt</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3F768.C8430240--

Delivery-date: Wed, 18 Feb 2004 00:27:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Educational Sessions in Seoul
Date: Tue, 17 Feb 2004 21:41:41 -0000

All,
You are encouraged to attend the training sessions in Seoul.
Adrian

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 17, 2004 9:32 PM
Subject: Educational Sessions in Seoul

> 
> Hi All,
> 
> The EDU Team is offering several training sessions on Sunday afternoon in Seoul
> that are open to ALL IETF ATTENDEES.  These sessions include:
> 
> - Newcomers Training (in both English and Korean)
> - Editors Training
> - Introductory WG Chairs Training
> - Security Tutorial
> 
> Details about these sessions can be found below.
> 
> Please note that you do not need to be a current Editor or WG Chair to attend
> those sessions, these sessions are all open to everyone!  So, show up early
> and learn more about how to work effectively within the IETF.
> 
> Margaret
> 
> 
> 
> Sunday, February 29, 2004
> =========================
> 
> 1300-1400  Newcomer's Training in English -- Location??  (Spencer Dawkins)
> 
>             An introduction to the IETF for new or recent IETF
>             attendees.  Covers the IETF document processes, the
>             structure of the IETF, and tips for new attendees to
>             be successful in the IETF environment.
> 
> 1400-1500  Newcomer's Training in Korean -- Location??  (ChangJoon Kim)
> 
>             [Include description on agenda in Korean, if possible.]
> 
>             An introduction to the IETF for new or recent IETF
>             attendees.  Covers the IETF document processes, the
>             structure of the IETF, and tips for new attendees to
>             be successful in the IETF environment.
> 
> 1300-1500  Editor's Training -- Location??  (Avri Doria)
> 
>             Training for current or aspiring IETF document
>             editors.  Covers the roles and responsibilities
>             of a document editor, and includes advice on
>             producing a high-quality IETF specification.
> 
> 1300-1500  Intro WG Chairs Training -- Location??  (Margaret Wasserman)
> 
>             Introductory training for new or aspiring WG
>             chairs.  Covers the role and responsibilities of
>             a WG chair, and includes advice on how to run a
>             WG that is fair, open and productive.  This class
>             is open to all IETF attendees.
> 
> 1500-1700  Security Tutorial -- Location??  (Radia Perlman)
> 
>             All IETF attendees need to be aware of the security
>             implications of our design choices.  This session
>             offers a basic primer in protocol security, as well
>             as advice on how to write the Security Considerations
>             sections required for all IETF documents.
> 
> 
> 
> 

Delivery-date: Tue, 17 Feb 2004 15:32:37 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-03.txt
Date: Tue, 17 Feb 2004 10:30:35 -0500

--NextPart

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

	Title		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow
	Filename	: draft-ietf-ccamp-gmpls-overlay-03.txt
	Pages		: 12
	Date		: 2004-2-17
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies.  These protocols can be used to support a number of
deployment scenarios.  This memo addresses the application of GMPLS
to the overlay model.

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

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 16 Feb 2004 20:37:05 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-04.txt
Date: Mon, 16 Feb 2004 15:33:51 -0500

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching (GMPLS) Traffic 
			  Engineering Management Information Base
	Author(s)	: T. Nadeau
	Filename	: draft-ietf-ccamp-gmpls-te-mib-04.txt
	Pages		: 43
	Date		: 2004-2-16
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

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

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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-te-mib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-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: Fri, 13 Feb 2004 21:23:20 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: Malcolm Betts <[email-masked]>, Scott Bradner <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], IESG Secretary <[email-masked]>, "'Peter Wery'" <[email-masked]>, "'Steve Trowbridge'" <[email-masked]>, "'Rosa, Paolo'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Liaison regarding ASON Routing Requirements submission
Date: Fri, 13 Feb 2004 16:18:32 -0500
Reply-To: "Lam, Hing-Kam (Kam)" <[email-masked]>

> ----------
> Od: 	Lam, Hing-Kam (Kam)[SMTP:[email-masked]]
> Wys³ano: 	13 lutego 2004 22:18:32
> Do: 	'Kireeti Kompella'
> DW: 	Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner; [email-masked]; IESG Secretary; 'Peter Wery'; 'Steve Trowbridge'; 'Rosa, Paolo'; [email-masked]'
> Temat: 	RE: Liaison regarding ASON Routing Requirements submission
> Automatycznie przesy³ane dalej przez regu³ê
> 
Dear Mr. Kompella,

Thank you for the liaison and the document. I will put them into the agenda of the Q14/15 Interim meeting that is next week in Chicago. I expect a reply will be generated from the meeting.

Thanks again for the opportunity to review and comment on the ccamp document.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 11:27 AM
> To: Hing-Kam Lam
> Cc: Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner;
> [email-masked]; IESG Secretary
> Subject: Liaison regarding ASON Routing Requirements submission
> 
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 13, 2004
> Deadline: February 27, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by February
> 27, 2004 so that we can review it during the next IETF meeting.  We
> look forward to ongoing collaboration with you regarding the use of
> IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 

Delivery-date: Fri, 13 Feb 2004 21:20:13 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: Malcolm Betts <[email-masked]>, Scott Bradner <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], IESG Secretary <[email-masked]>, "'Peter Wery'" <[email-masked]>, "'Steve Trowbridge'" <[email-masked]>, "'Rosa, Paolo'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Liaison regarding ASON Routing Requirements submission
Date: Fri, 13 Feb 2004 16:18:32 -0500

Dear Mr. Kompella,

Thank you for the liaison and the document. I will put them into the agenda of the Q14/15 Interim meeting that is next week in Chicago. I expect a reply will be generated from the meeting.

Thanks again for the opportunity to review and comment on the ccamp document.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 11:27 AM
> To: Hing-Kam Lam
> Cc: Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner;
> [email-masked]; IESG Secretary
> Subject: Liaison regarding ASON Routing Requirements submission
> 
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 13, 2004
> Deadline: February 27, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by February
> 27, 2004 so that we can review it during the next IETF meeting.  We
> look forward to ongoing collaboration with you regarding the use of
> IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 

Delivery-date: Fri, 13 Feb 2004 16:31:13 +0000
Date: Fri, 13 Feb 2004 08:27:07 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Hing-Kam Lam <[email-masked]>
cc: Malcolm Betts <[email-masked]>, Scott Bradner <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], IESG Secretary <[email-masked]>
Subject: Liaison regarding ASON Routing Requirements submission

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--0-1499996177-1076689627=:59519
Content-Type: TEXT/PLAIN; charset=US-ASCII

Liaison Statement
Source: CCAMP WG, IETF
To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
    Alex Zinin, IETF Routing Area Director
    Bill Fenner, IETF Routing Area Director
Approval: CCAMP WG
For: Action
Date: February 13, 2004
Deadline: February 27, 2004

Dear Mr. Lam,

This liaison is a follow-up to our recent liaison (October 2003)
regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
requirements.  We wish to inform Q14/15 that the Design Team has
prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
and the draft is submitted for review at CCAMP's March meeting.  We
would, therefore, appreciate any feedback on this draft by February
27, 2004 so that we can review it during the next IETF meeting.  We
look forward to ongoing collaboration with you regarding the use of
IETF signaling and routing protocols for ASON.

                                     Kireeti Kompella & Adrian Farrel,
                                            IETF CCAMP WG Chairs
--0-1499996177-1076689627=:59519
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rout-req
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename=rout-req

--0-1499996177-1076689627=:59519--

Delivery-date: Fri, 13 Feb 2004 07:38:35 +0000
content-class: urn:content-classes:message
Subject: MPLS and GMPLS Interoperability Test Event, to be showcased in Kobe, Japan
Date: Fri, 13 Feb 2004 00:35:33 -0700
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Invitation to participate at the first Asian MPLS Interoperability event =
to be showcased at ICBN 2004 (International Conference on Communication =
and Broadband Networking), Kobe, Japan, April 7-9, 2004

Hello everyone,

The MPLS & FR Alliance Interoperability Committee for the first time =
will hold a public interoperability event in Asia. This will be =
showcased at the upcoming conference ICBN 2004 co-sponsored by the ATM =
Forum and MPLS & FR Alliance.  You are invited to participate in the =
public interoperability event.

The event will bring important benefits to the participating companies:
- The private test event leading to the showcase will improve the =
device's interoperability
- The public showcase will demonstrate the tests and results to the =
conference visitors and confirm that the devices are addressing =
interoperability issues
- There will be extensive interaction with the press about the event

Visitors to the ICBN 2004 conference will represent the technical =
community in Asia.

The topics to be covered at this event include MPLS Quality of Service =
and resiliency of routers using MPLS, as well topics in GMPLS.=20

Showcase Details:

The interoperability event is organized by the MPLS & Frame Relay =
Alliance. A network with MPLS/GMPLS routers from different vendors, =
complemented by emulators, will be used to perform the test scenarios =
and validate the test methodologies.=20

To ensure that the showcase is successful, a hot-stage event will be =
held in March, a few weeks prior to the ICBN 2004 event. This test event =
will take place in two parts over two weeks, focusing on MPLS and GMPLS =
separately in each week.=20

The hot-stage events for MPLS as well as GMPLS will be held at Isocore's =
testing facility in Virginia, U.S. (http://www.isocore.com/)

Test Areas:

The test plans will be based on work by the MPLS & Frame Relay Alliance =
interoperability committee. These tests will be built upon the =
experiences of previous interoperability test events and go into new =
testing areas. The topics will be finalized after discussing with the =
potential test event participants.

The tests may cover the following topics:

o	Graceful Restart for OSPF, IS-IS, LDP, and BGP
o	DiffServ and MPLS TE covering both RFC 2702 and RFC 3270
o	Fast Reroute
o	Layer 2 and Layer 3 MPLS VPNs

Next Steps:

The first conference call has been held. For details on the next =
conference call, please contact Alexa Morris of the MPLS & FR Alliance =
(details below).

Detailed test plans will be discussed on conference calls between the =
interested parties. All interested parties will have to sign a =
non-disclosure agreement (NDA) to participate as confidential =
information may be exchanged on subsequent calls.

For registration and enquiries, please contact:

Alexa Morris
Executive Director, MPLS & FR Alliance
Phone: +1-510-608-5914/5910
[email-masked]

Thanks for your attention and look forward to meeting you on the =
conference calls.

Regards,

Ananda Sen Gupta
Chair, Interoperability Committee
MPLS and Frame Relay Alliance
[email-masked]

Delivery-date: Tue, 10 Feb 2004 08:59:55 +0000
content-class: urn:content-classes:message
Subject: Merged intera-area reqts ID
Date: Tue, 10 Feb 2004 09:56:55 +0100
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3EFB3.D5229064
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C3EFB3.D5229064"

------_=_NextPart_002_01C3EFB3.D5229064
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

Hi all,=20

Find attached a new ID on  inter-area TE requirements, that was posted
yesterday .=20

It is a merge of two previous IDs:=20
        -draft-boyle-tewg-interarea-reqts-01=20
        -draft-leroux-tewg-inter-area-te-reqs-00=20

 CCAMP  comments will be much appreciated.=20

Regards=20

JL=20

<<draft-leroux-tewg-interarea-mpls-te-req-00.txt>>=20

------_=_NextPart_002_01C3EFB3.D5229064
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DTahoma size=3D2></FONT>&nbsp;</DIV><!-- Converted from =
text/rtf format -->
<P><FONT face=3DArial size=3D2>Hi all,</FONT> </P>
<P><FONT face=3DArial size=3D2>Find attached a new ID&nbsp;<SPAN=20
class=3D484195108-10022004><FONT=20
color=3D#000000>on&nbsp;</FONT></SPAN>&nbsp;inter-area&nbsp;<SPAN=20
class=3D484195108-10022004><FONT color=3D#0000ff><FONT =
color=3D#000000>TE=20
</FONT></FONT></SPAN>requirements, that was poste<SPAN=20
class=3D484195108-10022004>d yesterday</SPAN><SPAN=20
class=3D484195108-10022004>&nbsp;</SPAN>.</FONT> </P>
<P><FONT face=3DArial size=3D2>It is a merge of two previous IDs:</FONT> =

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
size=3D2>-draft-boyle-tewg-interarea-reqts-01</FONT>=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
size=3D2>-draft-leroux-tewg-inter-area-te-reqs-00</FONT> </P>
<P><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D484195108-10022004><FONT=20
color=3D#0000ff>&nbsp;</FONT><FONT color=3D#000000>CCAMP=20
&nbsp;</FONT></SPAN>comments will be much =
appreciated.&nbsp;</FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Regards</FONT> </P>
<P><FONT face=3DArial size=3D2>JL</FONT> </P>
<P><FONT face=3DArial=20
size=3D2>&lt;&lt;draft-leroux-tewg-interarea-mpls-te-req-00.txt&gt;&gt;=20
</FONT></P></BODY></HTML>

------_=_NextPart_002_01C3EFB3.D5229064--

------_=_NextPart_001_01C3EFB3.D5229064
Content-Type: text/plain;
	name="draft-leroux-tewg-interarea-mpls-te-req-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-leroux-tewg-interarea-mpls-te-req-00.txt
Content-Disposition: attachment;
	filename="draft-leroux-tewg-interarea-mpls-te-req-00.txt"

------_=_NextPart_001_01C3EFB3.D5229064--

Delivery-date: Mon, 09 Feb 2004 17:31:16 +0000
Date: Mon, 09 Feb 2004 12:29:38 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: IETF CCAMP List <[email-masked]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart  extensions(draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

Reshad Rahman wrote:
> 
> I haven't seen anything wrt ERO change clearly specified in any of
> the RFCs.

Unfortunately, it isn't mentioned.  The consensus at the time of RFC 
3209's development was that make-before-break should be used for any 
rerouting.

Unfortunately, this ignores corner cases like when the route table 
changes, causing a loose-hop's next-hop to change.  How to process an 
ERO change seems (to me, anyway) to be related.

What I wrote (quoted below) is what I think makes the most sense.  It 
would be great if this could be codified so that everybody handles this 
the same way.  If some feel that my assumption is wrong, then this is 
something that should be discussed and codified afterwards.

>> RSVP, by nature is a soft-state protocol.  Implementations should
>> expect stuff to change all the time.  When an ERO changes, a node
>> shouldn't reject the message.  It should use the new ERO to
>> determine the new next-hop.
>> 
>> If the next hop doesn't change, then the node should leave the LSP
>> in place and immediately generate a Path refres, so that downstream
>> neighbors get the new ERO as soon as possible.
>> 
>> If the next hop changes, then it should be treated identically to
>> what would happen in response to a route change with a loose
>> ERO-hop or no ERO.

Note that I didn't describe what to do when a route-table change causes 
an LSP to reroute.  There are different approaches to this, but none are 
ideal.  All result in transient problems (LSP flapping, dropped packets, 
etc.)  This is why make-before-break is strongly preferred to changing 
an ERO in-line.

-- David

Delivery-date: Mon, 09 Feb 2004 17:17:42 +0000
Date: Mon, 09 Feb 2004 12:16:12 -0500
From: Reshad Rahman <[email-masked]>
Organization: Cisco Systems
To: David Charlap <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart  extensions(draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

Thanks for the response. Comments inline.

David Charlap wrote:
> 
> Reshad Rahman wrote:
> >
> > Tthe main comment/question was if we could reuse the RRO object instead
> > of defining a new object to recover the contents of an ERO expansion
> > done prior to control plane restart. Here are two potential issues with
> > reusing RRO:
> > - The RRO would contain the full list of nodes whereas the ERO expansion
> > may have been partial. In that situation the downstream node would
> > detect a change in the incoming ERO and may reject the message (the
> > expected behaviour on incoming ERO change seems to be unspecified).
> 
> I hope it doesn't do this.
> 

I haven't seen anything wrt ERO change clearly specified in any of the RFCs. 

> RSVP, by nature is a soft-state protocol.  Implementations should expect
> stuff to change all the time.  When an ERO changes, a node shouldn't
> reject the message.  It should use the new ERO to determine the new
> next-hop.
> 
> If the next hop doesn't change, then the node should leave the LSP in
> place and immediately generate a Path refres, so that downstream
> neighbors get the new ERO as soon as possible.
> 
> If the next hop changes, then it should be treated identically to what
> would happen in response to a route change with a loose ERO-hop or no ERO.
> 
> BTW, I noted that your draft allows an ingress node to recover more
> quickly.  This has been a hole in the GR procedure.  An ingress node
> that is computing an ERO can't re-compute that ERO until routing
> reconverges, and when it does so, there is no guarantee that it will
> compute the same ERO as before the failure.  It could store the ERO in
> non-volatile storage, but that can be problematic if there are thousands
> of LSPs originating.
> 
> Using the recovery-ERO object solves this.  The ingress node can then
> send out a Path (using the preserved forwarding state to know what the
> next-hop is) using an empty (or near-empty) recovery ERO.  The next-hop
> can then send back an immediate Resv containing an appropriate
> recovery-ERO, which the ingress node can use while waiting for routing
> to reconverge.  (Once routing reconverges and recovery completes, of
> course, it will want to compute its own ERO and possibly do a
> make-before-break to the new path if it ends up being better than the
> recovered path.)
> 
> > - RRO uses Class-Number of form 0bbbbbbb, so if the downstream node
> > doesn't support RRO, the whole message is rejected.
> 
> If RRO isn't supported, then the ingress node will know about, since the
> LSP won't come up in the first place.
> 
> If this happens, then the upstream node will know that it can't use this
> method of ERO recovery.  Functionally, this is really no different from
> a node not supporting the recovery-ERO class.

Yes. I was thinking of the case where the LSP hadn't initially been setup with
RRO. Adding RRO in the Path message may result in a PathError but the restarting
node can handle that. So it doesn't seem to be an issue.

> 
> Note that other RSVP extensions (like Fast Reroute) also require RRO
> support as a prerequisite.

We're OK with using RRO to recover ERO, as long as there's agreement/consensus
on how to handle ERO change.

Regards,
Reshad.

> -- David

Delivery-date: Mon, 09 Feb 2004 08:35:02 +0000
Date: Mon, 09 Feb 2004 17:29:46 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Protection object in resv message

Hi Dimitri,

Yes. The text below addresses my concern.

Thank you,

Yoshihiko

On Thu, 05 Feb 2004 02:02:30 +0100,
[email-masked] wrote:

> hi, see in-line
> 
> Yoshihiko SUEMURA wrote:
> 
> > Hi Dimitri,
> > 
> > Please see inline.
> > 
> > On Sun, 01 Feb 2004 15:39:33 +0100,
> > [email-masked] wrote:
> > 
> > 
> >>hi, see in-line
> >>
> >>Yoshihiko SUEMURA wrote:
> >>
> >>>P&R Design Team,
> >>>
> >>>In the 1:1/Shared Mesh Restoration described in
> >>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> >>>secondary LSP is done only by a Path message. The Protection object is
> >>>carried only in a Path message.
> >>>However, I think a Resv message should also carry the Protection object.
> >>>
> >>>Consider the following case.
> >>>
> >>>   A-----------B
> >>>    \         /
> >>>     C-------D
> >>>    /         \
> >>>   E           F
> >>>
> >>>A-B:     Primary LSP
> >>>A-C-D-B: Secondary LSP
> >>>E-C-D-F: Extra (preemptable) LSP
> >>>
> >>>Activating the Secondary LSP using only a Path message may cause
> >>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> >>>LSP. 
> >>
> >>here i would agree that there is a condition on the next_hop
> >>to delete the extra_lsp state before activating the xc for
> >>the secondary lsp and in order to guarantee this commit of
> >>the resources activation may be done upon resv reception
> >>
> >>also the use of hard preemption before committing this
> >>operation decreases (if not completely elevates if used
> >>to commit action when received from D in this example)
> >>the time occurrence of this transient state:
> >>
> >>- PathErr with PAth_State_Removed flag towards E and a PathTear
> >>   to the destination F
> >>- or a PathErr with Path_State_Removed flag towards F and a
> >>   PathTear towards E
> >>
> >>therefore there are other faster triggers for this purpose
> >>the issue being at the end to either perform this operation
> >>as fast as possible when reaching the last common node,
> >>or simply delete in downstream direction and commit along
> >>the upstream direction as said above (there are more complex
> >>cases where this might be at the end more easy to process)
> >>
> >>
> >>>This can be prevented by applying a two-way activation scheme using
> >>>both Path and Resv messages. 
> >>
> >>nothing prevent this from the above (the paragraph that
> >>describes this doesn't say commit at the data plane this
> >>is left out to the implementation) some clarification in
> >>the document are certainly needed here
> >>
> >>
> >>>You can delete the Extra LSP by the Path
> >>>message, and activate the Secondary LSP by the Resv message. 
> >>
> >>you may want to apply this activation scheme, in such a case
> >>all the nodes would have their extra-traffic lsp deleted
> >>through the downstream path message
> > 
> > 
> > Yes. This is what I want to apply. I want to delete all the
> > extra-traffic LSPs through the downstream Path message, and then,
> > activate the secondary LSP through the upstream Resv message.
> > 
> > 
> >>>However, if the Resv message for activation does not carry the
> >>>Protection object, it cannot be distinguished from a refresh Resv
> >>>message. This still causes unintended connection in the following case.
> >>>
> >>>(1) At node C, a crossconnect for the Extra LSP is deleted when
> >>>receiving a Path message.
> >>>  
> >>>(2) Then, if node C receives a refresh Resv message from D, it sets up a
> >>>crossconnect for the Secondary LSP because it cannot distinguish the
> >>>refresh Resv message from a Resv message for activation.
> >>
> >>referring to 2961 p12/13 don't see how see this could happen,
> >>would you clarify, in order to address this point in case, also
> >>the resv is considered implicitly here as trigger message
> > 
> > 
> > After (1), node C waits for the upstream Resv message for activating the
> > secondary LSP. However, it may receive a refresh Resv message (refresh
> > for a Resv message for PROVISIONING the secondary LSP) from D before
> > receiving the Resv for activation. Currently, C cannot distinguish it
> > from the Resv for activation because there is no difference between
> > their formats. This may trigger C to activate the secondary LSP
> > unintentionally before the downstream nodes delete their extra-traffic
> > LSPs.
> 
> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
> 
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."
> 
> hope this addresses the concern,
> thanks,
> - dimitri.
> > Thank you,
> > 
> > Yoshihiko
> > 
> > 
> >>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> >>>causes unintended connection between the Secondary LSP and the Extra LSP.
> >>>
> >>>As a solution for the above problem, I propose to add the Protection
> >>>object to a Resv message. The unintended connection can be prevented
> >>>because you can distinguish a Resv message for activation from a refresh
> >>>Resv message by watching the S bit.
> >>
> >>suggest to first clarify the previous point,
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>Best regards,
> >>>
> >>>Yoshihiko
> >>>
> >>>-----------------------------------------------------------------
> >>>Yoshihiko SUEMURA 
> >>>
> >>>NEC Corporation
> >>>E-mail: [email-masked]
> >>>
> >>>
> >>
> >>-- 
> >>Papadimitriou Dimitri
> >>E-mail : [email-masked]
> >>E-mail : [email-masked]
> >>Webpage: http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : +32 3 240-8491
> >>
> > 
> > 
> > 
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA 
> > 
> > NEC Corporation
> > E-mail: [email-masked]
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [email-masked]
> E-mail : [email-masked]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
> 
> 
> 

-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [email-masked]

Delivery-date: Sat, 07 Feb 2004 03:00:11 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, "'John Drake'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "'Vishal Sharma'" <[email-masked]>
Subject: Re: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-03.txt has been updated)  
Date: Fri, 6 Feb 2004 21:58:28 -0500
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C3ECFC.5B000EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Ccamp'ers:
 
This is a follow-up on our AI from the last ccamp WG meeting and
comments from Adrian Farrel, John Drake, Vishal Sharma, Kireeti
Kompella, George Swallow, Lou Berger, et al on/ off the list and during
WG meeting. 

Please note that during the last Ccamp meeting and on the mailing list,
we all agreed on the need for component link recording in the RRO. 

The AI on us was to state requirements for explicit control for the
component links (via ERO) in the ID.  We have, therefore, added a
requirement section in the ID for this purpose.  

We would also like to stress that we have agreed on the requirement for
component link recording in RRO. Furthermore, in addition of the
requirement stated on the ID, the ERO counterpart is also needed to
maintain symmetry between the ERO and RRO definitions. We would,
therefore, like to request the WG to adapt this ID as a WG document. 

An updated copy will be available at IETF Web site in a couple of days.
In the mean time, a mirror version of the ID can be viewed at,
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-zamfir-explicit-resou
rce-control-bundle-03.txt

Comments on the updated version will be very much appreciated. 

Thanks

Regards. Anca, Dimitri and Zafar. 

=====================================================================
Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,       Ann Arbor, MI 48104, USA.
Cisco Systems.       (734) 276-2459.
=====================================================================

------=_NextPart_000_000D_01C3ECFC.5B000EB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=3D702311602-15102003><FONT face=3DArial color=3D#000080 =

size=3D2>Dear&nbsp;<SPAN=20
class=3D822482913-20102003>C</SPAN>camp'ers:</FONT></SPAN></DIV>
<DIV><SPAN class=3D702311602-15102003><FONT face=3DArial color=3D#000080 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702311602-15102003>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
color=3D#000080><FONT=20
face=3DArial><FONT size=3D2>This is a follow-up on&nbsp;our =
AI&nbsp;<SPAN=20
class=3D822482913-20102003>from&nbsp;<SPAN =
class=3D953574115-03022004>the=20
</SPAN>last&nbsp;ccamp WG<SPAN class=3D953574115-03022004> meeting=20
and</SPAN></SPAN><SPAN class=3D953574115-03022004>&nbsp;</SPAN><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004>comments =
from Adrian=20
Farrel,&nbsp;John Drake, Vishal Sharma, Kireeti Kompella, George=20
Swallow,&nbsp;Lou Berger, et al on/ off the list and during WG meeting.=20
</SPAN></SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial><FONT=20
size=3D2><FONT color=3D#800000><SPAN class=3D173104902-07022004>Please =
note that=20
d</SPAN>uring the last Ccamp meeting and on&nbsp;the mailing =
list,&nbsp;we all=20
agreed on the need for component link recording in the RRO.=20
</FONT></FONT></FONT></SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial><FONT=20
color=3D#000080><FONT =
size=3D2></FONT></FONT></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN =
class=3D953574115-03022004><FONT><FONT><FONT=20
face=3DArial><FONT color=3D#000080><FONT size=3D2>The AI on =
us&nbsp;<SPAN=20
class=3D173104902-07022004>was </SPAN>to state requirements&nbsp;for =
explicit=20
control for the component links (via ERO) in the ID.&nbsp;<SPAN=20
class=3D822482913-20102003>&nbsp;</SPAN>We have, therefore,&nbsp;added a =

requirement section in the&nbsp;ID for this purpose.&nbsp;<SPAN=20
class=3D822482913-20102003>=20
</SPAN></FONT></FONT></FONT></FONT></FONT></SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D953574115-03022004><FONT face=3DArial><FONT =
color=3D#000080><FONT size=3D2>We=20
would also like to stress that we have agreed on the requirement for =
component=20
link recording in RRO. Furthermore, in addition&nbsp;of =
the&nbsp;requirement=20
stated on the ID,&nbsp;the ERO counterpart is also needed =
to&nbsp;maintain=20
symmetry between the ERO and RRO definitions<SPAN =
class=3D822482913-20102003>. We=20
would, therefore,&nbsp;<SPAN class=3D173104902-07022004>like to request=20
the</SPAN>&nbsp;WG to adapt this ID as a WG document.=20
</SPAN></FONT></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000080=20
size=3D2><SPAN class=3D953574115-03022004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D822482913-20102003><FONT face=3DArial color=3D#000080 =
size=3D2>An&nbsp;updated=20
copy will be available at IETF Web site in a couple of days. In the mean =
time, a=20
mirror version of the ID can be viewed at,&nbsp;<A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-zamfir-explici=
t-resource-control-bundle-03.txt">http://multimedia.ecn.purdue.edu/~ali/i=
etf59/draft-zamfir-explicit-resource-control-bundle-03.txt</A></FONT></SP=
AN></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D822482913-20102003></SPAN></o:p><?xml:namespace prefix =3D o ns =
=3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p><FONT =
face=3DArial=20
color=3D#000080 size=3D2>&nbsp;</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
color=3D#000080><FONT=20
face=3DArial><FONT size=3D2>Comments<SPAN class=3D822482913-20102003> =
on&nbsp;<SPAN=20
class=3D953574115-03022004>the updated version </SPAN>will be very much=20
appreciated. </SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000000=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000080=20
size=3D2>Thanks</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
color=3D#000080 size=3D2>&nbsp;</FONT></o:p></P>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium =
none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; =
mso-border-bottom-alt: solid windowtext .75pt">
<P class=3DMsoNormal=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0in =
0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium =
none; mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: =
0in 0in 1.0pt 0in"><FONT=20
face=3DArial color=3D#000080 size=3D2>Regards&#8230; Anca,&nbsp;<SPAN=20
class=3D173104902-07022004>Dimitri </SPAN>and&nbsp;<SPAN=20
class=3D173104902-07022004>Zafar</SPAN>. </FONT></P></DIV></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. =
#200,<BR>Technical=20
Leader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 48104, =
USA.<BR>Cisco=20
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734)=20
276-2459.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_000D_01C3ECFC.5B000EB0--

Delivery-date: Sat, 07 Feb 2004 02:18:28 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>, "'MPLS wg'" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Reshad Rahman'" <[email-masked]>, <[email-masked]>
Subject: Request for comments on a new ID on Administrative Control of RSVP Hello and Graceful Restart Procedure
Date: Fri, 6 Feb 2004 21:14:46 -0500
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C3ECF6.40AA2BF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear MPLS-ers: 
 
We have submitted a new ID on Administrative Control of RSVP Hello and
Graceful Restart Procedure for discussion in CCAMP WG at the upcoming
IETF meeting in Seoul. Abstract of the ID is as follows: 
 
Abstract

Ability to administratively shutdown RSVP Hellos and Graceful Restart
(GR) procedure without impacting the traffic is a desirable network
operation. Furthermore, there are applications that run RSVP Hellos with
intervals on the order of milliseconds. This poses a requirement to
reduce the number of RSVP messages to a minimal required count.
Fortunately RSVP Hellos are not mandatory and are only required to run
when needed. This allows applications to remove an RSVP Hello session,
when it is not needed. This ID proposes a procedure to remove RSVP Hello
and/ or GR sessions for administrative or optimization purposes.

We have uploaded a copy of it at, 
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-hello-
gr-admin-00.txt
 
Your comments and input on usefulness and applicability will be much
appreciated. 
 
Thanks
 
Regards... Zafar
 
=====================================================================
Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,     Ann Arbor, MI 48104, USA.
Cisco Systems.       (734) 276-2459.
=====================================================================

------=_NextPart_000_000F_01C3ECF6.40AA2BF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><FONT face=3DArial size=3D2>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>Dear MPLS-ers: </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><FONT face=3D"Times New Roman"=20
size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>We have submitted a new ID on Administrative =
Control of=20
RSVP Hello and Graceful Restart Procedure<SPAN =
class=3D748510802-07022004>=20
</SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>for discussion&nbsp;<SPAN =
class=3D748510802-07022004>in=20
CCAMP WG </SPAN>at the upcoming IETF meeting in Seoul. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract=20
of the ID is as follows: </SPAN></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" =
size=3D3></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
<P class=3DRFCHeading-NoTOC style=3D"MARGIN: 0in 0in 0pt">Abstract</P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in"><SPAN=20
style=3D"mso-bidi-font-family: 'Times New Roman'"><?xml:namespace prefix =
=3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in">Ability to =
administratively=20
shutdown RSVP Hellos and Graceful Restart (GR) procedure without =
impacting the=20
traffic is a desirable network operation. Furthermore, there are =
applications=20
that run RSVP Hellos with intervals on the order of milliseconds. This =
poses a=20
requirement to reduce the number of RSVP messages to a minimal required =
count.=20
Fortunately RSVP Hellos are not mandatory and are only required to run =
when=20
needed. This allows applications to remove an RSVP Hello session, when =
it is not=20
needed. This ID proposes a procedure to remove RSVP Hello and/ or GR =
sessions=20
for administrative or optimization purposes.</P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in"><FONT =
face=3DArial=20
size=3D2></FONT>&nbsp;</P></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>We have uploaded a copy of it at, =
</SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004><A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp=
-hello-gr-admin-00.txt">http://multimedia.ecn.purdue.edu/~ali/ietf59/draf=
t-ali-ccamp-rsvp-hello-gr-admin-00.txt</A></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>Your comments and input on usefulness and =
applicability=20
will be much appreciated. </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><FONT=20
face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV align=3Dleft>Thanks</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft>Regards...=20
Zafar</DIV></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. =
#200,<BR>Technical=20
Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ann Arbor, MI 48104, USA.<BR>Cisco=20
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734)=20
276-2459.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C3ECF6.40AA2BF0--

Delivery-date: Fri, 06 Feb 2004 21:04:43 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>
Subject: Re: disman MIB Followup on gmpls-alarm-spec-
Date: Fri, 6 Feb 2004 20:58:11 -0000

Yes, my concerns are allayed.

One point you may be aware of is that there has been a discussion on the
Disman list as a result of IESG concerns over how new values would be added
to the list.  IANA (naturally) with the range 1 to 1023 aiming to be
aligned with any new alarms from ITU and 1025 upwards for ones from any
other source.  So you are referring to a moving target, in IANA rather than
in an RFC.  (This is of course not new but I have yet to see an elegant
approach to it).  You might want to add some words to this effect.

(You will find the new text, not yet in an I-D, in a thread
[Disman] Propose Resolution to iesg-1 and iesg-5 (take 3)
Date: 22 January 2004 20:45
of which the last entry contains

>The following is the proposed resolution to IESG-1 and IESG-5
>
>In the description for IanaItuProbableCause, replace the description
>
>"ITU probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure uniqueness. Probable cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of all Internet numbers, including
>           various SNMP-related numbers, and specifically, new
>           IANAItuProbableCause values. Values of
>           IANAItuProbableCause less than 1024 are reserved for causes
>           that correspond to ITU probable cause. IANAItuProbableCause
>           of 0 is reserved for special purposes and therefore cannot
>           be assigned. See http://www.iana.org"
>
>With
>
>"          ITU-T probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure syntactic uniqueness. Probable
cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of the enumerations in this TC.
>           IANAItuProbableCause value of 0 is reserved for special
>           purposes and MUST NOT be assigned.
>
>           Values of IANAItuProbableCause in the range 1 to 1023 are
reserved
>           for causes that correspond to ITU-T probable cause.
>
>           All other requests for new causes will be handled on a
first-come,
>           first served basis and will be assigned enumeration values
starting
>           with 1025.
>
>           Request should  come in the form of well-formed SMI [RFC2578]
>           for enumeration names that are unique and sufficiently
descriptive.
>
>           While some effort will be taken to ensure that new probable
causes
>           do not conceptually duplicate existing probable causes it is
>           acknowledged that the existence of conceptual duplicates in the
>           starting probable cause list is an known industry reality.
>
>           To aid IANA in the administration of probable cause names and
values,
>           the OPS Area Director will appoint one or more experts to help
review
>           requests.
>           See http://www.iana.org
(end of extract from Disman mailing list)

Tom Petch

-----Original Message-----
From: Lou Berger <[email-masked]>
To: Tom Petch <[email-masked]>; Randy Presuhn
<[email-masked]>
Cc: Wijnen, Bert (Bert) <[email-masked]>; [email-masked]
<[email-masked]>
Date: 30 January 2004 15:01
Subject: disman MIB Followup on gmpls-alarm-spec-

>Tom, (Randy)
>
>         Thank you for providing this input.  What we're looking for is a
>reference that provides enumerated values for alarms.  The ITU specs that
>we found all provide text strings, which is what we're trying to avoid.
It
>seems that the disman MIB provides exactly what we're looking for.
>
>Please let us know if our intended use of the values defined in the MIB
>makes sense from your (disman WG's) perspective, or if you recommend an
>alternate approach.
>
>Thank you,
>Lou
>
>PS The text in the new rev (submitted today) of the draft reads:
>[from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
>3.1.3. Error Codes and Values
>
>    The Error Codes and Values used in ALARM_SPEC objects are the same as
>    those used in ERROR_SPEC objects.  New Error Code values for use with
>    both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
>    alarm types defined by other standards.
>
>    In this document we define one new Error Code.  The Error Code uses
>    the value TBA (by IANA) and is referred to as "Alarms".  The values
>    used in the Error Values field are the same as the values used for
>    IANAItuProbableCause in the Alarm MIB [ALARM-MIB].
>
>The error values field is carried in an object with the format:
>[from: rfc3473]
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Length             | Class-Num (6) | C-Type (3)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     IPv4 Error Node Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Flags     |   Error Code  |          Error Value          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                              TLVs                             ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>At 10:20 AM 11/19/2003, Tom Petch wrote:
>>FYI
>>
>>
>>As a member of the disman WG, I have followed the development of the
alarm
>>mib,
>>currently draft-ietf-disman-alarm-mib-15.txt, over some years and this
has
>>included formal liaison with SG4 and some contact with SG15 over such
>>issues as
>>who owns the code points and who can define them.  SG4 have expressed
>>satisfaction with the way in which the liaison with disman WG has worked
>>(as on
>>the IETF web site).
>>
>>But
>>
>>1) not knowing the working procedures of the ITU, I don't know if the
>>agreement
>>with disman extends to other IETF WG - the wording suggests not to me.
>>
>>2) the alarm mib is currently under debate between authors and WG chair
with a
>>list of some 80 issues being resolved; the most difficult to resolve
>>appear IMO
>>to be the ones relating to the existence of the ITU alarm table as an
>>augmentation of the basic disman alarm table (and perhaps IMHO the lack
of
>>suitable features in SMIv2).  The alarm mib is complex, not one I would
expect
>>people to be able to dip into and readily extract a part thereof.
>>
>>3) I have lost track of the start of this thread and just what it was
that
>>this,
>>ccamp, WG
>>wanted to include in what (and my Acrobat viewer renders the text of the
>>bullet
>>points in AlarmSpec as black blobs of varying size:-(!  But whatever it
is, I
>>suggest you contact the
>>disman chair, randy presuhn, to clarify the niceties of any interaction
>>with the
>>output of disman, whatever form that finally takes.  It may be that
M.3100
>>related material should be in a common MIB module and not included in the
>>alarm
>>mib because of issues of future updates and cross references from
multiple
>>WGs..
>>
>>I think this is known as cross-functional review:-)
>>
>>Tom Petch
>>
>>
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) <[email-masked]>
>>To: Brungard, Deborah A, ALABS <[email-masked]>; Wijnen, Bert (Bert)
>><[email-masked]>; Adrian Farrel <[email-masked]>; Lou Berger
>><[email-masked]>
>>Cc: [email-masked] <[email-masked]>
>>Date: 18 November 2003 23:10
>>Subject: RE: Taking to the
list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>>
>>
>> >the disman mib has enumerations I believe!
>> >
>> >Thanks,
>> >Bert
>> >
>> >> -----Original Message-----
>> >> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
>> >> Sent: dinsdag 18 november 2003 23:06
>> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
>> >> Cc: [email-masked]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Thanks Bert.
>> >>
>> >> M.3100 provides the generic information model, X.733 and
>> >> X.736 define OSI generics pointing to X.721, and X.721
>> >> provides abstract syntax. We were looking for an enumeration
>> >> to use vs. needing to support abstract syntax strings in
>> >> signaling. Any suggestions are welcome.
>> >> Deborah
>> >>
>> >> -----Original Message-----
>> >> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>> >> Sent: Tuesday, November 11, 2003 11:46 AM
>> >> To: Adrian Farrel; Lou Berger
>> >> Cc: [email-masked]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Things to potentially look at:
>> >>
>> >>   draft-ietf-disman-alarm-mib-15.txt
>> >>
>> >>   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
>> >>               Model", 1995
>> >>
>> >>   [X.733]     ITU Recommendation X.733, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Alarm
>> >>               Reporting Function", 1992
>> >>
>> >>   [X.736]     ITU Recommendation X.736, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Security
>> >>               Alarm Reporting Function", 1992
>> >>
>> >> Thanks,
>> >> Bert
>> >>
>> >> > -----Original Message-----
>> >> > From: Adrian Farrel [mailto:[email-masked]]
>> >> > Sent: dinsdag 11 november 2003 17:28
>> >> > To: Lou Berger
>> >> > Cc: [email-masked]
>> >> > Subject: Re: Taking to the
>> >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >> >
>> >> >
>> >> > Lou,
>> >> >
>> >> > I believe the alarm reference was M.3100.
>> >> >
>> >> > Can someone confirm?
>> >> >
>> >> > Adrian
>> >> >
>> >> >
>> >> > > In the morning's meeting the AD's asked to bring the
>> >> proposed Alarm
>> >> > > communication extension to "the list".  For today's
>> >> > presentation see:
>> >> > > http://www.labn.net/docs/AlarmSpec00.pdf
>> >> > >
>> >> > > I believe the issues to be discussed are:
>> >> > > 1) Is there general interest in this work?
>> >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
>> >> > >          (We think there's some value, particularly with string
>> >> > >           and timestamp)
>> >> > > 3) Are there good references for alarm code points?
>> >> > >
>> >> > > Thank,
>> >> > > Lou (and co-authors)
>> >> >
>> >> >
>> >>
>> >
>

Delivery-date: Fri, 06 Feb 2004 20:32:43 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Date: Fri, 6 Feb 2004 15:25:19 -0500
Organization: Cisco Systems

Hi Dimitri, 

Thanks for your comments and feedback. I have in-lined some new
comments. 

As I mentioned in my earlier email that we will take care of these
comments in the next version of the document. 

Thanks again for your feedback. 

Regards... Zafar

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Friday, February 06, 2004 11:17 AM
>To: zafar ali
>Cc: [email-masked]
>Subject: Re: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>hi, some comments on this document that would imho
>beneficiate from the community
>

Thanks, 

>>>   Another scenario which introduces the need for node-id 
>based Hellos
>>>   is when nodes support unnumbered TE links. Specifically,
>>>when all TE
>>>   links between neighbor nodes are unnumbered, it is 
>implied that the
>>>   nodes will use node-id based Hellos for detecting node 
>>>failures. This
>>>   draft also clarifies the use of node-id based Hellos when all or a
>>>   sub-set of TE links are unnumbered.
>>>
>>>DP: the key point is "is the router id used to identify the te
>>>link the same as the one used for the hello's ?"
>>  
>> Yes, the same router-id/ node-id is used.
>
>ok, that's what i wanted to know and i would propose to
>include the above sentence in this i-d
>

Agreed, we will. 

>>>   When link level failure detection is performed by some means other
>>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
>>>   also optimal for detection of nodal failures.
>>>
>>>DP: pin point that this is a particular case, it's not a nodal
>>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>>>signaling controller failure, 
>> 
>> Agreed! this is more precise statement.
>
>ok, thanks
>
>>>note that if this session is
>>>maintained and is used as the IP channel for all messages then 
>>>it MAY also be used as "nodal failure"
>>>
>>>   An implementation may initiate a node-id based Hello
>>>session when it
>>>   starts sharing RSVP states with the neighbor or at an 
>earlier time.
>>>
>>>DP: i don't understand what you mean here
>>>
>> What we meant here is that an application may not run RSVP Hello 
>> session all the time. It may initiate one when it has an application 
>> (e.g., when for GR when it start sharing states with the neighbor.
>
>this is an interesting statement to be considered in the
>scope of this document

No, these details are implementation specific. The related para was
included in the ID as a reference (to avoid confusion on how node-id's
can be obtained.). Nonetheless, as you would agree that this is
implementation specific detail, and hence is outside the scope of the
ID.  

>
>>>   Similarly, an implementation may use the IGP topology to determine
>>>   the remote node-id which matches an interface address(es) used in
>>>   RSVP signaling. These aspects are considered to be a local
>>>   implementation decision.
>>>
>>>DP: how is this possible since you're using the router_id
>>>being the router_address advertized as top level te link 1 in ospf_te
>>>
>>  
>> In Inter-area and inter-AS case, this information is assumed to come 
>> via configuration. Is this what you meant here?
>
>the above sentence introduces an issue once the interface
>is in failure state, i would provide more details here wrt
>to real expectations behind the above paragraph either it
>is implementation specific w/o impact on neighbors or it
>has and then would suggest some details on the last part.
>

This is also an implementation specific detail.  

>>>   When a node receives a Hello packet where the destination
>>>IP address
>>>   is its local node-id as advertised in the IGP-TE 
>topology, the node
>>>   MUST use its node-id in replying to the Hello message. In other
>>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>>   messages are those derived/contained in the IGP-TE topology.
>>>   Furthermore, a node can only run one node-id based RSVP 
>>>Hello session
>>>   with its neighbor.
>>>
>>>DP: well here in fact you have a real issue because, a may
>>>have several node_id's on a node, so what you want to say is 
>>>"one per node_id pair"
>> 
>> Yes, in the cases when router is participating multiple topologies 
>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
>address in 
>> a given IGP instance.
>> 
>> We need to make statement clear for multiple IGP instances case. Is 
>> this is what you meant?
>
>exactly

This is a good point. New text will be updated based on your comment. 

>
>>>   If all interfaces between a pair of nodes are unnumbered,
>>>the optimal
>>>   way to use RSVP to detect nodal failure is to run node-id based
>>>   Hellos. Similarly, when link level failure detection is 
>>>performed by
>>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>>   also optimal in detecting nodal failures. Therefore, if all
>>>   interfaces between a pair of nodes are unnumbered or when 
>>>link level
>>>   failure detection is performed by some means other than 
>>>RSVP Hellos,
>>>   a node MUST run node-id based Hellos for node failure detection.
>>>
>>>DP: this is not true, i can run LMP, but a MUST for the
>>>signaling adj. maintenance
>>>
>>  
>> Yes, we can clarify it in the next version.
>
>thanks,
>-- 
>Papadimitriou Dimitri
>E-mail : [email-masked]
>E-mail : [email-masked]
>Webpage: http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : +32 3 240-8491
>
>

=====================================================================
Zafar Ali, Ph. D. 				  100 South Main St.
#200,
Technical Leader, 				  Ann Arbor, MI 48104,
USA.
Cisco Systems.					  (734) 276-2459.
=====================================================================

Delivery-date: Fri, 06 Feb 2004 16:20:31 +0000
Date: Fri, 06 Feb 2004 17:17:20 +0100
From: [email-masked]
To: zafar ali <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt

hi, some comments on this document that would imho
beneficiate from the community

>>   Another scenario which introduces the need for node-id based Hellos
>>   is when nodes support unnumbered TE links. Specifically, 
>>when all TE
>>   links between neighbor nodes are unnumbered, it is implied that the
>>   nodes will use node-id based Hellos for detecting node 
>>failures. This
>>   draft also clarifies the use of node-id based Hellos when all or a
>>   sub-set of TE links are unnumbered.
>>
>>DP: the key point is "is the router id used to identify the te 
>>link the same as the one used for the hello's ?"
>  
> Yes, the same router-id/ node-id is used. 

ok, that's what i wanted to know and i would propose to
include the above sentence in this i-d

>>   When link level failure detection is performed by some means other
>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
>>   also optimal for detection of nodal failures.
>>
>>DP: pin point that this is a particular case, it's not a nodal 
>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>>signaling controller failure, 
> 
> Agreed! this is more precise statement. 

ok, thanks

>>note that if this session is 
>>maintained and is used as the IP channel for all messages then 
>>it MAY also be used as "nodal failure"
>>
>>   An implementation may initiate a node-id based Hello 
>>session when it
>>   starts sharing RSVP states with the neighbor or at an earlier time.
>>
>>DP: i don't understand what you mean here
>>
> What we meant here is that an application may not run RSVP Hello session
> all the time. It may initiate one when it has an application (e.g., when
> for GR when it start sharing states with the neighbor. 

this is an interesting statement to be considered in the
scope of this document

>>   Similarly, an implementation may use the IGP topology to determine
>>   the remote node-id which matches an interface address(es) used in
>>   RSVP signaling. These aspects are considered to be a local
>>   implementation decision.
>>
>>DP: how is this possible since you're using the router_id 
>>being the router_address advertized as top level te link 1 in ospf_te
>>
>  
> In Inter-area and inter-AS case, this information is assumed to come via
> configuration. Is this what you meant here? 

the above sentence introduces an issue once the interface
is in failure state, i would provide more details here wrt
to real expectations behind the above paragraph either it
is implementation specific w/o impact on neighbors or it
has and then would suggest some details on the last part.

>>   When a node receives a Hello packet where the destination 
>>IP address
>>   is its local node-id as advertised in the IGP-TE topology, the node
>>   MUST use its node-id in replying to the Hello message. In other
>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>   messages are those derived/contained in the IGP-TE topology.
>>   Furthermore, a node can only run one node-id based RSVP 
>>Hello session
>>   with its neighbor.
>>
>>DP: well here in fact you have a real issue because, a may 
>>have several node_id's on a node, so what you want to say is 
>>"one per node_id pair"
> 
> Yes, in the cases when router is participating multiple topologies (OSPF
> & ISIS). But AFAIK router can only advertsie ONLY one address in a given
> IGP instance. 
> 
> We need to make statement clear for multiple IGP instances case. Is this
> is what you meant? 

exactly

>>   If all interfaces between a pair of nodes are unnumbered, 
>>the optimal
>>   way to use RSVP to detect nodal failure is to run node-id based
>>   Hellos. Similarly, when link level failure detection is 
>>performed by
>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>   also optimal in detecting nodal failures. Therefore, if all
>>   interfaces between a pair of nodes are unnumbered or when 
>>link level
>>   failure detection is performed by some means other than 
>>RSVP Hellos,
>>   a node MUST run node-id based Hellos for node failure detection.
>>
>>DP: this is not true, i can run LMP, but a MUST for the 
>>signaling adj. maintenance
>>
>  
> Yes, we can clarify it in the next version. 

thanks,
-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 05 Feb 2004 23:44:00 +0000
From: "zafar ali" <[email-masked]>
To: <[email-masked]>, "'MPLS wg'" <[email-masked]>
Cc: "'Reshad Rahman'" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>
Subject: Request for comments on a new ID on use of node-id based Hellos 
Date: Thu, 5 Feb 2004 18:40:19 -0500
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C3EC17.82D388D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear MPLS-ers: 
 
We have submitted a new ID on the use of node-id based Hellos for
discussion at the upcoming IETF meeting in Seoul. Abstract of the ID is
as follows: 
 
Abstract: Use of node-id based RSVP Hello messages is implied in a
number of cases, e.g., when data and control plan are separated, when TE
links are unnumbered. Furthermore, when link level failure detection is
performed by some means other than RSVP Hellos, use of node-id based
Hellos is optimal for node failure detection. Nonetheless, this implied
behavior is unclear and this informational draft clarifies use of
node-id based RSVP Hellos.
 
We have uploaded a copy of it at, 
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-node-i
d-based-hello-00.txt
 
Your comments and input on usefulness and applicability will be much
appreciated. 
 
Thanks
 
Regards... Zafar

------=_NextPart_000_0001_01C3EC17.82D388D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>Dear MPLS-ers: </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>We have submitted a new ID on the use of =
node-id based=20
Hellos for discussion at the upcoming IETF meeting in Seoul. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract=20
of the ID is as follows: </SPAN></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract<SPAN=20
class=3D393542523-05022004>: </SPAN>Use of node-id based RSVP Hello =
messages is=20
implied in a number of cases, e.g., when data and control plan are =
separated,=20
when TE links are unnumbered. Furthermore, when link level failure =
detection is=20
performed by some means other than RSVP Hellos, use of node-id based =
Hellos is=20
optimal </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">for=20
node failure detection. </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Nonetheless,=20
this implied behavior is unclear and this </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">informational=20
draft clarifies use of node-id based RSVP Hellos.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>We have uploaded a copy of it at, =
</SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp=
-node-id-based-hello-00.txt">http://multimedia.ecn.purdue.edu/~ali/ietf59=
/draft-ali-ccamp-rsvp-node-id-based-hello-00.txt</A></SPAN></SPAN></SPAN>=
</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>Your comments and input on usefulness and =
applicability=20
will be much appreciated. </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV align=3Dleft>Thanks</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft>Regards... Zafar</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0001_01C3EC17.82D388D0--

Delivery-date: Thu, 05 Feb 2004 15:57:37 +0000
Date: Thu, 05 Feb 2004 10:53:19 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: Reshad Rahman <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart extensions (draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

Reshad Rahman wrote:
> 
> Tthe main comment/question was if we could reuse the RRO object instead 
> of defining a new object to recover the contents of an ERO expansion 
> done prior to control plane restart. Here are two potential issues with 
> reusing RRO:
> - The RRO would contain the full list of nodes whereas the ERO expansion 
> may have been partial. In that situation the downstream node would 
> detect a change in the incoming ERO and may reject the message (the 
> expected behaviour on incoming ERO change seems to be unspecified).

I hope it doesn't do this.

RSVP, by nature is a soft-state protocol.  Implementations should expect 
stuff to change all the time.  When an ERO changes, a node shouldn't 
reject the message.  It should use the new ERO to determine the new 
next-hop.

If the next hop doesn't change, then the node should leave the LSP in 
place and immediately generate a Path refres, so that downstream 
neighbors get the new ERO as soon as possible.

If the next hop changes, then it should be treated identically to what 
would happen in response to a route change with a loose ERO-hop or no ERO.

BTW, I noted that your draft allows an ingress node to recover more 
quickly.  This has been a hole in the GR procedure.  An ingress node 
that is computing an ERO can't re-compute that ERO until routing 
reconverges, and when it does so, there is no guarantee that it will 
compute the same ERO as before the failure.  It could store the ERO in 
non-volatile storage, but that can be problematic if there are thousands 
of LSPs originating.

Using the recovery-ERO object solves this.  The ingress node can then 
send out a Path (using the preserved forwarding state to know what the 
next-hop is) using an empty (or near-empty) recovery ERO.  The next-hop 
can then send back an immediate Resv containing an appropriate 
recovery-ERO, which the ingress node can use while waiting for routing 
to reconverge.  (Once routing reconverges and recovery completes, of 
course, it will want to compute its own ERO and possibly do a 
make-before-break to the new path if it ends up being better than the 
recovered path.)

> - RRO uses Class-Number of form 0bbbbbbb, so if the downstream node 
> doesn't support RRO, the whole message is rejected.

If RRO isn't supported, then the ingress node will know about, since the 
LSP won't come up in the first place.

If this happens, then the upstream node will know that it can't use this 
method of ERO recovery.  Functionally, this is really no different from 
a node not supporting the recovery-ERO class.

Note that other RSVP extensions (like Fast Reroute) also require RRO 
support as a prerequisite.

-- David

Delivery-date: Thu, 05 Feb 2004 01:50:58 +0000
Date: Wed, 04 Feb 2004 20:44:45 -0500
From: Reshad Rahman <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Looking for comments on draft for RSVP Graceful Restart extensions (draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

This is a multi-part message in MIME format.
--------------080108010402030403020308
Content-Type: multipart/alternative;
 boundary="------------010305030707090600090902"

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

Hi,

This draft was presented at the MPLS WG during IETF 58 and there was 
some interest. However the recommendation was to move the draft to CCAMP. 

Tthe main comment/question was if we could reuse the RRO object instead 
of defining a new object to recover the contents of an ERO expansion 
done prior to control plane restart. Here are two potential issues with 
reusing RRO:
- The RRO would contain the full list of nodes whereas the ERO expansion 
may have been partial. In that situation the downstream node would 
detect a change in the incoming ERO and may reject the message (the 
expected behaviour on incoming ERO change seems to be unspecified).
- RRO uses Class-Number of form 0bbbbbbb, so if the downstream node 
doesn't support RRO, the whole message is rejected.

The draft also proposes a mechanism for a restarting node to detect 
whether its downstream neighbour is also restarting.

Comments welcome.

Regards,
Reshad.

-------- Original Message --------
Subject: 	I-D ACTION:draft-rahman-ccamp-rsvp-restart-extensions-00.txt
Date: 	Wed, 04 Feb 2004 15:41:46 -0500
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RSVP Graceful Restart Extensions
	Author(s)	: R. Rahman
	Filename	: draft-rahman-ccamp-rsvp-restart-extensions-00.txt
	Pages		: 9
	Date		: 2004-2-4
	
This document describes the extensions needed by certain 
             features for the purpose of RSVP Graceful Restart (defined 
             in[RFC3473]). One of these extensions refers to the ability of 
             a node to recover the ERO in the case it has performed an ERO 
             expansion before control plane restart. Also a small 
             modification is proposed in the basic procedure to support 
             simultaneous multiple node restarts in a network. 
             Specifically, a node should use a non-zero Recovery Time while 
             in the recovery phase. This allows a node to determine at 
             restart time if any of its neighbors has previously restarted 
             and it is currently in the recovery phase.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt

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

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
This draft was presented at the MPLS WG during IETF 58 and there was
some interest. However the recommendation was to move the draft to
CCAMP.&nbsp; <br>
<br>
Tthe main comment/question was if we could reuse the RRO object instead
of defining a new object to recover the contents of an ERO expansion
done prior to control plane restart. Here are two potential issues with
reusing RRO:<br>
- The RRO would contain the full list of nodes whereas the ERO
expansion may have been partial. In that situation the downstream node
would detect a change in the incoming ERO and may reject the message
(the expected behaviour on incoming ERO change seems to be unspecified).<br>
- RRO uses Class-Number of form 0bbbbbbb, so if the downstream node
doesn't support RRO, the whole message is rejected.<br>
<br>
The draft also proposes a mechanism for a restarting node to detect
whether its downstream neighbour is also restarting.<br>
<br>
Comments welcome.<br>
<br>
Regards,<br>
Reshad.<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>I-D ACTION:draft-rahman-ccamp-rsvp-restart-extensions-00.txt</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Wed, 04 Feb 2004 15:41:46 -0500</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td>IETF-Announce: ;</td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RSVP Graceful Restart Extensions
	Author(s)	: R. Rahman
	Filename	: draft-rahman-ccamp-rsvp-restart-extensions-00.txt
	Pages		: 9
	Date		: 2004-2-4
	
This document describes the extensions needed by certain 
             features for the purpose of RSVP Graceful Restart (defined 
             in[RFC3473]). One of these extensions refers to the ability of 
             a node to recover the ERO in the case it has performed an ERO 
             expansion before control plane restart. Also a small 
             modification is proposed in the basic procedure to support 
             simultaneous multiple node restarts in a network. 
             Specifically, a node should use a non-zero Recovery Time while 
             in the recovery phase. This allows a node to determine at 
             restart time if any of its neighbors has previously restarted 
             and it is currently in the recovery phase.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt">http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt</a>

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

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

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
In the body type:
	"FILE /internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-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.

</pre>
</body>
</html>

--------------010305030707090600090902--

--------------080108010402030403020308
Content-Type: Message/External-body;
 name="draft-rahman-ccamp-rsvp-restart-extensions-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-rahman-ccamp-rsvp-restart-extensions-00.txt"

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

--------------080108010402030403020308--

Delivery-date: Thu, 05 Feb 2004 01:02:43 +0000
Date: Thu, 05 Feb 2004 02:02:30 +0100
From: [email-masked]
To: Yoshihiko SUEMURA <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Protection object in resv message

hi, see in-line

Yoshihiko SUEMURA wrote:

> Hi Dimitri,
> 
> Please see inline.
> 
> On Sun, 01 Feb 2004 15:39:33 +0100,
> [email-masked] wrote:
> 
> 
>>hi, see in-line
>>
>>Yoshihiko SUEMURA wrote:
>>
>>>P&R Design Team,
>>>
>>>In the 1:1/Shared Mesh Restoration described in
>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
>>>secondary LSP is done only by a Path message. The Protection object is
>>>carried only in a Path message.
>>>However, I think a Resv message should also carry the Protection object.
>>>
>>>Consider the following case.
>>>
>>>   A-----------B
>>>    \         /
>>>     C-------D
>>>    /         \
>>>   E           F
>>>
>>>A-B:     Primary LSP
>>>A-C-D-B: Secondary LSP
>>>E-C-D-F: Extra (preemptable) LSP
>>>
>>>Activating the Secondary LSP using only a Path message may cause
>>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
>>>LSP. 
>>
>>here i would agree that there is a condition on the next_hop
>>to delete the extra_lsp state before activating the xc for
>>the secondary lsp and in order to guarantee this commit of
>>the resources activation may be done upon resv reception
>>
>>also the use of hard preemption before committing this
>>operation decreases (if not completely elevates if used
>>to commit action when received from D in this example)
>>the time occurrence of this transient state:
>>
>>- PathErr with PAth_State_Removed flag towards E and a PathTear
>>   to the destination F
>>- or a PathErr with Path_State_Removed flag towards F and a
>>   PathTear towards E
>>
>>therefore there are other faster triggers for this purpose
>>the issue being at the end to either perform this operation
>>as fast as possible when reaching the last common node,
>>or simply delete in downstream direction and commit along
>>the upstream direction as said above (there are more complex
>>cases where this might be at the end more easy to process)
>>
>>
>>>This can be prevented by applying a two-way activation scheme using
>>>both Path and Resv messages. 
>>
>>nothing prevent this from the above (the paragraph that
>>describes this doesn't say commit at the data plane this
>>is left out to the implementation) some clarification in
>>the document are certainly needed here
>>
>>
>>>You can delete the Extra LSP by the Path
>>>message, and activate the Secondary LSP by the Resv message. 
>>
>>you may want to apply this activation scheme, in such a case
>>all the nodes would have their extra-traffic lsp deleted
>>through the downstream path message
> 
> 
> Yes. This is what I want to apply. I want to delete all the
> extra-traffic LSPs through the downstream Path message, and then,
> activate the secondary LSP through the upstream Resv message.
> 
> 
>>>However, if the Resv message for activation does not carry the
>>>Protection object, it cannot be distinguished from a refresh Resv
>>>message. This still causes unintended connection in the following case.
>>>
>>>(1) At node C, a crossconnect for the Extra LSP is deleted when
>>>receiving a Path message.
>>>  
>>>(2) Then, if node C receives a refresh Resv message from D, it sets up a
>>>crossconnect for the Secondary LSP because it cannot distinguish the
>>>refresh Resv message from a Resv message for activation.
>>
>>referring to 2961 p12/13 don't see how see this could happen,
>>would you clarify, in order to address this point in case, also
>>the resv is considered implicitly here as trigger message
> 
> 
> After (1), node C waits for the upstream Resv message for activating the
> secondary LSP. However, it may receive a refresh Resv message (refresh
> for a Resv message for PROVISIONING the secondary LSP) from D before
> receiving the Resv for activation. Currently, C cannot distinguish it
> from the Resv for activation because there is no difference between
> their formats. This may trigger C to activate the secondary LSP
> unintentionally before the downstream nodes delete their extra-traffic
> LSPs.

by re-reading it was also my understanding when performing the xc
on the resv we got here a transient issue that may appear to be
problematic as the length of the path in terms of number of hops
increases (since the latency increases, the probability to be
impacted by this also increases), so would the following text
address your concern:

"In certain circumstances, it MAY be desirable to perform the
activation of the secondary LSP in the upstream direction (Resv
trigger message) instead of using the default downstream method.
In this case, and in order to avoid any mis-ordering and any mis-
interpretation between a refresh Resv and a trigger Resv message
at intermediate nodes along the secondary LSP, upon reception of
the Path message, the egress node MAY include the PROTECTION
object in the Resv message. The latter is then processed on a hop
by hop basis to activate the secondary LSP until reaching the
ingress node. The PROTECTION object included in the Path message
MUST be set as specified in Section 8.3 and Section 9.3. The
upstream activation behavior SHOULD be configurable on a local
basis."

hope this addresses the concern,
thanks,
- dimitri.
> Thank you,
> 
> Yoshihiko
> 
> 
>>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
>>>causes unintended connection between the Secondary LSP and the Extra LSP.
>>>
>>>As a solution for the above problem, I propose to add the Protection
>>>object to a Resv message. The unintended connection can be prevented
>>>because you can distinguish a Resv message for activation from a refresh
>>>Resv message by watching the S bit.
>>
>>suggest to first clarify the previous point,
>>
>>thanks,
>>- dimitri.
>>
>>
>>>Best regards,
>>>
>>>Yoshihiko
>>>
>>>-----------------------------------------------------------------
>>>Yoshihiko SUEMURA 
>>>
>>>NEC Corporation
>>>E-mail: [email-masked]
>>>
>>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>E-mail : [email-masked]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
> 
> 
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> NEC Corporation
> E-mail: [email-masked]
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Wed, 04 Feb 2004 22:12:24 +0000
Date: Wed, 04 Feb 2004 17:06:33 -0500
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: New draft on Inter-area/AS MPLS TE: draft-vasseur-ayyangar-inter-area-AS-TE-00.txt
Cc: arthi Ayyangar <[email-masked]>, [email-masked], [email-masked]

--=====================_197048580==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

During IETF-58, two drafts related to Inter-area and Inter-AS MPLS TE were 
presented:
	- draft-vasseur-inter-AS-TE (JP Vasseur / Raymond Zhang)
	- draft-ayyangar-inter-region-te (Arthi Ayyangar)
It was agreed with the WG to merge the two drafts which should cover 
solutions for both inter-area and inter-AS MPLS TE and for both packet and 
non-packet TE LSPs. Here is the result of this merge.

In a nutshell, the draft proposes three TE LSPs types (Contiguous, Stitched 
and Nested) and two inter-area/AS TE path computation methods (Per-area/AS, 
distributed PCEs). We tried to also describe the applicability of each TE 
LSP type and path computation method as well as their respective pros and 
cons with regards to several aspects (path optimality, reoptimization, 
diverse path computation, DS-TE, hierarchy, policy control, ...).

Just a side note regarding the terminology: the comment was made several 
times that the PCS terminology was confusing and may be interpreted as 
"off-line". Hence this has been changed for PCE (Path Computation Element), 
where the PCE may be an ABR or an ASBR. This applies to one of the 
distributed path computation method described in this draft.

Several SPs expressed an interest in this draft.

Comments are obviously more than welcome !

We'd like to specifically thank Adrian Farrel for his contribution to this 
merged draft.

JP.

--=====================_197048580==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt"

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
                                                                        =20
                                                     JP Vasseur (Editor)=20
                                                     Cisco Systems, Inc. =20
                                                 Arthi Ayyangar (Editor)=20
                                                        Juniper Networks=20
IETF Internet Draft=20
Expires: August, 2004                                               =20
                                                         February, 2004=20
=20
=20
=20
                                    =20
                                    =20
              draft-vasseur-ccamp-inter-area-AS-TE-00.txt=20
                                    =20
                                    =20
            Inter-area and Inter-AS MPLS Traffic Engineering=20
=20
=20
=20
Status of this Memo=20
=20
This document is an Internet-Draft and is in full conformance with all=20
provisions of Section 10 of RFC2026. Internet-Drafts are=20
Working documents of the Internet Engineering Task Force (IETF), its=20
areas, and its working groups.  Note that other groups may also=20
distribute working documents as Internet-Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six months=20
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as reference material=20
or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.txt.=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20

 =20
 Vasseur and Ayyangar                                                1=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Abstract=20
=20
This document proposes a set of signaling and routing mechanisms to=20
establish and maintain generalized (packet and non-packet) MPLS Traffic=20
Engineering Label Switched Path (MPLS TE LSPs) that span multiple areas=20
or Autonomous Systems.. Each mechanism is described along with its=20
applicability to the set of requirements.=20
=20
Conventions used in this document=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20
document are to be interpreted as described in RFC 2119 [RFC2119].=20
=20
=20
Content=20
=20
1. Terminology=20
2. Introduction=20
3. General assumptions=20
4. Notion of contiguous, nested and stitched TE LSP=20
5. Scenario 1: next-hop resolution during inter-area/AS TE LSP set=20
up(per-area/AS path computation)=20
5.1 Example with an inter-area TE LSP (based on the assumption=20
described in section 3).=20
5.1.1 Case 1: T1 is a contiguous TE LSP=20
5.1.2 Case 2: T2 is a stitched or nested TE LSP=20
5.1.3 Processing of the Resv message (common procedure for contiguous=20
and stitched/nested LSPs)=20
5.2 Example with an inter-AS TE LSP (based on the assumption described=20
in section 3).=20
5.2.1 Case 1: T1 is a contiguous TE LSP=20
5.2.2 Case 2: T1 is a stitched or nested TE LSP=20
5.3 Signaling specifics with TE LSP stitching for packet LSPs=20
6. Scenario 2: end to end shortest path computation=20
6.1 Introduction and definition of an optimal path=20
6.2 Notion of PCE (Path Computation Element)=20
6.3 Dynamic PCE discovery=20
6.4 PCE selection=20
6.5 LSR-PCE signaling protocol=20
6.6 Computation of an optimal end to end TE LSP path=20
6.7 Path optimality=20
6.8 Diverse end to end path computation=20
7. Mode of operation of MPLS Traffic Engineering Fast Reroute for=20
inter-area/AS TE LSPs=20
7.1 Support of MPLS TE Fast Reroute for a contiguous inter-area/AS TE=20
LSP=20
7.1.1 Failure of a network element within an area/AS=20
7.1.2 Failure of an inter-AS link=20
7.1.3 Failure of an ABR or an ASBR node=20
=20
 Vasseur and Ayyangar                                                2=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
7.1.4 Procedure during MPLS TE Fast Reroute=20
7.2 Support of MPLS TE Fast Reroute for a stitched/nested TE LSP=20
7.2.1 Failure of an inter-AS link=20
7.2.2 Failure of an ABR or an ASBR node=20
7.3 Failure handling of inter-AS TE LSP=20
8. Reoptimization of an inter-area/AS TE LSP=20
8.1 Contiguous TE LSPs=20
8.1.1 Per-area/AS path computation (scenario 1)=20
8.1.2 End to end shortest path computation (scenario 2)=20
8.2 Stitched or nested (non-contiguous) TE LSPs=20
9 Routing traffic onto inter-area/AS TE LSPs=20
10 Evaluation criteria and applicability=20
10.1 Path optimality=20
10.2 Reoptimization=20
10.3 Support of MPLS Traffic Engineering Fast Reroute=20
10.4 Support of diversely routed paths=20
10.5 Diffserv-aware MPLS TE=20
10.6 Hierarchical LSP support=20
10.7 Policy Control at the AS boundaries=20
10.8 Inter-AS MPLS TE Management=20
10.9 Confidentiality=20
11 Scalability and extensibility=20
12 Security Considerations=20
13 Intellectual Property Considerations=20
14 Acknowledgments=20
=20
References=20
=20
=20
=20
=20
=20
=20
=20

=20
 Vasseur and Ayyangar                                                3=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
1.      Terminology=20
 =20
LSR: Label Switch Router=20
=20
LSP: MPLS Label Switched Path=20
=20
PCE: Path Computation Element. An LSR in charge of computing TE LSP=20
path for which it is not the Head-end. For instance, an ABR (inter-
area) or an ASBR (Inter-AS) can play the role of PCE.=20
    =20
PCC: Path Computation Client (any head-end LSR) requesting a path=20
computation from the Path Computation Element.=20
    =20
Local Repair: local protection techniques used to repair TE LSPs=20
quickly when a node or link along the LSPs path fails.=20
=20
Protected LSP: an LSP is said to be protected at a given hop if it has=20
one or multiple associated backup tunnels originating at that hop.=20
=20
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing=20
over a common facility.=20
=20
PLR: Point of Local Repair. The head-end of a bypass tunnel.=20
=20
MP: Merge Point. The LSR where bypass tunnels meet the protected LSP.=20
=20
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which=20
bypasses a single link of the protected LSP.=20
=20
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which=20
bypasses a single node of the protected LSP.=20
=20
Fast Reroutable LSP: any LSP for which the "Local protection desired"=20
bit is set in the Flag field of the SESSION_ATTRIBUTE object of its=20
Path messages or signaled with a FAST-REROUTE object.=20
=20
CSPF: Constraint-based Shortest Path First.=20
=20
Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do =20
not reside within the same Autonomous System (AS), or whose head-end=20
LSR and tail-end LSR are both in the same AS but the TE  LSP=92s path =20
 may be across different ASes. Note that this definition also applies=20
to TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes=20
(BGP confederations).=20
=20
Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end=20
LSR do not reside in the same area or both the head-end and tail end=20
LSR reside in the same area but the TE LSP transits one or more=20
different areas along the path.=20
=20
=20
 Vasseur and Ayyangar                                                4=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
ABR Routers: routers used to connect two IGP areas (areas in OSPF or=20
L1/L2 in IS-IS)=20
=20
Interconnect routers or ASBR routers: routers used to connect together=20
ASes of a different or the same Service Provider via one or more Inter-
AS links.=20
=20
Boundary LSR: a boundary LSR is either an ABR in the context of inter-
area MPLS TE or an ASBR in the context of inter-AS MPLS TE.=20
=20
TED: MPLS Traffic Engineering Database=20
=20
In this document, the term inter-area/AS TE LSP refers to an inter-area=20
or an inter-AS MPLS Traffic Engineering Label Switched Path.=20
=20
The notion of =91=91TE LSP nesting=92=92 refers to the ability to carry one=
 or=20
more inter-area/AS TE LSPs within another intra-area/AS TE LSP by using=20
the MPLS label stacking property at the intra-area/AS outer TE LSP=92s=20
head-end LSR. On the other hand, =91=91stitching a TE LSP=92=92 means to=
 split an=20
inter-area/AS TE LSP and insert a different intra-area/AS LSP, into the=20
split. This implies a label swap operation at the stitching point (head-
end of the intra-area/AS TE LSP). Similar to [LSP_HIER], in the context=20
of this document as well, the term FA-LSP always implies one or more=20
LSPs nested within another LSP using the label stack construct. We use=20
the term =91=91LSP segment=92=92 in the context of LSP stitching (when one=
 LSP is=20
split and another LSP is inserted into the split).=20
=20
=20
2.      Introduction=20
=20
Considering the set of requirements for inter-area and inter-AS Traffic=20
Engineering respectively listed in [INTER-AREA-TE-REQS] and [INTER-AS-
TE-REQS], this document proposes a set of mechanisms to establish and=20
maintain MPLS Traffic Engineering Label Switched Paths that span=20
multiple areas in the context of inter-area MPLS TE or multiple ASes or=20
sub-ASes (with BGP confederations) in the context of inter-AS MPLS TE.=20
The mechanisms proposed in this document could also be applicable to=20
MPLS TE domains other than areas and ASes as well.=20
=20
According to the wide set of requirements defined in [INTER-AS-TE-REQS]=20
and [INTER-AREA-TE-REQS], coming up with a single solution covering all=20
the requirements is certainly possible but may not be desired: indeed,=20
as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios=20
is quite large and designing a solution addressing the super-set of all=20
the requirements would lead to provide a rich set of mechanisms not=20
required in several cases. Depending on the deployment scenarios of a=20
SP, certain requirements stated above may be strict while certain other=20
requirements may be relaxed. =20
=20
There are two aspects to a TE LSP setup: the TE LSP path computation=20
and the signaling. There are different ways in which path computation=20
=20
 Vasseur and Ayyangar                                                5=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
for an inter-area/AS TE LSP could be done. For example, if the=20
requirement is for an end-to-end constraint-based shortest path for the=20
inter-area/AS TE LSP, then a mechanism using one or more distributed=20
PCEs could be used to obtain an optimal path across different=20
areas/ASes. Alternatively, one could also use some static or discovery=20
mechanisms to determine the next boundary LSR per area/AS as the inter-
area/AS TE LSP is being signaled. Other offline mechanisms for path=20
computation are not precluded either. Depending on the requirements of=20
the SP, one may adopt either of these techniques for inter-area/AS path=20
computation. Hence, once the TE LSP path is obtained, this document=20
provides three different types of inter-area/inter-AS TE LSP which are=20
signaled by different means: contiguous, nested or stitched. Depending=20
on the needs of the SP networks, one may choose either of these=20
mechanisms to signal the TE LSP. In case of inter-AS (inter-provider)=20
TE LSP setup, since different SPs may have different needs and may=20
choose different TE policies in their network, this document provides a=20
way to communicate some requirements that the head-end LSR originating=20
the TE LSP may have for the ASes that the TE LSP transit. Also, with TE=20
LSPs crossing AS boundaries or administrative domains, it is assumed=20
that there will be some form of Policy control at the administrative=20
boundaries.=20
=20
In section 11,  the applicability and evaluation criteria of each=20
solution proposed in this document with respect to the set of=20
requirements defined in [INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS] are=20
analyzed.=20
=20
3.      General assumptions=20
=20
In the rest of this document, we make the following set of assumptions:=20
=20
1) Assumptions common to inter-area and inter-AS TE:=20
=20
- Each area or AS in all the examples below is assumed to be capable of=20
doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP-
TE). An AS may itself be composed of several other sub-AS(es) (BGP=20
confederations) or areas/levels.=20
=20
- The inter-area/AS LSPs are signaled using RSVP-TE ([RSVP-TE]).=20
=20
- The path (ERO) for the inter-area/AS TE LSP traversing multiple=20
areas/ASes may be signaled  as a set of (loose and/or strict) hops. The=20
hops may identify:=20
        - The complete strict path end to end across different=20
        areas/ASes=20
        - The complete strict path in the source area/AS followed by=20
        boundary LSRs (and domain identifiers, e.g. AS numbers)=20
        - The complete list of boundary LSRs along the path=20
        - The current boundary LSR and the LSP destination=20
=20

=20
 Vasseur and Ayyangar                                                6=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
In this case, the set of (loose or strict) hops can either be=20
statically configured on the Head-end LSR or dynamically computed. In=20
the former case, the resulting path is statically configured on the=20
Head-end LSR. In the latter case (dynamic computation), two methods=20
described in this document can be used:=20
        - A distributed path computation involving some PCEs (e.g=20
        ABR/ASBR) resulting in globally optimal path consisting of=20
        strict and/or loose hops,=20
        - Some Auto-discovery mechanism based on BGP and/or IGP=20
        information yielding the next-hop boundary LSR (ABR/ASBR) along=20
        the path as the LSP is being signaled, along with crankback=20
        mechanisms.=20
=20
- Furthermore, the boundary LSRs are assumed to be capable of=20
performing local path computation for expansion of a loose next-hop in=20
the signaled ERO if the path is not signaled by the head-end LSR as a=20
set of strict hops or if the strict is for example an AS number. This=20
can be done by performing a CSPF computation to that loose hop, instead=20
of to the LSP destination or by making use of some PCEs. In any case,=20
no topology or resource information needs to be distributed between=20
areas/ASes, which is critical to preserve IGP/BGP scalability.=20
=20
- The paths for the intra-area/AS FA-LSPs or LSP segments or for a=20
contiguous TE LSP within the area/AS, may be pre-configured or computed=20
dynamically based on the arriving inter-area/AS LSP setup request;=20
depending on the requirements of the transit area/AS. Note that this=20
capability is explicitly specified as a requirement in [INTER-AS-TE-
REQS]. When the paths for the FA-LSPs/LSP segments are pre-configured,=20
the constraints as well as other parameters like local protection=20
scheme for the intra-area/AS FA-LSP/LSP segment are also pre-
configured. Some local algorithm can be used on the head-end LSR of a=20
FA-LSP to dynamically adjust the FA-LSP bandwidth based on the=20
cumulative bandwidth requested by the inter-area/AS TE LSPs. It is=20
RECOMMENDED  to use a threshold triggering mechanism to avoid constant=20
bandwidth readjustment as inter-area/AS TE LSPs are set up and torn=20
down.=20
=20
- While certain constraints like bandwidth can be used across different=20
areas/ASes, certain other TE constraints like resource affinity, color,=20
metric, etc. as listed in [RFC2702] could be translated at areas/ASes=20
boundaries. If required, it is assumed that, at the area/AS boundary=20
LSRs, there will exist some sort of local mapping based on offline=20
policy agreement, in order to translate such constraints across area/AS=20
boundaries. It is expected that such an assumption particularly applies=20
to inter-AS TE: for example, the local mapping would be similar to the=20
Inter-AS TE Agreement Enforcement Polices stated in [INTER-AS-TE-
REQTS].=20
=20
- When an area/AS boundary LSR at the exit of an area/AS receives a TE=20
LSP setup request (Path message) for an inter-area/AS TE LSP, then if=20
this LSP had been nested or stitched at the entry area/AS boundary LSR,=20
=20
 Vasseur and Ayyangar                                                7=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
then this exit boundary LSR can determine the corresponding FA-LSP or=20
LSP segment from the received Path message. The signaling mechanism=20
used to signal an inter-area/AS TE LSP being transported either over a=20
FA-LSP or LSP segment is similar to that described in [LSP-HIER]. The=20
way to identify an unnumbered FA is described in [RSVP-UNNUM]. The same=20
mechanisms are used here.=20
=20
2) Example of topology for the inter-area TE case:=20
=20
<---area1---><--area0--><----area2----->=20
 ---------ABR1-----------ABR=921-------=20
 |      /   |              |  \     |=20
R0--X1--    |              |   X2---X3--R1=20
 |          |              |  /     |=20
 ---------ABR2-----------ABR=922------=20
=20
- ABR1, ABR2, ABR=921 and ABR=922 are ABRs=20
- X1: an LSR in area 1=20
- X2, X3: LSRs in area 2=20
Note:=20
- The terminology used in the example corresponds to OSPF but the set=20
of mechanisms proposed in this document equally applies to IS-IS.=20
- Just a few routers in each area are depicted in the diagram above for=20
the sake of simplicity.=20
=20
3) Example of topology for  the inter-AS TE case:=20
=20
We will consider the following general case, built on a superset of the=20
various scenarios defined in [INTER-AS-TE-REQS]:=20
=20
=20
     <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> =20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9----R6 =20
      |\     \ |       / |   / |   / |          |      |=20
      | \     ASBR2---/ ASBR5  | --  |          |      |  =20
      |  \     |         |     |/    |          |      |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10--
                                                    -
                                                    -
                                                    --R7---CE2 =20
                =20
      <=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP(LSR to LSR)=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D>=20
or=20
=20
<=3D=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP (CE to ASBR =3D>=20
=20
or=20
=20
<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP (CE to=
 CE)=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>=20
=20
The diagram above covers all the inter-AS TE deployment cases described=20
in [INTER-AS-TE-REQS].=20
=20
 Vasseur and Ayyangar                                                8=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Assumptions:=20
=20
- Three interconnected ASes, respectively AS1, AS2, and AS3. Note that=20
AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS],=20
=20
- The various ASBRs are BGP peers, without any IGP running on the=20
single hop link interconnecting the ASBRs,=20
=20
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE=20
extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are=20
TE enabled,=20
=20
- Each AS can be made of several areas. In this case, the TE LSP will=20
rely on the inter-area TE techniques to compute and set up a TE LSP=20
traversing multiple IGP areas. For the sake of simplicity, each routing=20
domain will be considered as single area in this document, but the=20
solutions described in this document does not prevent the use of multi-
area techniques.=20
=20
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6=20
in AS3,=20
=20
- An inter-AS TE LSP T2 originated at CE1 (connected to R0) and=20
terminating at CE2 (connected to R7),=20
=20
- A set of backup tunnels:=20
        =20
        o B1 from X1 to ASBR4 following the path X1-ASBR2-ASBR4 and=20
        protecting against a failure of the ASBR1 node,=20
        =20
        o B2 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4=20
        and protecting against a failure of the ASBR1-ASBR4 link,=20
        =20
        o B3 from ASBR1 to R3 following the path ASBR1-ASBR2-ASBR3-
        ASBR6-ASBR5-R3 and protecting against a failure of the ASBR4=20
        node.=20
        =20
        o B4 from ASBR1 to ASBR7 following the path ASBR1-ASBR2-ASBR3-
        ASBR6-R4-ASBR7 and protecting against a failure of the ASBR4=20
        node.=20
        =20
- In the example above, ASBR1, ASBR8 and ASBR9 could have the function=20
of PCE for respectively the ASes 1, 2 and 3 (the notion of PCE applies=20
to the scenario 2 of this document).=20
=20
4.      Notion of contiguous, nested and stitched TE LSPs=20
=20
A contiguous TE LSP is defined as a TE LSP spanning multiple IGP=20
areas/levels or ASes, which must be considered as a unique end-to-end=20
TE LSP. By contrast, a stitched or nested TE LSP is made of up multiple=20
=20
 Vasseur and Ayyangar                                                9=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
LSP pieces within each area/AS which are either stitched or nested=20
together at area/AS boundaries to form an inter-area/AS TE LSP.=20
=20
In case of a contiguous TE LSP, it is expected to provide more control=20
at the head-end LSR that originates the inter-area/AS TE LSP. On the=20
other hand, in case of the stitched or nested TE LSP, the control of=20
the TE LSP is performed on a per-area or per-AS basis. This difference=20
is possible because in the latter case (stitching and nesting) the=20
intra-area/AS TE LSP is a different TE LSP from the inter-area/AS TE=20
LSP. The term =91LSP segment=92 is used when one TE LSP is split and=20
another LSP is inserted into the split. And the term FA-LSP is used=20
when one or more TE LSPs are carried within another LSP. Both stitched=20
and nested TE LSPs are signaled using mechanisms defined in [LSP-HIER].=20
=20
While signaling a contiguous TE LSP is different from signaling a=20
stitched TE LSP, in the forwarding plane at the boundary LSR, both=20
involve a label swap operation. However, nesting multiple inter-area/AS=20
LSPs into another intra-area/AS LSP, is done using the MPLS label=20
stacking construct.=20
=20
It is desirable in mixed environments making use of different=20
techniques (contiguous, stitched or nested TE LSPs) to provide the=20
ability for the head-end LSR of the inter-area/AS TE LSP to signal its=20
requirement regarding the nature of the inter-area/AS TE LSP=20
(contiguous, stitched, nested) on a per-LSP basis. For the sake of=20
illustration, a Head-end LSR, may desire to prevent stitching or=20
nesting for a traffic sensitive inter-area/AS TE LSPs that require a=20
path control on the head-end LSR. On the other hand, the head-end LSR=20
may decide to avoid any tight control.[LSP-ATTRIBUTES] defines the=20
format of the attribute flags TLV included in the LSP-ATTRIBUTE object=20
carried in an RSVP Path message which is used for the purpose of=20
signaling the inter-area/AS TE LSP characteristics.=20
=20
The following bits of the attribute flags TLV is defined for this=20
purpose:=20
=20
0x01: Contiguous LSP required bit: this flag is set by the head-end LSR=20
that originates the inter-AS/area TE LSP if it desires a contiguous=20
end-to-end TE LSP. When set, this indicates that a boundary LSR MUST=20
not perform any stitching or nesting on the TE LSP and the TE LSP MUST=20
be routed as any other TE LSP (it must be contiguous end to end). When=20
this bit is cleared, a boundary LSR can decide to perform stitching or=20
nesting. A mid-point LSR not supporting contiguous TE LSP MUST send a=20
Path Error message upstream with error sub-code=3D17 =91=91Contiguous LSP=
 type=20
not supported=92=92. This bit MUST not be modified by any downstream node.=
=20
 =20
Additionally, in case of a non-contiguous inter-area/AS LSP, if the=20
inter-area/AS TE LSP is being stitched into another intra-area/AS TE=20
LSP, it is sometimes required to explicitly signal the stitching=20
behavior in the =91=91intra-area/AS=92=92 LSP segment within that area/AS.=
 The=20
following bit of the attributes flags TLV is defined for this purpose:=20
=20
 Vasseur and Ayyangar                                               10=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
0x02: LSP stitching required bit: this flag is set by the boundary LSR=20
for the intra-area/AS LSP segment which is local to that area/AS. This=20
flag SHOULD not be modified by any other LSR in that area/AS. If the=20
egress LSR for the intra-area/AS LSP segment does not understand this=20
flag then it will simply forward the object unmodified and will send a=20
Path Error message upstream with error sub-code=3D16.=20
=20
Further signaling details for TE LSP stitching are described in section=20
5.3.=20
=20
Note: in some cases, it may be desirable for the head-end LSR to exert=20
some control on the ability for the boundaries LSRs to make use of=20
crankback. See [CRANKBACK] for the definition of those bits. When=20
crankback is allowed, the boundary LSR can either decide to forward the=20
Path Error message upstream to the head-end LSR or try to select=20
another egress boundary LSR (which is also referred to as crankback).=20
When crankback is not allowed, a boundary LSR, when receiving a Path=20
Error message from a downstream boundary LSR MUST propagate the Path=20
Error message up to the inter-area/AS head-end LSR.=20
=20
5.      Scenario 1: Next-hop resolution during inter-area/AS TE LSP set=20
   up (per-area/AS path computation)=20
=20
Regardless of whether the inter-area/AS TE LSP is a contiguous or=20
stitched or nested TE LSP, a similar set of mechanisms for local TE LSP=20
path computation (next hop resolution) and setup can be used.=20
=20
When an ABR/ASBR receives a Path message with a loose next-hop in the=20
ERO, then it carries out the following actions:=20
=20
1) It checks if the loose next-hop is accessible via the TED. If the=20
loose next-hop is not present in the TED, then it will check if the=20
next-hop at least has IP reachability (via IGP or BGP). If the next-hop=20
is not reachable, then the LSR will be unable to propagate the Path=20
message any further and will send back a PathErr upstream. If the next-
hop is reachable, then it will find an ABR/ASBR to get to the next-hop.=20
In the absence of an auto-discovery mechanism, the ABR/ASBR should be=20
the loose next-hop in the ERO and hence should be accessible via the=20
TED, otherwise path computation for the inter-area/AS TE LSP will fail.=20
=20
2) If the next-hop boundary LSR is present in the TED.=20
=20
        a) Case of a contiguous TE LSP (=91=91Contiguous LSP required bit=92=
=92=20
        of the attribute flags TLV included in the LSP-ATTRIBUTE object=20
        is set). In that case, the ABR/ASBR just performs an ERO=20
        expansion after having computed the path to the next loose hop=20
        (ABR/ASBR) that obeys the set of required constraints. If no=20
        path satisfying the set of constraints can be found then a Path=20
        Error MUST be sent for the inter-area/AS TE LSP.=20
=20
=20
 Vasseur and Ayyangar                                               11=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
        b) Case of stitched or nested LSP (=91=91Contiguous LSP required=20
        bit=92=92 of the attribute flags TLV included in the LSP-ATTRIBUTE=
=20
        object is cleared).=20
        =20
                i) if this ABR/ASBR (receiving the LSP setup request)=20
                is a candidate LSR for intra-area FA-LSP/LSP segment=20
                setup, and if there is no FA-LSP/LSP segment from this=20
                LSR to the next-hop boundary LSR (satisfying the=20
                constraints) it SHOULD signal a FA-LSP/LSP segment to=20
                the next-hop boundary LSR. If pre-configured FA-LSP(s)=20
                or LSP segment(s) already exist, then it SHOULD try to=20
                select from among those intra-area/AS LSPs. Depending=20
                on local policy, it MAY signal a new FA-LSP/LSP segment=20
                if this selection fails. If the FA-LSP/LSP segment is=20
                successfully signaled or selected, it propagates the=20
                inter-area/AS Path message to the next-hop following=20
                the procedures described in [LSP-HIER]. If, for some=20
                reason the dynamic FA-LSP/LSP segment setup to the=20
                next-hop boundary LSR fails, a PathErr is sent upstream=20
                for the inter-area/AS LSP. Similarly, if selection of a=20
                preconfigured FA-LSP/LSP segment fails and local policy=20
                prevents dynamic FA-LSP/LSP segment setup, then a=20
                PathErr is sent upstream for the inter-area/AS TE LSP.=20
=20
                ii) If, however, this boundary LSR is not a FA-LSP/LSP=20
                segment candidate, then it SHOULD simply compute a CSPF=20
                path up to the next-hop boundary LSR carry out an ERO=20
                expansion to the next-hop boundary LSR) and propagate=20
                the Path message downstream. The outgoing ERO may be=20
                modified after an ERO expansion to the loose next-hop.=20
=20
The above procedures do not apply when a boundary LSR receives a Path=20
message with strict next-hop.=20
=20
5.1.    Example with an inter-area TE LSP (based on the assumption=20
    described in section 3).=20
=20
In this example, R0 sets up an inter-area TE LSP T1 to R1.=20
=20
5.1.1.  Case 1: T1 is a contiguous TE LSP=20
=20
When the path message reaches ABR1, it first determines the egress LSR=20
from its area 0 along the LSP path (say ABR=921), either directly from=20
the ERO (if for example the next hop ABR is specified as a loose hop in=20
the ERO) or by using some constraint-aware auto-discovery mechanism. =20
=20
In the former case, every inter-AS TE LSP path is defined as a set of=20
loose and strict hops but at least the ASBRs traversed by the inter-AS=20
TE LSP MUST be specified as loose hops on the Head-End LSR. =20
=20
- Example 1 (set of strict hops end to end): R0-X1-ABR1-ABR=921-X2-X3-R1=20
=20
 Vasseur and Ayyangar                                               12=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
- Example 2 (set of loose hops): R0-ABR1(loose)-ABR=921(loose)-R1(loose)=20
- Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABR=921(loose)-
X2-X3-R1=20
=20
At least, the set of ABRs from the TE LSP head-end to the Tail-End MUST=20
be present in the ERO as a set of loose hops. Optionally, a set of=20
paths can be configured on the head-end LSR, ordered by priority. Each=20
priority path can be associated with a different set of constraints.=20
Typically, it might be desirable to systematically have a last resort=20
option with no constraint to ensure that the inter-area TE LSP could=20
always be set up if at least a path exist between the inter-area TE LSP=20
source and destination. Note that in case of set up failure or when an=20
RSVP Path Error is received indicating the TE LSP has suffered a=20
failure, an implementation might support the possibility to retry a=20
particular path option a specific amount of time (optionally with=20
dynamic intervals between each trial) before trying a lower priority=20
path option. Any path can be defined as a set of loose and strict hops.=20
In other words,=20
in some cases, it might be desirable to rely on the dynamic path=20
computation in some area, and exert a strict control on the path in=20
other areas (defining strict hops).=20
=20
Example of configuration of T1 on R0 in dynamic mode: T1 Path: R0-
R6(loose)=20
=20
Once it has computed the path up to the next ABR, ABR1 sends the Path=20
message for the inter-area TE LSP to ABR=921. ABR=921 then repeats the=20
exact same procedures and the Path message for the inter-area TE LSP=20
will reach the destination R1. If ABR=921 cannot find a path obeying the=20
set of constraints for the inter-area TE LSP, then ABR=921 MUST send a=20
PathErr message to ABR1. Then ABR1 can in turn select another egress=20
boundary LSR (ABR=922 in the example above) if crankback is allowed for=20
this inter-area TE LSP (see [CRANBACK]). If crankback is not allowed=20
for that inter-area TE LSP or if ABR1 has been configured not to=20
perform crankback, then ABR1 MUST forward a PathErr up to the inter-
area head-end LSR (R0) without trying to select another egress LSR.=20
=20
5.1.2.  Case 2: T2 is a stitched or nested TE LSP=20
=20
When the path message reaches ABR1, it first determines the egress LSR=20
from its area 0 along the LSP path (say ABR=921), either directly from=20
the ERO or by using some constraint-aware auto-discovery mechanism.=20
=20
ABR1 will check if it has a FA-LSP or LSP segment to ABR=921 matching the=20
constraints carried in the inter-area Path message. If not, ABR1 will=20
setup a FA-LSP or LSP segment from ABR1 to ABR=921. Note that once the=20
FA-LSP/LSP segment is setup, it may be advertised as a link within that=20
area (see [LSP-HIER]) (area 0 in this example). The FA-LSP or LSP=20
segment could have also been pre-configured.=20
=20

=20
 Vasseur and Ayyangar                                               13=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
If the inter-area LSP is a packet LSP and ABR1 desires to do one-to-one=20
stitching, then it will signal this explicitly in the Path message for=20
the intra-area LSP segment as described in section 5.3.=20
=20
Also, there could be multiple FA-LSPs/LSP segments between ABR1 and=20
ABR=921. So, ABR1 needs to select one FA-LSP/LSP segment from these, for=20
the inter-area LSP through area 0. The mechanism and the criterion used=20
to select the FA-LSP/LSP segment is local to ABR1 and will not be=20
described here in detail. e.g. if we have multiple pre-configured FA-
LSPs/LSP segments, a local policy may prefer to use FA-LSPs (nesting)=20
for most inter-area/AS LSP requests. And it may select the LSP segments=20
(stitching) only for some specific inter-area LSPs.=20
=20
Once it has selected the FA-LSP/LSP segment for the inter-area LSP,=20
using the signaling procedures described in [LSP-HIER], ABR1 sends the=20
Path message for inter-area TE LSP to ABR=921. Note that irrespective of=20
whether ABR1 does nesting or stitching, the Path message for the inter-
area TE LSP is always forwarded to ABR=921. ABR=921 then repeats the exact=
=20
same procedures and the Path message for the inter-area TE LSP will=20
reach the destination R1. If ABR=921 cannot find a path obeying the set=20
of constraints for the inter-area TE LSP, then ABR=921 MUST send a=20
PathErr message to ABR1. Then ABR1 can in turn either select another=20
FA-LSP/LSP segment to ABR=921 if such an LSP exists or select another=20
egress boundary LSR (ABR=922 in the example above) if crankback is=20
allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is=20
not allowed for that inter-area TE LSP or if ABR1 has been configured=20
not to perform crankback, then ABR1 MUST forward a PathErr up to the=20
inter-area head-end LSR (R0) without trying to select another egress=20
LSR.=20
=20
5.1.3.  Processing of the Resv message (common procedure for contiguous=20
     and stitched/nested LSPs)=20
=20
The Resv message for the inter-area TE LSP is sent back from R1 to R0.=20
When the Resv message arrives at ABR=921, depending on whether ABR=921 is=20
nesting or stitching, ABR=921 will install the appropriate label actions=20
for the packets arriving on the inter-area LSP. Similar procedures are=20
carried out at ABR1 as well, while processing the Resv message.=20
=20
As the Resv message for the inter-area LSP traverses back from R1 to=20
R0, each LSR along the Path may record an address into the RRO object=20
carried in the Resv. According to [RSVP-TE], the addresses in the RRO=20
object may be a node or interface addresses. The link corresponding to=20
an unnumbered FA-LSP/LSP segment will have the ingress and egress LSR=20
Router-IDs as the link addresses ([RSVP-UNNUM]). So when ABR=921 sends=20
the Resv message to ABR1, ABR=921 will record its Router ID in the RRO=20
object. So, the inter-area TE LSP from R0 to R1 would have an RRO of=20
R0-ABR1-ABR=921-R1 or R0-<other hops>-ABR1-ABR=921-R1, depending on whether=
=20
the source area is setting up a FA-LSP/LSP segment or signaling a=20
contiguous TE LSP. If the FA-LSPs/LSP segments are numbered, then the=20

=20
 Vasseur and Ayyangar                                               14=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
addresses assigned to the FA-LSP/LSP segment will be recorded in the=20
RRO object.=20
=20
5.2.    Example with an inter-AS TE LSP (based on the assumption=20
described in section 3).=20
=20
The procedures for establishing an inter-AS TE LSP are very similar to=20
those of the inter-area TE LSP described above. The main difference=20
here from the inter-area case, is the presence of ASBR-ASBR link(s). =20
=20
The links interconnecting ASBRs are usually not TE enabled and no IGP=20
is running at the AS boundaries.=20
=20
An implementation supporting inter-AS MPLS TE MUST obviously allow the=20
set up of inter-AS TE LSP over the region interconnecting multiple=20
ASBRs. In other words, an ASBR compliant with this document MUST=20
support the set up of TE LSP over ASBR to ASBR links, performing all=20
the usual operations related to MPLS Traffic Engineering (call=20
admission control, =85) as defined in [RSVP-TE]. So the limitation (1)=20
MUST be removed. Regarding the second limitation (2), in the very vast=20
majority of the cases, two SPs do not run an IGP between ASBRs.=20
Although this imposes for the two ASBRs to be interconnected via single=20
hop link, this does not constitute a severe limitation.=20
=20
An interesting optimization consists in allowing the ASBRs to flood the=20
TE information related to the ASBR-ASBR link(s) although no IGP TE is=20
enabled over those links (and so there is no IGP adjacency over the=20
ASBR-ASBR links). This allows a head-end LSR to make a more appropriate=20
route selection up to the first ASBR in the next hop AS in the case of=20
scenario 1 and will significantly reduce the number of signaling steps=20
in route computation. This also allows the entry ASBR in an AS to make=20
a more appropriate route selection up to the entry ASBR in the next hop=20
AS taking into account constraints associated with the ASBR-ASBR links.=20
Moreover, this reduces the risk of call set up failure due to inter-
ASBR links not satisfying the inter-AS TE set of constraints. Note that=20
the TE information is only related to the ASBR-ASBR links. In other=20
words, the TE LSA/LSP flooded by the ASBR includes not only the links=20
contained in the AS but also the ASBR-ASBR links. =20
=20
Note that no summarized TE information is leaked between ASes in any of=20
the proposed scenarios in this document.=20
=20
Example:=20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9---R6 =20
      |\     \ |       / |   / |   / |          |     |=20
      | \     ASBR2---/ ASBR5  | --  |          |     |  =20
      |  \     |         |     |/    |          |     |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10---R7---CE2 =20
                =20
=20
 Vasseur and Ayyangar                                               15=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
For instance, in the diagram depicted above, when ASBR1 floods its IGP=20
TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing=20
domain, it reflects the reservation states and TE properties of the=20
following links: X1-ASBR1, ASBR1-ASBR4, ASBR1-ASBR2.=20
=20
Thanks to such an optimization, the inter-ASBRs TE link information=20
corresponding to the links originated by the ASBR is made available in=20
the TED of other LSRs in the same area/AS that the ASBR belongs to,=20
hence the CSPF computations for an inter-AS TE LSP path can also take=20
into account the ASBR-ASBR link. This will improve the chance of=20
successful path computation up to the next AS (ASBR4, 5 or 6 in this=20
example) in case of a bottleneck on some ASBR-ASBR links and it reduces=20
one level of crankback. Note that no topology information is flooded=20
and these links are not used in IGP SPF computations. Only the TE=20
information for the links originated by the ASBR is advertised.=20
=20
5.2.1.  Case 1: T1 is a contiguous TE LSP=20
=20
The inter-AS TE path may be configured on the head-end LSR as a set of=20
strict hops, loose hops or a combination of both.=20
=20
- Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5-
R3-ASBR7-ASBR9-R6=20
- Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose)=20
- Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1-
ASBR4(loose)-ASBR10(loose)-ASBR9-R6=20
=20
When a next hop is a loose hop, a dynamic path calculation (also called=20
ERO expansion) is required taking into account the topology and TE=20
information of its own AS and the set of TE LSP constraints. In the=20
example 1 above, the inter-AS TE LSP path is statically configured as a=20
set of strict hops, so in this case, no dynamic computation is=20
required. In the example 2, a per-AS path computation is performed,=20
respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3.=20
=20
Note that when an LSR has to perform an ERO expansion, the next hop=20
must either belong to the same AS, or must be the ASBR directly=20
connected to the next hops AS. In this later case, the ASBR=20
reachability must be announced in the IGP TE LSA/LSP originated by its=20
neighboring ASBR. In the example 2 above, the TE LSP path is defined=20
as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that the ERO=20
expansion performed by R0 must compute the path from R0 to ASBR4. As=20
stated in section 6.2, the TE reservation state related to the ASBR1-
ASBR4 link is flooded in AS1 by ASBR1. In addition, ASBR1 MUST also=20
announce the IP address of ASBR4 specified in the T1 path=20
configuration.=20
=20
If an auto-discovery mechanism is available, every LSR receiving an=20
RSVP Path message, will have to determine automatically the next hop=20
ASBR, based on the IGP/BGP reachability of the TE LSP destination. With=20
such a scheme, the head-end LSR and every downstream ASBR loose hop=20
=20
 Vasseur and Ayyangar                                               16=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
(except the last loose hop that computes the path to the final=20
destination) automatically computes the path up to the next ASBR, the=20
next loose hop based on the IGP/BGP reachability of the TE LSP=20
destination. If a particular destination is reachable via multiple=20
loose hops (ASBRs), local heuristics may be implemented by the head-end=20
LSR/ASBRs to select the next hop an ASBR among a list of possible=20
choices (closest exit point, metric advertised for the IP destination=20
(ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR=20
has been determined, an ERO expansion is performed as in the previous=20
case.=20
=20
Once it has computed the path up to the next ASBR, ASBR1 sends the Path=20
message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the=20
selected next hop ASBR). ASBR4 then repeats the exact same procedures=20
and the Path message for the inter-AS TE LSP will reach the destination=20
R1. If ASBR4 cannot find a path obeying the set of constraints for the=20
inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then=20
ASBR1 can in turn either select another ASBR (ASBR5 in the example=20
above) if crankback is allowed for this inter-AS TE LSP (see=20
[CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if=20
ASBR1 has been configured not to perform crankback, then ABR1 MUST=20
forward a PathErr up to the head-end LSR (R0) without trying to select=20
another egress LSR. In this case, the head-end LSR can in turn select=20
another sequence of loose hops, if configured. Alternatively, the head-
end LSR may decide to retry the same path; this can be useful in case=20
of set up failure due an outdated IGP TE database in some downstream=20
AS. An alternative could also be for the head-end LSR to retry to same=20
sequence of loose hops after having relaxed some constraint(s).=20
=20
5.2.2.  Case 2: T1 is a stitched or nested TE LSP=20
=20
The signaling procedures are very similar to the inter-area LSP setup=20
case described in section 5.1.2. In this case, the FA-LSPs or LSP=20
segments will only be originated by the ASBRs at the entry to the AS.=20
=20
In the example provided in section 3, for an LSP setup from CE1 to CE2,=20
the FA-LSPs/LSP segments may be setup between ASBR4-ASBR7 and=20
potentially ASBR9-R7.  The Path message in this case traverses along=20
CE1-R0-ASBR1-ASBR4-ASBR7-ASBR9-R7-CE2. In the RRO sent in the Resv=20
message, the ASBRs which are ingress into the AS (like ASBR4, ASBR9,=20
ASBR3, ASBR10) can record the interface address corresponding to the=20
ASBR-ASBR link in the RRO.=20
=20
Between the ASBRs regular RSVP-TE signaling procedures are carried out.=20
In case the ASBRs (say ASBR1 and ASBR4) are more than one hop away,=20
then instead of creating RSVP state for every inter-AS LSP traversing=20
ASBR1 and ASBR4, one MAY decided to aggregate these requests by setting=20
up a FA-LSP between the ASBRs to nest the inter-AS LSP requests. The=20
boundary LSR ASBR1, by default is not a candidate to initiate a FA-LSP=20
or LSP segment setup. But this behavior MAY be overridden by=20
configuration.=20
=20
 Vasseur and Ayyangar                                               17=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
5.3.    Signaling specifics with TE LSP stitching for packet LSPs=20
=20
This section only applies to an inter-area/AS packet LSP being stitched=20
to another intra-area/AS packet LSP. If a boundary LSR (ABR/ASBR)=20
desires to perform LSP stitching, then it MUST indicate this in the=20
Path message for the intra-area/AS LSP segment. This signaling is=20
needed so that the egress LSR for the LSP segment knows in advance, how=20
the ingress for the LSP segment plans to map traffic onto the LSP=20
segment. This will allow it to allocate the correct label(s) as=20
explained below. Also, so that the head-end LSR can ensure that correct=20
stitching actions were carried out at the egress LSR, a new flag is=20
defined below in the RRO subobject to indicate that the LSP segment may=20
be used for stitching.=20
=20
In order to request LSP stitching, we define a new flag bit in the=20
Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RSVP-=20
ATTRIBUTES]:=20
=20
0x04: LSP stitching desired=20
=20
This flag will be set in the Attributes Flags TLV of the LSP_ATTRIBUTES=20
object in the Path message for the local intra-area/AS LSP segment by=20
the head-end LSR of the LSP segment (boundary LSR) that desires LSP=20
stitching. This flag SHOULD not be modified by any other LSRs in that=20
area/AS.=20
=20
An intra-area/AS LSP segment can only be used for stitching if=20
appropriate label actions were carried out at the egress LSR of the LSP=20
segment. In order to indicate this to the head-end LSR for the LSP=20
segment, the following new flag bit is defined in the RRO sub-object:=20
=20
0x20: LSP segment stitching ready=20
=20
If an egress LSR receiving a Path message, supports the LSP_ATTRIBUTES=20
object and the Attributes Flags TLV, and also recognizes the =91=91LSP=20
stitching desired=92=92 flag bit, but cannot support the requested stitching=
=20
behavior, then it MUST send back a PathErr message with an error code=20
of "Routing Problem" and an error sub-code=3D16 "Stitching unsupported"=20
to the head-end LSR of the intra-area/AS LSP segment.=20
=20
If an egress LSR receiving a Path message with the =91=91LSP stitching=20
desired=92=92 flag set, recognizes the object, the TLV and the flag and also=
=20
supports the desired stitching behavior, then it MUST allocate a non-
NULL label for that LSP segment in the corresponding Resv message. Now,=20
so that the head-end LSR can ensure that the correct label actions will=20
be carried out by the egress LSR and that the LSP segment can be used=20
for stitching, the egress LSR MUST set the =91=91LSP segment stitching=20
ready=92=92 bit defined in the RRO sub-object. Also, when the egress LSR for=
=20
the LSP segment receives a Path message for an inter-area/AS LSP using=20
this LSP segment, it SHOULD first check if it is also the egress for=20
=20
 Vasseur and Ayyangar                                               18=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
the inter-area/AS TE LSP. If the egress LSR is the egress for both the=20
intra-area/AS LSP segment as well as the inter-area/AS TE LSP, and it=20
requires Penultimate Hop Popping (PHP), then the LSR MUST send back a=20
Resv refresh for the intra-area/AS LSP segment with a new label=20
corresponding to the NULL label. The egress LSR SHOULD always allocate=20
a NULL label in the Resv message for the inter-area/AS TE LSP.=20
=20
Finally, if the egress LSR for the intra-area/AS LSP segment supports=20
the LSP_ATTRIBUTES object but does not recognize the Attributes Flags=20
TLV, or supports the TLV as well but does not recognize this particular=20
flag bit, then it SHOULD simply ignore the above request.=20
=20
An ingress LSR requesting stitching SHOULD examine the RRO sub-object=20
flag corresponding to the egress LSR for the intra-area/AS LSP segment,=20
to make sure that stitching actions were carried out at the egress LSR.=20
It MUST NOT use the LSP segment for stitching if the =91=91LSP segment=20
stitching ready=92=92 flag is cleared.=20
=20
An ingress LSR stitching an inter-area/AS LSP to an LSP segment MUST=20
ignore any Label received in the Resv for the inter-area/AS LSP.=20
=20
Example: In case of inter-AS TE LSP setup from CE1 to CE2 as described=20
in the example, let us assume that ASBR4 is doing one-to-one LSP=20
stitching. When ASBR4 receives the inter-AS TE LSP Path message, it=20
will first initiate the setup of an intra-AS LSP segment to ASBR7, if=20
not already present. In the Path message for this LSP segment, ASBR4=20
will set the "LSP stitching desired" flag in the Attributes Flags TLV=20
of the LSP_ATTRIBUTES object. When ASBR7 receives this Path message, it=20
will allocate a non-NULL label (real label for swap action) in the Resv=20
message for this LSP segment. Also, it will set the "LSP segment=20
stitching ready" flag in the RRO subobject in the Resv message. Once=20
the LSP segment is signaled successfully, ASBR4 will then forward the=20
Path message for the inter-AS TE LSP to ASBR7, which propagates it=20
further. Eventually as the Resv message for the inter-AS TE LSP=20
traverses back from ASBR9 to ASBR7 and reaches ASBR7, ASBR7 will=20
remember to swap the LSP segment label with the label received for the=20
inter-AS LSP from ASBR9. Also, ASBR7 will itself allocate a NULL label=20
in the Resv message for the inter-AS TE LSP and sends the Resv message=20
to ASBR4. ASBR4 ignores the Label object in the Resv message received=20
from ASBR7 for the inter-AS TE LSP and remembers to swap the label that=20
it allocates in the inter-AS Resv message sent to ASBR1 with the label=20
that it had received from say, LSR R4 for the intra-AS LSP segment. In=20
this manner, the inter-AS TE LSP is stitched to an intra-area/AS LSP=20
segment in AS2. In this example, if the LSP destination for the inter-
AS LSP had been ASBR7, if this is a packet-switched LSP and if ASBR7=20
requires PHP, then on receiving the Path message for the inter-AS LSP,=20
ASBR7 will re-send a Resv message for the intra-area/AS LSP segment to=20
say R4, by changing the Label to a NULL label.=20
=20
6.      Scenario 2: end to end shortest path computation=20
=20
=20
 Vasseur and Ayyangar                                               19=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
6.1.    Introduction and definition of an optimal path=20
=20
Qualifying a path as optimal requires clarification. Indeed, a globally=20
optimal TE LSP placement usually refers to a set of TE LSP whose=20
placements optimize the network resources (i.e a placement that reduces=20
the maximum or average network load for instance). By contrast, a=20
optimal path for a TE LSP, is the shortest path that obeys the set of=20
required constraints (bandwidth, affinities,=85), minimizing either the=20
IGP or TE metric cost (See [SECOND-METRIC] and [MULTIPLE-METRICS]). In=20
this document, an optimal inter-AS TE path is defined as the optimal=20
path that would be obtained in the absence of AS/Areas, in a totally=20
flat network between the source and destination of the TE LSP.=20
=20
6.2.    Notion of PCE (Path Computation Element)=20
=20
An LSR is said to be a PCE (Path Computation Element) when it has the=20
ability to compute an inter-area/AS TE LSP path for a TE LSP it is not=20
the head-end of. Ideal candidates to support a PCE function are ABRs in=20
the context of inter-area TE (since each ABR has the view of two of=20
more areas in its TED) and ASBR in the context of inter-AS TE. Note=20
that in this document an LSR supporting the function of PCE is simply=20
referred to as a PCE. As in the case of intra-area TE, it is not made=20
any assumption on the actual path computation algorithm in use by the=20
PCE (it can be any variant of CSPF, algorithm based on linear-
programming to solve multi-constraints optimization problems,=85).=20
=20
6.3.    Dynamic PCE discovery=20
=20
PCE(s) can either be statically configured on each LSR requesting an=20
inter-area/AS TE LSP path computation or dynamically discovered by=20
means of IGP extensions defined in [OSPF-CAP], [OSPF-TE-CAP], [ISIS-
CAP] and [ISIS-TE-CAP]. This allows an Operator to elect a subset of=20
ABRs/ASBRs to act as PCEs.=20
=20
Note that if the AS is made of multiple areas/levels, [OSPF-CAP] and=20
[ISIS-CAP] support the capabilities announcements across the entire=20
routing domain (making use of TLV leaking procedure for IS-IS and OSPF=20
opaque LSA type 11 for OSPF).=20
=20
6.4.    PCE selection=20
=20
It belongs to an LSR informed of the existence of multiple PCEs having=20
the capability to serve an inter-area/AS TE LSP path computation=20
request to select the preferred PCE. For instance, an LSR may select=20
the closest PCE based on the IGP metric or may just randomly select one=20
of the PCE. In case of multiple PCEs, the selected PCE should be such=20
that the requests are balanced across multiple PCEs. An LSR MUST be=20
able to select another PCE if its preferred PCE does not answer to its=20
request. Note that the PCE may or not be along the TE LSP Path. This=20
implies that the PCE is just responsible for the TE LSP path=20
computation, not for its maintenance. Moreover, the PCE may compute=20
=20
 Vasseur and Ayyangar                                               20=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
just a path segment, not the whole path end to end; in this case, the=20
returned computed path will contain loose hops.=20
=20
6.5.    LSR-PCE signaling protocol=20
=20
Any LSR can send an RSVP path computation request to a PCE that will in=20
turn compute a set of TE LSP(s) path and return the corresponding path=20
parameters via an RSVP path computation reply message. The format of=20
the RSVP path computation requests and reply messages are defined in=20
[PATH-COMP] as well as the set of optional objects characterizing the=20
constraints:=20
=20
REQUEST-ID object: must be present in any RSVP Path computation request=20
and reply message and specifies the request-ID-number, several requests=20
characteristics. =20
=20
METRIC-TYPE object: allows the PCC to indicate to the PCE the metric to=20
be used to compute the shortest path (currently two metrics are=20
defined: the IGP or TE metric).=20
                =20
PATH-COST object: object inserted in the RSVP path computation reply=20
message to indicate the cost of a computed TE LSP in addition to the=20
path. This object is mandatory if the cost has been explicitly=20
requested in the RSVP path computation request and optional in any=20
other case.=20
=20
The protocol state machine is also defined in [PATH-COMP].=20
=20
6.6.    Computation of an optimal end to end TE LSP path=20
=20
This section details the set of mechanisms allowing to compute an=20
optimal (shortest) inter-area/AS TE LSP path obeying a set of specified=20
constraints. =20
=20
Each step of the mechanism is illustrated with the example of an inter-
AS TE LSP obeying a set of specified constraints: the shortest path of=20
an inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in=20
AS3 is computed). The case of inter-area TE LSP optimal path=20
computation is very similar.=20
=20
1) Step 1: discovery by the head-end LSR of a PCE capable of serving=20
its path computation request. The PCE will either be an ABR (inter-area=20
TE) or an ASBR (Inter-AS TE). In the case of inter-AS TE, the PCE must=20
be able to serve the source AS and can compute inter-AS TE LSP path=20
terminating in the destination ASn. As mentioned above, the PCE can=20
either be statically configured or dynamically discovered via IGP=20
extensions. If multiple PCEs are discovered, the head-end LSR selects=20
one PCE based on some local policies/heuristics.=20
=20
Ex: R1 selects ASBR1 as the PCE serving its request for the T1 path=20
computation.=20
=20
 Vasseur and Ayyangar                                               21=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
2) Step 2: an RSVP Path computation request is sent to the selected=20
PCE. =20
=20
Case of inter-area TE: the head-end LSR sends its path computation=20
requests to the selected PCE (ABR).=20
=20
Case of inter-AS TE: the RSVP path computation request can be sent=20
either (1) to a PCE in the same AS which will in turn relay the request=20
to a PCE of the next hop AS (Ex: R0 sends an RSVP path computation=20
request to ASBR1 which relays the request to say ASBR4) or (2) to the=20
PCE in the next hop AS if the head-end LSR has a complete topology and=20
TE view up to the next hop PCE (Ex: R0 sends an RSVP path computation=20
request to ASBR4). It is expected that (1) will be the most common=20
inter-AS TE deployment scenario for some security issues.=20
=20
Note that it may be desirable to set up some policies on the PCE to=20
limit the access to specific LSRs. Moreover, the usual RSVP=20
authentication process may be used when sending a request to a PCE.=20
=20
Step i: the PCE of ASi relays the path computation request to the=20
selected PCE peer in AS(i+1) located in the next hop AS. Note that the=20
address of the list of PCE(es) in the next hop AS must be statically=20
configured on the PCE. This implies some static configuration on the=20
PCE only.=20
=20
Ex: ASBR1 sends an RSVP path computation request to ASBR4=20
=20
If the TE LSP destination is in ASi, then the PCE provides the list of=20
shortest paths (with their corresponding ERO (potentially partial ERO)=20
+ Path-cost) from every ASBR to the inter-AS TE LSP destination. See a=20
detailed example below.=20
=20
If the TE LSP destination is not in ASi, the PCE relays the RSVP path=20
computation request to the targeted PCE peer in AS(i+2) in the next hop=20
AS.=20
=20
The process is iterated until the destination AS is reached.=20
=20
Ex: ASBR4 relays the RSVP path computation request to ASBR9 which=20
determines that the T1=92s destination address belongs to its AS. ASBR9=20
will in turn return a path computation reply to the requesting PCE, e.g=20
ASBR4. The RSVP path computation reply contains two paths (provided=20
that two paths obeying the set of constraints exist):=20
        - ERO 1: ASBR9-R6, Cost=3Dc1,=20
        - ERO 2: ASBR10-R7-R6, Cost=3Dc2=20
Note that the ERO object might be made of loose hop to preserve=20
confidentiality.=20
=20
Step 3: once a requesting PCEi receives an RSVP Path computation reply,=20
the shortest path is computed from ASi to ASi+1 by route concatenation.=20
=20
 Vasseur and Ayyangar                                               22=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
This is done by running a virtual SPT (Shortest Path Tree) computation=20
using CSPF where the nodes are the ABSRs connected by virtual link=20
whose costs are equal to the shortest path connecting the ASBRs.=20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9---R6 =20
      |\     \ |       / |   / |   / |          |     |=20
      | \     ASBR2---/ ASBR5  | --  |          |     |  =20
      |  \     |         |     |/    |          |     |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10---R7---CE2 =20
=20
Resulting Virtual SPT computed by ASBR 4=20
=20
ASBR4---ASBR7---ASBR9---R6=20
| |  \ /  /| \  / |    /=20
| |   \  / |  \/  |   /=20
| |  / \/  |  /\  |  /=20
| | /  /\  | /  \ | /=20
|ASBR5--ASBR8---ASBR10=20
| |   / /=20
| |  / /=20
| | / /=20
| |/ /=20
ASBR6=20
=20
Within ASi, the cost of each ASBR-ASBR virtual link is equal to the=20
shortest path cost. This information is known by PCEi. =20
=20
The cost of the ASBR-ASBR link between ASBR of different ASes is also=20
known by the PCEi (see section 6.2).=20
=20
Within ASi+1, the cost of the ASBR-ASBR virtual link is provided in the=20
RSVP path computation reply of the PCEi+1.=20
=20
Ex: ASBR4 will then compute the shortest path for the TE LSP traversing=20
AS2 and AS3. =20
=20
Then the process is reiterated recursively until the optimal end-to-end=20
Path computation is completed. The whole path may not be seen by each=20
PCE for confidentiality reason but this process will ensure that the=20
shortest path is selected. =20
=20
Example: the resulting computed virtual SPT computed by ASBR1 will=20
finally be:=20
=20
R0-----ASBR1-----ASBR4----R6=20
| \     |  |\ \ /  /||   / /=20
|  \    |  | \ \  / ||  / /=20
|   \   |  |  / \/  || / /=20
|    \  |  | / \/\  ||/  | =20
|     \-|-ASBR2--
               -
               -
                ASBR5    |=20
=20
 Vasseur and Ayyangar                                               23=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
|       |  |\  /\/  ||   |=20
|       |  | \/ /\  ||   /=20
|       |  | /\/  \ ||  /=20
|       |  |/ /\   \|| /=20
--------|=3DASBR3---
                -
                -
                 ASBR6/=20
=20
Then once the optimal end to end path is computed, the head-end LSR=20
sets up the inter-AS TE using a complete list of ERO if the various=20
PCEs have provided the list of ERO or some loose hops in the contrary.=20
=20
An implementation MAY decide to support local caching of path=20
computation in order to optimize the path computation process. The flip=20
side of path caching is the potential increase of call set up failure.=20
When caching is in use, it must be flushed upon TE LSP failure provided=20
that the PCE is along the inter-area/AS TE LSP path.=20
=20
As opposed to scenario 1, an end-to-end shortest path obeying the set=20
of required constraint is computed. In that sense, the path is optimal.=20
=20
Some other variants of such an algorithm relying on the same principles=20
are also possible.=20
=20
Note also that in case of ECMP paths, more than one path could be=20
returned to the requesting LSR.=20
=20
6.7.    Path optimality=20
=20
In the case of inter-area TE, it is a common usage to adopt the same=20
policy for the IGP/TE metric (based on the link-speed, propagation=20
delay or some other combination of constraints). Hence, the proposed=20
set of mechanism always computes the shortest path across multiple=20
areas obeying the required set of constraints. In the case of Inter-AS=20
TE, in order for this path computation to be meaningful, a metric=20
normalization between ASes is required. One solution to avoid IGP=20
metric modification would be for the SPs to agree on a TE metric=20
normalization and use the TE metric for TE LSP path computation (in=20
that case, this must be requested in the RSVP Path computation request=20
via the METRIC-COST object defined in [PATH-COMP]).=20
=20
6.8.    Diverse end to end path computation=20
=20
The RSVP signaling protocol defined in [PATH-COMP] allows an LSR to=20
request the computation of a set of N diversely routed TE LSPs. Then in=20
this scenario, a set of diversely routed TE LSP between two LSRs can be=20
computed since both paths are simultaneously computed with a minimal=20
required amount of steps. =20
=20
7.      Mode of operation of MPLS Traffic Engineering Fast Reroute for=20
inter-area/AS TE LSPs=20
=20

=20
 Vasseur and Ayyangar                                               24=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
MPLS Traffic Engineering Fast Reroute ([FAST-REROUTE]) defines local=20
protection schemes that provide fast recovery (in 10s of msecs) of=20
protected TE LSPs upon link/SRLG/Node failure. A backup TE LSP path is=20
either statically configured or dynamically computed and then the=20
backup TE LSP is signaled at each hop. Upon detecting a network element=20
failure (via link failure detection mechanisms provided via layer 2=20
protocol, or IGP/BFD/RSVP fast hellos), the node immediately upstream=20
to the failure (called the PLR (Point of Local Repair)) reroutes the=20
set of protected TE LSPs onto the appropriate backup tunnel(s) around=20
the failed resource. In the context of inter-area/AS TE, one must=20
consider various failure scenarios and analyze for each of them the=20
potential required extensions for MPLS TE FRR. [FAST-REROUTE] specifies=20
two modes referred to as the one to one mode and facility backup mode.=20
While this section specifies the use of MPLS TE Fast Reroute for the=20
facility backup mode, similar procedures also apply for the one-to-one=20
backup mode.=20
=20
The failure scenarios specific to inter-area/AS TE are the following:=20
        - Failure of an ABR or an ASBR node=20
        - Failure of an inter-ASBRs link=20
=20
Because the cases of a contiguous LSP significantly differ from the one=20
of a stitched/nested TE LSP, they will be treated separately.=20
=20
The current set of mechanisms defined in [FAST-REROUTE] applies without=20
any restriction to any link/SRLG/Node failure within an area or an AS.=20
In other words, a protected inter-area/AS TE LSP (an LSP signaled with=20
the "local protection desired" bit set in the SESSION-ATTRIBUTE object=20
or with a FAST-REROUTE object) can be protected via the MPLS TE Fast=20
Reroute mechanism regardless of whether the TE LSP is an intra-area/AS=20
or inter-AS TE LSP in case of link/SRLG/node failure within the AS.=20
This is true for contiguous, nested and stitched inter-area/AS TE LSP. =20
=20
However, MPLS TE Fast Reroute is a temporary local protection=20
mechanism. Upon a link/SRLG/node failure, the PLR triggers Fast Reroute=20
and for each rerouted TE LSP, the PLR MUST send a notification of the=20
local repair by sending an RSVP Path Error message with error code of=20
"Notify"(Error code =3D25) and an error value field of ss00 cccc cccc=20
cccc where ss=3D00 and the sub-code =3D 3 ("Tunnel locally repaired") (see=
=20
[RSVP-TE]). The receipt of such a Notify Path Error is used by the=20
head-end LSR to trigger a reoptimization such that the TE LSP follows a=20
more optimal path. =20
=20
Case of a contiguous inter-area/AS TE LSP=20
        - The case of a contiguous inter-area/AS TE LSP is identical to=20
        an intra-area TE LSP. =20
=20
Case of a stitched/nested TE LSP=20
        =20
        The failure notification (RSVP Path Error/Notify message=20
        "Tunnel Locally Repaired") for the FA-LSP/LSP segment SHOULD be=20
=20
 Vasseur and Ayyangar                                               25=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
        sent to the respective ingress LSR for that intra-area/AS FA-
        LSP/LSP segment in that area. The ingress LSR for the FA-
        LSP/LSP segment will then try to re-route the FA-LSP/LSP=20
        segment around the failure, and the inter-area/AS LSPs using=20
        the FA-LSP/LSP segment will start taking the new path in that=20
        area/AS. However, in case the head-end LSR in that area/AS is=20
        unable to find a path around the failure to re-route the intra-
        area FA-LSP/LSP segment, then a failure and repair notification=20
        stated above (PathErr) for all the affected inter-area/AS TE=20
        LSPs MAY be propagated to the upstream area/AS towards the=20
        head-end LSR for the inter-area/AS TE LSP. This could be a=20
        local policy decision.  Other area/AS boundary LSRs along the=20
        way could intercept the error message to do some kind of=20
        crankback if crankback is allowed for the inter-area/AS TE LSP.=20
        This two-phase approach tries to handle the failure first=20
        locally within an area/AS as far as possible by intercepting=20
        the error notification at the area/AS boundary LSR and re-
        routing the intra-area/AS LSP. Only if that fails, do we=20
        propagate the error notification further upstream.=20
=20
        Alternatively, instead of intercepting the error notifications=20
        and following the above two-phase approach, one may choose to=20
        always send back error notifications back to the head-end LSR=20
        for the inter-area/AS TE LSP in the originating area/AS. This=20
        could be a local policy decision. In any case, the TE LSP=20
        SHOULD be re-routed around the failure using the "make-before-
        break" approach.=20
        =20
        Example: back to the example of the inter-AS TE LSP setup, let=20
        us assume that the FA-LSP/LSP segment traverses R4 in AS2, and=20
        is node-protected against the failure of R4. In that case, when=20
        R4 or the corresponding link to R4 fails, then the traffic will=20
        be locally protected by the corresponding backup path LSP=20
        associated with the protected FA-LSP/LSP segment. When the=20
        PathErr/Notify message "Tunnel Locally Repaired" reaches ASBR4,=20
        it may find a new path for the FA-LSP/LSP segment and signal=20
        it. During this time, the FA-LSP/LSP segment along the old path=20
        was locally repaired and so traffic will continue to take the=20
        backup path around the failure. Once the new path for the FA-
        LSP/LSP segment is successfully signaled the traffic is=20
        switched to the new path and the old path is torn down. Note=20
        that since the inter-AS traffic is sent along the FA-LSP/LSP=20
        segment, that traffic has been protected as well.=20
=20
Note: in the context of inter-AS TE LSP, if the failure occurs in an=20
area/AS different from the head-end LSR, the head-end LSR exclusively=20
relies on the Path Error message to get informed that a local repair=20
has been performed in order to potentially perform a reoptimization.=20
Hence, the RSVP Path Error message SHOULD be sent in reliable mode=20
([REFRESH-REDUCTION]).=20
=20
=20
 Vasseur and Ayyangar                                               26=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
7.1.    Support of MPLS TE Fast Reroute for a contiguous inter-area/AS=20
TE LSP=20
=20
7.1.1.  Failure of a network element within an area/AS=20
=20
The mode of operation of MPLS TE Fast Reroute to protect a contiguous,=20
stitched or nested TE LSP within an area or AS is identical as the=20
single area/AS case.=20
=20
7.1.2.  Failure of an inter-AS link=20
=20
To protect an inter-ASBR link with MPLS TE Fast Reroute, the following=20
actions are required:=20
=20
- A set of backup tunnels must be configured or dynamically computed=20
between the two ASBRs diversely routed from the protected inter-ASBRs=20
link. Mechanisms like =91=91auto-discovery=92=92 of next-hop LSR and ERO=
 loose-
hop expansion with partial CSPF computation to the first reachable LSR=20
may also be applicable to the backup path computation.=20
=20
Notes:=20
=20
        - Typically, the region connecting two ASes is not TE enabled.=20
        So an implementation will have to support the set up of TE LSP=20
        over a non-TE enabled region. The backup tunnel path will be=20
        configured on each ASBR as a set of strict hops and then=20
        signaled via the RSVP-TE procedure defined in RFC3209.=20
        =20
        - The reason why a set of NHOP backup tunnels might be required=20
        is in case of requirement for bandwidth protection if a single=20
        backup tunnel satisfying the bandwidth requirement cannot be=20
        found (see [BANDWIDTH-PROTECTION]).=20
=20
        - For each protected inter-AS TE LSP traversing the protected=20
        link, a NHOP backup must be selected by a PLR (i.e ASBR), when=20
        the TE LSP is first set up. This requires for the PLR to select=20
        a backup tunnel terminating at the NHOP. Finding the NHOP=20
        backup tunnel of an inter-AS LSP can be achieved by analyzing=20
        the content of the RRO object received in the RSVP Resv message=20
        of both the backup tunnel and the protected TE LSP(s). As=20
        defined in [RSVP-TE], the addresses specified in the RRO IPv4=20
        subobjects can be node-ids and/or interface addresses (with=20
        specific recommendation to use the interface address of the=20
        outgoing Path messages). Within a single area, the PLR can=20
        easily find whether the backup tunnel intersects the protected=20
        TE LSP regardless of whether the node-id or the interfaces are=20
        specified in the RRO object since it has the complete topology=20
        knowledge in its IGP database. This is not the case when the MP=20
        resides in a different AS. [NODEID] proposes a solution to this=20
        issue, defining an additional RRO IPv4 suboject that specifies=20
        a node-id address.=20
=20
 Vasseur and Ayyangar                                               27=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 that=20
follows the ASBR1-ASBR2-ASBR4 path.=20
=20
7.1.3.  Failure of an ABR or an ASBR node=20
=20
To protect a contiguous inter-area/AS TE LSP from an ABR/ASBR node=20
failure using MPLS TE Fast Reroute, the following actions are required:=20
=20
Case of inter-AS TE:=20
=20
- A set of backup tunnel(s) must be configured from the penultimate hop=20
in AS1 (penultimate node directly connected to the last ASBR in AS1) to=20
the first ASBR in AS2 to protect against the failure of the last ASBR=20
in AS1.=20
=20
Ex: B1 from X1 to ASBR4 follows the X1-ASBR2-ASBR4 path and protects=20
against the failure of the ASBR1 node.=20
=20
- A set of backup tunnel(s) must be configured from the last ASBR in=20
AS1 to the next hop of the first ASBR in AS2 to protect against the=20
failure of the first ASBR in AS2.=20
=20
Ex: B3 from ASBR1 to R3 follows the ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3=20
path and protects against the failure of the ASBR4 node.=20
=20
Case of inter-area TE:=20
=20
- A set of NHOP backup tunnel(s) must be configured from the ABR=92s=20
upstream LSR to the ABR=92s downstream LSR.=20
        =20
Example: B1 from X1 (upstream neighbor of ABR1 in area 1) to Y1=20
(downstream neighbor of ABR1 in area 0).=20
=20
For each protected inter-AS TE LSP traversing the protected link/node,=20
a NNHOP backup must be selected by a PLR (i.e LSR/ASBR). This requires=20
for the PLR to select a backup tunnel terminating at the NNHOP.=20
=20
Finding the NNHOP backup tunnel of an inter-AS LSP can be achieved by=20
analyzing the content of the RRO object received in the RSVP Resv=20
message of both the backup tunnel and the protected TE LSP(s) (see=20
[NODE-ID]).=20
=20
7.1.4.  Procedure during MPLS TE Fast Reroute=20
=20
In addition to the rules defined in [FAST-REROUTE], in the context of=20
inter-area/AS TE LSP, there is a specific action that must be performed=20
when protecting the first ASBR of the next AS via a NNHOP backup tunnel=20
(see 5.6.3 (1)). =20
=20
The ASBR acting as a PLR (Point of Local Repair) MUST:=20
=20
 Vasseur and Ayyangar                                               28=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
        - Identify the MP address in the RRO received in the=20
        corresponding Resv message,=20
        - Remove all the sub-objects preceding the first address=20
        belonging to the MP,=20
        - Replace this first MP address with the IP address of the MP=20
        (its node-id address).=20
=20
Example with inter-AS TE:=20
=20
                <---BGP--->            <---BGP-->=20
 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9---R6=20
       |\     \ |       / |   / |   / |          |     |=20
       | \     ASBR2---/ ASBR5  |  /  |          |     |=20
       |  \     |         |     |/    |          |     |=20
       R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2=20
=20
- T1: a protected inter-AS TE LSP from R0 to R6, whose path is defined=20
on R0 as a set of loose hops: R0-ASBR1(loose)-ASBR4(loose)-
ASBR9(loose)-R6=20
=20
- B3: a backup tunnel from ASBR1 to R3 following the ASBR1-ASBR2-ASBR3-
ASBR6-ASBR5-R3 path and protecting against a failure of the ASBR4 node.=20
=20
- The ERO subobject content signaled in the rerouted RSVP Path message=20
of T1 over B3 by ASBR1 (PLR) must content the MPs as the next hop=20
address (R3). Otherwise, R3 will receive an incorrect ERO.=20
=20
A similar mechanism is required when rerouting an inter-AS TE LSP from=20
the failure of the last ASBR of an AS.=20
=20
- The RRO object may need to be updated by inserting an IPv4 or IPv6=20
subobject corresponding to the outbound interface address the rerouted=20
traffic is forwarded onto (both the "Local protection in use" and=20
"Local Protection Available" flags must be set).=20
=20
7.2.    Support of MPLS TE Fast Reroute for a stitched/nested TE LSP=20
=20
7.2.1.  Failure of an inter-AS link=20
=20
The case of inter-ASBR link protection for stitched/nested TE LSPs is=20
identical as with contiguous TE LSPs. =20
=20
7.2.2.  Failure of an ABR or an ASBR node=20
=20
The major difference with=20contiguous inter-area/AS TE LSP is that with=20
stitched/nested inter-area/AS TE, the MP for the inter-area/AS LSP MUST=20
always be an area/AS boundary LSR (ABR/ASBR). This is because the FA-
LSP/LSP segment is a different LSP (different session) from the inter-
area/AS LSP, so the inter-area/AS LSP backup can only intersect the=20
protected LSP path at the area/AS boundary LSRs. =20
=20
 Vasseur and Ayyangar                                               29=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Node protection of an exit ABR/ASBR=20
=20
Let us consider the inter-AS TE example where the objective is to=20
protect the fast re-routable inter-AS TE LSP from a failure of ASBR7 by=20
means of MPLS TE Fast Reroute.=20
=20
Considering the FA-LSP/LSP segment terminating at ASBR7, this is the=20
last hop for the FA-LSP/LSP segment, so there can be no node-protection=20
for ASBR7 via the FA-LSP/LSP segment. However, as far as the inter-AS=20
LSP is concerned, its path is along R0-ASBR1-ASBR4-ASBR7-ASBR9-R7 and=20
the FA-LSP/LSP segment between ASBR4 and ASBR7 is a link. So for=20
protecting against ASBR7's failure, ASBR4 is the PLR and ASBR4 will=20
setup a bypass tunnel to the NNHOP for this LSP, which is ASBR9. Again=20
the NNHOP is determined by examining the received RRO for the inter-
area/AS LSP. So one or more bypass tunnels following ASBR4-ASBR8-
ASBR10-ASBR9 must be set up on ASBR4 to protect against node ASBR7's=20
failure. =20
=20
It is worth mentioning that this adds some additional constraints on=20
the backup path since the bypass tunnel path needs to be diverse from=20
the ASBR4-ASBR7-ASBR9 path instead of just being diverse from the X-
ASBR7-ASBR9 path where X is the upstream neighbor of ASBR7. =20
=20
The consequences are that the path is likely to be longer and if=20
bandwidth protection is desired for instance ([FACILITY-BACKUP] more=20
resources may be reserved in AS2 than necessary.=20
=20
Node protection of an entry ABR/ASBR=20
=20
Let us now consider the protection of an entry ASBR: for instance=20
ASBR4.=20
=20
Again, in this case, the FA-LSP/LSP segment offers no protection; so=20
one or more backups MUST be set up from the previous hop LSR, i.e.=20
ASBR1, to the NNHOP with respect to the inter-AS TE LSP, which is in=20
this case ASBR7. A bypass tunnel ASBR1-ASBR3-ASBR6-ASBR7 would protect=20
against ASBR4's failure. Depending on whether auto-discovery mechanisms=20
are available, and whether TE-information for ASBR-ASBR links is=20
available, the configuration required on the PLR for the backup could=20
be minimal or could require specifying the entire path. =20
=20
The same constraints as mentioned above apply in this case resulting in=20
the same consequences in term of backup tunnel path sub-optimality.=20
=20
When the FA-LSP/LSP Segment is unnumbered, the Router ID of the=20
boundary LSR will be recorded in the RRO object (see [RSVP-UNNUM]).=20
However, if the FA-LSP/LSP segment is numbered, then bypass tunnel=20
selection to protect an inter-area/AS TE LSP with Fast Reroute=20
"facility backup" ([FAST-REROUTE]) against the failure of an ASBR-ASBR=20
link or an ASBR node would require the support of [NODE-ID].=20
=20
 Vasseur and Ayyangar                                               30=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
7.3.    Failure handling of inter-AS TE LSP=20
=20
In the context of MPLS Inter-area and inter-AS Traffic Engineering, if=20
a link/SRLG/Node failure occurs in an area/AS different from the head-
end LSR, the head-end LSR exclusively relies on the receipt of an RSVP=20
Path Error message to get informed that the TE LSP has suffered a=20
failure in a downstream AS (a =91=91Notify=92=92 Path Error =91=91Notify=92=
=92 message if=20
the inter-AS TE has been locally repaired via MPLS TE Fast Reroute. For=20
those reasons, as already mentioned, the Path Error message SHOULD be=20
sent in reliable mode ([REFRESH-REDUCTION]). Note that this requires to=20
configure the reliable messaging mechanisms proposed in [REFRESH-
REDUCTION] between every pair of LSRs in the network (more precisely=20
between every PLR and any potential head-end LSRs).=20
=20
Upon receiving an RSVP Path Error message, a head-end LSR must perform=20
a TE reroute (new route computation) in a make before break fashion. =20
=20
It is worth highlighting that the set up of inter-AS TE LSP might be=20
significantly slower than in the case of intra-area TE LSP:=20
=20
        - In scenario 1, the process may involve several ASBRs=20
        performing policy control, partial route computation (ERO=20
        expansions), =85 In case of set up failure, the number of trials=20
        can be significant, which even more increases the set up time.=20
        =20
        Furthermore, in case of dynamic loose hop computation, both the=20
        IGP and BGP reachability solutions have drawbacks in term of=20
        convergence upon failure. This is due to the slow convergence=20
        property of BGP. With BGP redistribution within ASes, the=20
        convergence might be even slower especially when BGP Route=20
        Reflectors are in use with no multi-paths load balancing.=20
=20
        - In scenario 2, some signaling exchange between several PCC=20
        and PCEs must be performed prior to setting up the TE LSP. Note=20
        that in scenario 2, the probability of TE LSP set up failure is=20
        limited to some lack of synchronization of the TE databases and=20
        as such is significantly lower than in the case of scenario 1.=20
=20
Moreover, in case of a large amount of inter-AS TE LSP set up, some non=20
negligible extra signaling and routing computation load will be=20
required on the loose hops (scenario 1) and loose hops/PCE (scenario=20
2). Some implementation may implement some pacing of inter-AS TE LSP=20
set up rate. Typically a link/node/SRLG failure may impact a large=20
number of TE LSPs. Relying on a local repair mechanism like MPLS TE=20
Fast Reroute allows to relax the load on ASBR/PCE and reduces the need=20
for urgent inter-AS TE LSP reroute. This is the recommended approach.=20
=20
8.      Reoptimization of an inter-area/AS TE LSP=20
=20

=20
 Vasseur and Ayyangar                                               31=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
The ability to reoptimize an existing inter-area/AS TE LSP path is of=20
course a requirement. The reoptimization process significantly differs=20
based upon the nature of the TE LSP and the mechanism in use for the TE=20
LSP path computation.=20
=20
If the head-end LSR uses a dynamic and distributed path computation=20
technique such as the PCE-based path computation (described in section=20
6), then the head-end LSR can leverage this to send re-optimization=20
requests to the PCE to obtain an optimal end-to-end path. On the other=20
hand, in the absence of such a mechanism, the following mechanisms can=20
be used for re-optimization, which are dependent on the nature of the=20
inter-area/AS TE LSP.=20
=20
8.1.    Contiguous TE LSPs=20
=20
8.1.1.  Per-area/AS path computation (scenario 1)=20
=20
After an inter-AS TE LSP has been set up, a more optimal route might=20
appear in the various traversed ASes. Then in this case, it is=20
desirable to get the ability to reroute an inter-AS TE LSP in a non-
disruptive fashion (making use of the so called Make Before Break=20
procedure) to follow this more optimal path. This is a known as a TE=20
LSP reoptimization procedure. =20
=20
[LOOSE-REOPT] proposes a mechanisms allowing:=20
=20
        - The head-end LSR to trigger on every LSR whose next hop is a=20
        loose hop the re evaluation of the current path in order to=20
        detect a potentially more optimal path. This is done via=20
        explicit signaling request: the head-end LSR sets the =91=91ERO=20
        Expansion request=92=92 bit of the SESSION-ATTRIBUTE object carried=
=20
        in the RSVP Path message.=20
        =20
        - An LSR whose next hop is a loose-hop to signal to the head-
        end LSR that a better path exists. This is performed by sending=20
        an RSVP Path Error Notify message (ERROR-CODE =3D 25), sub-code 6=20
        (Better path exists).=20
        =20
        This indication may be sent either:=20
=20
                - In response to a query sent by the head-end LSR,=20
                - Spontaneously by any LSR having detected a more=20
                optimal path =20
=20
Such a mechanism allows to reoptimize a TE LSP if and only if a better=20
path is some downstream area/AS is detected.=20
=20
The reoptimization event can either be timer or event-driven based (a=20
link UP event for instance).=20
=20

=20
 Vasseur and Ayyangar                                               32=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
Note that the reoptimization MUST always be performed in a non-
disruptive fashion.=20
=20
Once the head-end LSR is informed of the existence of a more optimal=20
path either in its head-end area/AS or in another AS, the inter-AS TE=20
Path computation is triggered using the same set of mechanisms as when=20
the TE LSP is first set up (per-AS path computation as in scenario 1 or=20
involving some PCE(s) in scenario 2). Then the inter-AS TE LSP is set=20
up following the more optimal path, making use of the make before break=20
procedure. In case of a contiguous LSP, the reoptimization process is=20
strictly controlled by the head-end LSR which triggers the make-before-
break procedure, regardless of the location where the more optimal path=20
is.=20
=20
8.1.2.  End to end shortest path computation (scenario 2)=20
=20
[PATH-COMP] provides the ability to request a path reoptimization. In=20
order to avoid double bandwidth accounting which could result in=20
falsely triggered call set up failure the requesting LSR just provides=20
the current path of the inter-area/AS TE LSP path to be reoptimized.=20
=20
8.2.    Stitched or nested (non-contiguous)=20TE LSPs=20
=20
In the case of a stitched or nested inter-areas/AS TE LSP, re-
optimization is treated as a local matter to any Area/AS. The main=20
reason is that the inter-area/AS TE LSP is a different LSP (and=20
therefore different RSVP session) from the intra-area/AS LSP segment or=20
FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is=20
done by locally reoptimizing the intra-area/AS LSP segments.  Since the=20
inter-area/AS TE LSPs are transported using LSP segments or FA-LSP=20
across an area/AS, optimality of the inter-area/AS LSP in an area/AS is=20
dependent on the optimality of the corresponding LSP segments or FA-
LSPs. If, after an inter-area/AS LSP is setup, a more optimal path is=20
available within an area/AS, the corresponding LSP segment(s) or FA-LSP=20
will be re-optimized using "make-before-break" techniques discussed in=20
[RSVP-TE]. Reoptimization of the LSP segment automatically reoptimizes=20
the inter-area/AS LSPs that the LSP segment transports. Reoptimization=20
parameters like frequency of reoptimization, criteria for=20
reoptimization like metric or bandwidth availability; etc can vary from=20
one area/AS to another and can be configured as required, per intra-
area/AS TE LSP segment or FA-LSP if it is preconfigured or based on=20
some global policy within the area/AS.=20
=20
So, in this scheme, since each area/AS takes care of reoptimizing its=20
own LSP segments or FA-LSPs, and therefore the corresponding inter-
area/AS TE LSPs, the make-before-break can happen locally and is not=20
triggered by the head-end LSR for the inter-area/AS LSP. So, no=20
additional RSVP signaling is required for LSP re-optimization and=20
reoptimization is transparent to the HE LSR of the inter-area/AS TE=20
LSP.=20
=20
=20
 Vasseur and Ayyangar                                               33=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
If, however, an operator desires to manually trigger reoptimization at=20
the head-end LSR for the inter-area/AS LSP, then this solution does not=20
prevent that. A manual trigger for reoptimization at the head-end LSR=20
SHOULD force a reoptimization thereby signaling a "new" path for the=20
same LSP (along the optimal path) making use of the make-before-break=20
procedure. In response to this new setup request, the boundary LSR may=20
either initiate new LSP segment setup, in case the inter-area/AS TE LSP=20
is being stitched to the intra-area/AS LSP segment or it may select an=20
existing FA-LSP in case of nesting. When the LSP setup along the=20
current optimal path is complete, the head end should switchover the=20
traffic onto that path and the old path is eventually torn down. Note=20
that the head-end LSR does not know a priori whether a more optimal=20
path exists. Such a manual trigger from the head-end LSR of the inter-
area/AS TE LSP is, however, not considered to be a frequent occurrence.=20
=20
Note that because stitching or nesting rely on local optimization, the=20
reoptimization process allows to locally reoptimize each TE LSP segment=20
or FA-LSP: hence, the reoptimization is not global and cannot guarantee=20
that the optimal path end to end is found.=20
=20
9.      Routing traffic onto inter-area/AS TE LSPs=20
=20
Once an inter-area/AS TE LSP has been set up, the head-end LSR has to=20
determine the set of traffic to be routed onto the TE LSP. =20
=20
In the case of intra-area/AS TE LSP, various options are available:=20
=20
        (1) modify the IGP SPF such that shortest path calculation can=20
        be performed taking into account existing TE LSP, with some=20
        path preference,=20
        =20
        (2) make use of static routing. Note that the recursive route=20
        resolution of BGP allows routing any traffic to a particular=20
        (MP)BGP peer making use of a unique static route pointing the=20
        BGP peer address to the TE LSP. So any routes advertised by the=20
        BGP peer (IPv4/VPNv4 routes) will be reached using the TE LSP.=20
        =20
With an inter-area/AS TE LSP, just the mode (2) is available, as the TE=20
LSP head-end does not have any topology information related to the=20
destination area/AS.=20
=20
10.     Evaluation criteria and applicability=20
=20
The aim of this section is to evaluate each proposed set of mechanisms=20
described above with respects to the set of requirements listed in=20
[INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS].=20
=20
10.1.   Path optimality=20
=20
Inter-area/AS TE LSP path optimality is one of the major differences=20
between the various path computation techniques. In scenario 1, the=20
=20
 Vasseur and Ayyangar                                               34=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
path is computed on a per-area/AS basis (making use of mechanisms like=20
auto-discovery based on IGP/BGP information) cannot guarantee to=20
compute an optimal (shortest) path across multiple areas/ASes. The=20
resulting TE LSP path is the first path obeying the required set of=20
constraints. This gets particularly true as TE LSP gets rerouted due=20
the network element failures. On the other hand, a path computation=20
mechanism like PCE (described in section 6) relies on a distributed=20
path computation algorithm involving multiple ABR/ASBRs acting as PCEs=20
(Path Computation Elements) which guarantees to compute the shortest=20
path end to end. Hence the PCE-based path computation method fully=20
complies with the requirements states in [INTER-AS-TE-REQS] to be able=20
to compute a shortest path end to end.=20
=20
10.2.   Reoptimization=20
=20
In the absence of a distributed path computation method like the PCE-
based, both the contiguous LSP and non-contiguous TE LSP=20
(stitching/nesting) solution allows for reoptimization but they=20
significantly differ in term of reoptimization process. A stitched or=20
nested TE LSP is reoptimized on a per-area/AS basis. Each ABR/ASBR=20
which is also the head-end LSR of an LSP segment or FA-LSP is=20
responsible for the local reoptimization of that LSP segment or FA-LSP=20
in the corresponding area/AS: in other words, the reoptimization=20
process is contained within an area/AS. The reoptimization criteria and=20
frequency is individually controlled by each head-end LSR (ABR/ASBR) of=20
the LSP segment/FA-LSP independently of other segments and is=20
transparent to the inter-area/AS TE LSP head-end LSR. The head-end LSR=20
of the inter-area/AS TE LSP could still enforce a reoptimization but=20
without knowing in advance whether a more optimal path actually exist=20
in some downstream area/AS. Note also that each reoptimization is=20
performed in a non-disruptive fashion (Make before break procedure). XX=20
Indeed, each reoptimization implies some jitter and potentially some=20
packet reordering usually undesirable for sensitive traffic. The use of=20
contiguous inter-area/AS TE LSP used in conjunction with [LOOSE-PATH-
REOPT] allows the head-end LSR to exert a strict control on the=20
reoptimization process and perform a reoptimization if and only if a=20
better path exists in some downstream area/AS. It relies on both a=20
polling mechanism upon which an inter-area/AS TE LSP head-end LSR can=20
poll the downstream nodes involved in partial path computation to learn=20
whether a better (shorter) path exists. In addition, a downstream node=20
can explicitly notify the head-end LSR of the existence of a better=20
path (such a notification can be governed by local policy: timer-based,=20
event-driven, =85). In any case, the decision is led to the head-end LSR=20
to perform an end to end reoptimization: it is expected that the head-
end LSR will make use of some dampening mechanism to control the=20
reoptimization frequency based on the inter-area/AS attributes. Note=20
that the inter-area/AS TE LSP is reoptimized in every area/AS and may=20
follow an identical path in some area(s)/AS(es).=20
=20
In scenario 2, when a distributed path computation mechanism like PCE=20
is used by the head-end LSR, an inter-area/AS TE LSP reoptimization is=20
=20
 Vasseur and Ayyangar                                               35=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
similar to a path computation with the exception that the path of the=20
inter-area/AS TE LSP is provided to the PCE to avoid any double=20
bandwidth accounting. The reoptimization procedure is entirely=20
controlled by the head-end LSR of the inter-area/AS TE LSP: this=20
includes the path computation request frequency, decision to trigger an=20
actual reoptimization (for example, the Head-end LSR may decide the=20
perform a reoptimization if and only if the new more optimal path meets=20
some specific requirements like a gain of x% in term of path cost=20
compared to the TE LSP in place).=20
=20
10.3.   Support of MPLS Traffic Engineering Fast Reroute=20
=20
As stated in [INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS], the support=20
of MPLS Traffic Engineering Fast Reroute is a strong requirement for=20
inter-area/AS TE LSP and MUST cover the case of an inter-area/AS=20
link/SRLG/Node failure, an inter-ASBRs link failure and an ABR/ASBR=20
node failure.=20
=20
The various solutions proposed in this document are equivalent in term=20
of recovery time but significantly differ in term of backup tunnel path=20
optimality. In the case of a fast reroutable contiguous TE LSP, the=20
backup tunnel computed to protect against an ABR/ASBR node failure=20
starts on the node immediately upstream to the ABR/ASBR and terminates=20
on the node immediately downstream to the ABR/ASBR. By contrast, the=20
computed backup tunnel to protect an inter-area/AS TE LSP making use of=20
the stitching/nesting method MUST start and terminate on a boundary LSR=20
(ABR/ASBR). =20
=20
Hence, in the case of inter-AS TE for example, in order to protect=20
against the failure of an exit ASBR, the backup tunnel must start on=20
the entry upstream ASBR in the AS and terminate on the entry ASBR in=20
the next-hop AS. In order the protect against the failure of entry=20
ASBR, the backup tunnel starts on the node immediately upstream to the=20
ASBR (exit ASBR on the upstream AS) and terminates on an exit ASBR in=20
the AS (on the tail-end LSR of the FA-LSP/segment). =20
=20
Such an additional constraint has the consequences for the backup=20
tunnel path to be potentially sub-optimal compared to the backup tunnel=20
path for a contiguous inter-area/AS TE LSP, hence implying more jitter=20
during Fast Reroute. Moreover, this potentially reduces the capability=20
to provide bandwidth protection and perform some efficient bandwidth=20
sharing between backup tunnels protecting independent resources.=20
Finally, this may increase the number of TE LSPs per mid-point LSR.=20
=20
10.4.   Support of diversely routed paths=20
=20
There are several circumstances where the ability to set up a set of=20
diversely routed TE LSP paths between two LSRs might be desirable:=20
=20
(1) Load balancing=20
=20
=20
 Vasseur and Ayyangar                                               36=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
When a single TE LSP path satisfying the required constraints cannot be=20
found between two LSRs, an alternative may consist in setting up N TE=20
LSP such that the sum of their bandwidth is equal to the total required=20
bandwidth. In addition, having diverse paths allows to limit the=20
traffic disruption in case of network element failure between the two=20
nodes to the set of affected TE LSPs.=20
=20
(2) Path Protection=20
=20
In some networks, Path protection is used to protect TE LSP from=20
link/SRLG/node failure. This requires setting up, for each TE LSP, a=20
set of diversely routed TE LSPs. In case of failure along the primary=20
TE LSP path, the node directly attached to the failed resources signals=20
to the head-end LSR that the TE LSP has failed, sending an RSVP Path=20
Error. The head-end LSR can also detect that the TE LSP has suffered a=20
failure when receiving an IGP update reflecting the failed resource.=20
Note that the head-end LSR cannot rely on the IGP topology database to=20
detect the failure if the failure does not occur in the Head-End=20
area/AS in the case of inter-area/AS TE. Once the head-end LSR learns=20
the failure, the traffic is switched onto the pre-established backup TE=20
LSP. Note that a set of TE LSP can potentially share a single backup TE=20
LSP (1:N protection).=20
=20
Scenario 1: per-AS path computation=20
=20
In the case of scenario 1, the set up of N diversely routed TE LSP=20
paths can be done using the following scenario:=20
=20
- Set up the first TE LSP among the set of N TE LSPs and include an=20
RSVP RRO object in the RSVP Resv message to record the Path,=20
=20
- For i=3D2 to N=20
        Set up the TE LSPi, excluding the elements traversed by the=20
        already set up TE LSP1, =85, TE LSP i-1. The exclusion of a set=20
        of resources from a TE LSP path can be performed on the head-
        end LSR by CSPF and in other ASes by the loose hops along the=20
        path, each of them performing the computation of a part of the=20
        TE LSP. This requires from the head-end to pass the =91=91exclude=92=
=92=20
        constraints (see [EXCLUDE-ROUTE]).=20
=20
Important note: such an algorithm does not guarantee that diverse paths=20
can be found for the successive TE LSPs since the TE LSP path are not=20
simultaneously computed, even if a possible solution exists. Also this=20
simple algorithm does not allow finding two paths such that the sum of=20
their cost is minimal. In case of an inter-area/AS path setup, it is=20
important to note that CSPF computation may be distributed over=20
different LSRs and also the path represented by the RRO, need not=20
represent physical links, they could be other FA-LSPs/LSP segments.=20
=20
Scenario 2: end to end shortest path computation: since both the=20
primary and secondary TE LSP paths are simultaneously computed by the=20
=20
 Vasseur and Ayyangar                                               37=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
distributed PCEs, it is possible to compute N diversely routed TE LSPs=20
if such paths exist, with possibly and/or if necessary different=20
constraints for both the primary and secondary inter-area TE LSPs.=20
[PATH-COMP] proposes some RSVP extensions to signal such a requirement.=20
=20
10.5.   Diffserv-aware MPLS TE=20
=20
There are no restrictions as far as Diffserv-aware MPLS TE is concerned=20
introduced by the mechanisms proposed in the document.=20
=20
10.6.   Hierarchical LSP support=20
=20
The non-contiguous TE LSP signaling for both nested TE LSPs is based on=20
LSP Hierarchy signaling. Furthermore, the nesting of multiple inter-
area/AS TE LSPs into an intra-area/AS FA LSP provides the Hierarchical=20
LSP support in both control and forwarding planes.=20
=20
10.7.   Policy Control at the AS boundaries=20
    =20
Policy control essentially applies to TE LSPs spanning multiple ASes=20
where each AS belongs to a different Operator. As stated in [INTER-AS-
TE-REQS], a set of configurable options may be made available upon=20
which ingress control policies can be implemented governing or honoring=20
inter-AS TE agreements made by two interconnect SPs. During the path=20
computation process, the inter-AS RSVP path message sent to its=20
downstream loose hop (ASBR also) in a different AS can be firstly=20
passed through an inter-AS TE policy control process on the downstream=20
ASBR prior to its ERO expansion. The inter-AS RSVP path setup request=20
will get rejected resulting in an path-error message which will be sent=20
to the head-end LSR should it fail the control policy: for example,=20
requesting bandwidth reservation more than agreed upon or wrong=20
preemption priorities. Another approach consists in performing some=20
constraint mapping. In the case of a contiguous TE LSPs, the local=20
policy can dictate some constraints rewrite in order to make a TE LSP=20
compliant with the agreements between the SPs. In the case of LSP=20
stitching or nesting, the operation is eased by the fact that a=20
different LSP segment or FA-LSP is established within the AS;=20
consequently, other constraints can be applied to this intra-area/AS=20
LSP segment or FA-LSP like different affinities, preemption,etc.=20
=20
10.8.   Inter-AS MPLS TE Management=20
=20
[LSPPING] proposes a solution which can be adopted for inter-AS TE LSPs=20
whereby a head-end LSR sends MPLS echo requests over the LSP being=20
tested. When the destination LSR receives the message, it needs to=20
acknowledge the source LSR by sending an LSP_ECHO object in a RSVP Resv=20
message.=20
=20
The TTL processing over inter-area/AS TE primary or local backup LSPs=20
will be supported as per [MPLS-TTL].=20
=20
=20
 Vasseur and Ayyangar                                               38=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
10.9.   Confidentiality=20
=20
Confidentiality issues essentially apply to the case of a TE LSP=20
spanning multiple ASes, where each AS belongs to a different Operator.=20
That being said, this can also apply to other scenarios where=20
confidentially must be preserved outside of some specific domain. As=20
mentioned in [INTER-AS-REQS], the solution should allow preserving AS=20
confidentiality, by hiding the set of hops followed by the inter-AS TE=20
LSP within an AS.=20
=20
In scenario 1, as far as TE LSP signaling using RSVP is concerned, this=20
requirement can be met via some proper RRO filtering at the AS=20
boundaries (this applies to the RRO object carried in both the Path and=20
Resv message). Note that, if MPLS TE Fast Reroute is required to=20
protect inter-AS TE LSP against the failure of an ASBR, the RRO object=20
carried in the Resv message of an inter-AS TE LSP must not be=20
completely filtered, as mentioned in section 8. As least, the=20
information (label, IPv4 or IPv6 subobject (node-id subobject))=20
pertaining to the next-hop ASBRs must be preserved.=20
=20
In scenario 2, the RSVP Path computation reply can be filtered to=20
provide a partial ERO (an ERO containing loose hops). If the agreement=20
between SPs at AS boundary is such that confidentiality must be=20
guaranteed, just a partial EROs be returned PCEs.=20
=20
For the sake of illustration, [PATH-COMP] proposes some signaling=20
extensions whereby the requesting LSR in ASx sends a Path computation=20
request to the PCE in AS y, with the "Partial" flag of the REQUEST-ID=20
object set. The PCE controls that this flag is appropriately set; if=20
not, the PCE might decide either to provide a partial ERO or to drop=20
the request.=20
=20
Note that even when the returned ERO is partial, the PCE should provide=20
the cost of the computed path. =20
=20
Again for illustration, [PATH-COMP] proposes that the path computation=20
reply includes a PATH-COST object in the RSVP Path computation reply=20
message. If the agreement between SPs at AS boundaries is such that=20
path cost might be provided, then the requesting LSR in ASx might send=20
a Path computation request to the PCE in ASy, with the "cost" flag of=20
the REQUEST-ID object set. The PCE controls that this flag is=20
appropriately set; if set, the PCE MUST include a PATH-COST object in=20
its RSVP Path Computation reply message. This is required to compute=20
end to end shortest path.=20
=20
=20
11.     Scalability and extensibility=20
=20
All the features related to intra-area TE LSP are also applicable to=20
inter-AS TE LSP, without any restriction.=20
=20
=20
 Vasseur and Ayyangar                                               39=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
12.     Security Considerations=20
=20
When signaling an inter-AS TE, an Operator may make use of the already=20
defined security features related to RSVP (authentication). This may=20
require some coordination between SPs to share the keys (see RFC 2747=20
and RFC 3097).=20
=20
=20
13.     Intellectual Property Considerations=20
=20
The IETF takes no position regarding the validity or scope of any=20
intellectual property or other rights that might be claimed to pertain=20
to the implementation or use of the technology described in this=20
document or the extent to which any license under such rights might or=20
might not be available; neither does it represent that it has made any=20
effort to identify any such rights. Information on the IETF's=20
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of=20
rights made available for publication and any assurances of licenses to=20
be made available, or the result of an attempt made to obtain a general=20
license or permission for the use of such proprietary rights by=20
implementors or users of this specification can be obtained from the=20
IETF Secretariat.=20
=20
The IETF invites any interested party to bring to its attention any=20
copyrights, patents or patent applications, or other proprietary rights=20
which may cover technology that may be required to practice this=20
standard. Please address the information to the IETF Executive=20
Director.=20
=20
=20
14.     Acknowledgments=20
=20
We would like to acknowledge input and helpful comments from Adrian=20
Farrel.=20
=20
=20
Normative References=20
=20
[RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) -
                                                             - Version=20
1, Functional Specification=92=92, RFC 2205, September 1997.=20
=20
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC=20
3209, December 2001.=20
=20
[REFRESH-REDUCTION] Berger et al, =91=91RSVP Refresh Overhead Reduction=20
Extensions=92=92, RFC2961, April 2001.=20
=20

=20
 Vasseur and Ayyangar                                               40=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for=20
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December=20
2003.=20
=20
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering=20
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress).=20
=20
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",=20
draft-ietf-isis-traffic-04.txt (work in progress)=20
=20
Informative references=20
=20
[BANDWIDTH-PROTECTION] Vasseur et all, =91=91MPLS Traffic Engineering Fast=
=20
reroute: bypass tunnel path computation for bandwidth protection =BB, =20
draft-vasseur-mpls-backup-computation-01.txt, October 2002, Work in=20
progress.=20
=20
[SECOND-METRIC] Le faucheur, =91=91Use of IGP Metric as a second TE=
 Metric=92=92,=20
Internet draft, draft-lefaucheur-te-metric-igp-02.txt.=20
=20
[MULTIPLE-METRICS] Fedyk D., Ghanwani A., Ash J., Vedrenne A. =91=91Multiple=
=20
Metrics for Traffic Engineering with IS-IS and OSPF=92=92, Internet draft, =
=20
draft-fedyk-isis-ospf-te-metrics-01.txt=20
=20
[PATH-COMP] Vasseur et al, =91=91RSVP Path computation request and reply=20
messages=92=92,  draft-vasseur-mpls-computation-rsvp-04.txt, work in=20
progress.=20
=20
[RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP",=20
work in progress.=20
=20
[OSPF-TE-CAP] Vasseur et al."OSPF TE TLV capabilities", draft-ccamp-
mpls-ospf-te-cap-00.txt, work in Progress.=20
=20
[OSPF-CAP] Lindem et all =91=91 Extensions to OSPF for Advertising Optional=
=20
Router Capabilities=92=92, draft-ietf-ospf-cap-01.txt, work in progress.=20
=20
[ISIS-CAP] Aggarwal et all, =91=91Extensions to IS-IS for Advertising=20
Optional Router Capabilities=92=92, work in progress=20
=20
[ISIS-CAPA] Vasseur et al, =AB IS-IS extensions for advertising optional=20
router capabilities =BB, draft-vasseur-isis-cap-00.txt, work in progress.=20
=20
[ISIS-TE-CAP] Vasseur et al, =91=91IS-IS TE TLV capabilities=92=92,=
 draft-vasseur-
ccamp-isis-te-cap-00.txt, work in progress.=20
=20
[LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for=20
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)=20
Establishment Using RSVP-TE", (work in progress).=20
=20
=20
 Vasseur and Ayyangar                                               41=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay=20
Model", (work in progress).=20
=20
[EXCLUDE-ROUTE] Lee et
                    all
                     ,
                       Exclude Routes - Extension to RSVP-TE, draft-
ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress.=20
    =20
[INTER-AREA-TE] Kompella et all,=92=92Multi-area MPLS Traffic Engineering=92=
=92,          =20
draft-kompella-mpls-multiarea-te-04.txt, work in progress.=20
=20
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,=20
Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",=20
Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. (Work=20
in Progress)=20
=20
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS  =20
Networks", RFC 3443 Updates RFC 3032) ", January 2003=20
=20
[INTER-AS-TE-REQS] Zhang et al, =91=91MPLS Inter-AS Traffic Engineering=20
requirements=92=92, draft-ietf-tewg-interas-mpls-te-req-06.txt, work in=20
progress.=20
=20
[INTER-AREA-TE-REQTS-1] Boyle J., "Requirements for support of Inter-=20
Area and Inter-AS MPLS Traffic Engineering", (work in progress).=20
=20
[INTER-AREA-TE-REQTS-2] Leroux et al, =91=91Requirements for Inter-area MPLS=
=20
Traffic Engineering=92=92, draft-leroux-tewg-interarea-mpls-te-req-00.txt,=
=20
work in progress.=20
=20
[LOOSE-PATH-REOPT] Vasseur and Ikejiri, =91=91Reoptimization of an explicit=
=20
loosely routed MPLS TE paths=92=92, draft-vasseur-ccamp-loose-path-reopt-
00.txt, June 2003, Work in Progress.=20
=20
[NODE-ID] Vasseur, Ali and Sivabalan, =91=91Definition of an RRO node-id=20
subobject=92=92,  draft-ietf-mpls-nodeid-subobject-02.txt, work in progress.=
=20
=20
[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized=20
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002.=20
=20
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS=20
Networks", RFC 3443 (Updates RFC 3032) ", January 2003.=20
=20
=20
Authors' Address:=20
=20
Jean-Philippe Vasseur=20
Cisco Systems, Inc.=20
300 Beaver Brook Road=20
Boxborough , MA - 01719=20
USA=20
Email: [email-masked]=20
=20
=20
 Vasseur and Ayyangar                                               42=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
Arthi Ayyangar=20
Juniper Networks, Inc=20
1194 N.Mathilda Ave=20
Sunnyvale, CA 94089=20
USA=20
e-mail: [email-masked] =20
=20
=20
Full Copyright Statement=20
=20
   Copyright (C) The Internet Society (2004). All Rights=20
   Reserved.=20
=20
   This document and translations of it may be copied and=20
   furnished to others, and derivative works that comment on=20
   or otherwise explain it or assist in its implementation may=20
   be prepared, copied, published and distributed, in whole or=20
   in part, without restriction of any kind, provided that the=20
   above copyright notice and this paragraph are included on=20
   all such copies and derivative works.  However, this=20
   document itself may not be modified in any way, such as by=20
   removing the copyright notice or references to the Internet=20
   Society or other Internet organizations, except as needed=20
   for the purpose of developing Internet standards in which=20
   case the procedures for copyrights defined in the Internet=20
   Standards process must be followed, or as required to=20
   translate it into languages other than English.=20
=20
   The limited permissions granted above are perpetual and=20
   will not be revoked by the Internet Society or its=20
   successors or assigns. This document and the information=20
   contained herein is provided on an "AS IS" basis and THE=20
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE=20
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT=20
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR=20
   PURPOSE.=20
=20
=20
=20
=20
=20
=20

=20
 Vasseur and Ayyangar                                               43=20
=20
=20

--=====================_197048580==_--

Delivery-date: Wed, 04 Feb 2004 18:40:40 +0000
Date: Wed, 4 Feb 2004 10:39:26 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: ASON Routing Requirements doc

On Wed, 4 Feb 2004, Kireeti Kompella wrote:

> Many thanks to the design team for their progress on ASON Routing
> Requirements!  To keep the ITU-T in the loop, the design team lead
> suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.

Here is a draft: please comment by Wed Feb 11, 5pm PST.  We would like
to send this Liaison to ITU-T Q12/15 and Q14/15 by Fri Feb 13, 2004.

Please excuse my complete inability to read a calendar :-)  (Thanks,
Steve for making me look again!)

Kireeti.

> --------------------------------------------------------------------
>
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 9, 2004
> Deadline: March 12, 2004
>
> Dear Mr. Lam,
>
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by March 12,
> 2004.  We look forward to ongoing collaboration with you regarding the
> use of IETF signaling and routing protocols for ASON.
>
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs

Delivery-date: Wed, 04 Feb 2004 18:33:37 +0000
Date: Wed, 4 Feb 2004 10:31:39 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen J Trowbridge <[email-masked]>
cc: [email-masked]
Subject: Re: ASON Routing Requirements doc

On Wed, 4 Feb 2004, Stephen J Trowbridge wrote:

> Kireeti,
> As you know ITU-T Q.14/15 has an interim meeting scheduled in Chicago from 16-20
> February. I think it would be most useful if you could strive to send the
> liaison statement in time for the beginning of that meeting rather than the end
> so that Q.14/15 can discuss it and respond.

Good point!

If there are no comments, I will send the Liaison immediately.  It
should be received prior to Tuesday's morning session.  Would that be
okay?

Kireeti.
-------

Delivery-date: Wed, 04 Feb 2004 18:04:22 +0000
Date: Wed, 04 Feb 2004 11:02:41 -0700
From: Stephen J Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: ASON Routing Requirements doc

Kireeti,
As you know ITU-T Q.14/15 has an interim meeting scheduled in Chicago from 16-20
February. I think it would be most useful if you could strive to send the
liaison statement in time for the beginning of that meeting rather than the end
so that Q.14/15 can discuss it and respond.
Regards,
Steve

On 2/4/2004 10:47 AM, Kireeti Kompella wrote:
> Many thanks to the design team for their progress on ASON Routing
> Requirements!  To keep the ITU-T in the loop, the design team lead
> suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.
> 
> Here is a draft: please comment by Monday Feb 16, 5pm PST.  In the
> absence of any comments, the following will go out as is to those
> mentioned below by Feb 20, 2004.
> 
> --------------------------------------------------------------------
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 9, 2004
> Deadline: March 12, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by March 12,
> 2004.  We look forward to ongoing collaboration with you regarding the
> use of IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 
> Kireeti.
> -------
> 

Delivery-date: Wed, 04 Feb 2004 17:55:44 +0000
Date: Wed, 4 Feb 2004 09:47:37 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: ASON Routing Requirements doc

Many thanks to the design team for their progress on ASON Routing
Requirements!  To keep the ITU-T in the loop, the design team lead
suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.

Here is a draft: please comment by Monday Feb 16, 5pm PST.  In the
absence of any comments, the following will go out as is to those
mentioned below by Feb 20, 2004.

--------------------------------------------------------------------

Liaison Statement
Source: CCAMP WG, IETF
To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
    Alex Zinin, IETF Routing Area Director
    Bill Fenner, IETF Routing Area Director
Approval: CCAMP WG
For: Action
Date: February 9, 2004
Deadline: March 12, 2004

Dear Mr. Lam,

This liaison is a follow-up to our recent liaison (October 2003)
regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
requirements.  We wish to inform Q14/15 that the Design Team has
prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
and the draft is submitted for review at CCAMP's March meeting.  We
would, therefore, appreciate any feedback on this draft by March 12,
2004.  We look forward to ongoing collaboration with you regarding the
use of IETF signaling and routing protocols for ASON.

                                     Kireeti Kompella & Adrian Farrel,
                                            IETF CCAMP WG Chairs

Kireeti.
-------

Delivery-date: Tue, 03 Feb 2004 20:49:19 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
Date: Tue, 03 Feb 2004 15:44:44 -0500

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Routing 
			  for Automatically Switched Optical Network (ASON)
	Author(s)	: D. Brungard
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
	Pages		: 17
	Date		: 2004-2-3
	
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-02.txt

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-reqts-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: Tue, 03 Feb 2004 00:15:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-mpls-preemption-00.txt
Date: Mon, 2 Feb 2004 23:46:17 -0000

All,

I have submitted a draft to attempt to start the process of resolving the pre-emption
debate.

The procedures are intended to be equally applicable to GMPLS.

It would be well for people to indicate their support, disapproval, or (equally valuable
to the assessment of the value of the draft) their apathy.
Comments should be made on the MPLS mailing list, not in CCAMP.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
Sent: Monday, February 02, 2004 9:04 PM
Subject: I-D ACTION:draft-farrel-mpls-preemption-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Multiprotocol Label Switching Pre-emption
> Author(s) : A. Farrel
> Filename : draft-farrel-mpls-preemption-00.txt
> Pages : 9
> Date : 2004-2-2
>
> Multiprotocol Label Switching (MPLS) signaling is documented in
> 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC 3209, using
> mechanisms inherited from 'Resource ReserVation Protocol --
> Version 1 Functional Specification', RFC 2205.
>
> MPLS includes the concept of pre-emption where, for administrative
> reasons such as contention for system resources, a new Label Switched
> Path (LSP) may displace an existing LSP.
>
> This document clarifies the procedures for MPLS pre-emption in the
> light of implementation experience. The procedures in this document
> update those described in RFC 2205 and RFC 3209, but apply only to
> RSVP-TE used in the MPLS context.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-preemption-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-preemption-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-mpls-preemption-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.
>

Delivery-date: Mon, 02 Feb 2004 22:26:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea
Date: Mon, 2 Feb 2004 17:21:23 -0000

FYI
----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Sent: Monday, February 02, 2004 3:48 PM
Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea

> There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, 
> Korea:
> 
> February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents)
> 
> All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be 
> submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions 
> (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate
> WG Chair before they can be processed or announced. WG Chair approval MUST be 
> received by Wednesday, February 4th, at 09:00 ET.
> 
> February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher)
> 
> All revised Internet-Drafts (-01 and higher) must be submitted by Monday, 
> February 16th, at 09:00 ET.
> 
> Initial and revised Internet-Drafts received after their respective cutoff dates 
> will NOT be made available in the Internet-Drafts directory OR announced, and will 
> have to be resubmitted.  Please do NOT wait until the last minute to submit.  
> The Secretariat will begin accepting Internet-Draft submissions starting Monday, 
> March 8th.
> 
> Thank you for your understanding and cooperation. If you have any questions or 
> concerns, then please send a message to [email-masked].
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th 
> IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html.

Delivery-date: Mon, 02 Feb 2004 20:58:05 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-01.txt
Date: Mon, 02 Feb 2004 15:54:54 -0500

--NextPart

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

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel
	Filename	: draft-ietf-ccamp-crankback-01.txt
	Pages		: 30
	Date		: 2004-2-2
	
In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) label switched path (LSP)
   setup requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to
   RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be
   retried on an alternate path that detours around blocked links or
   nodes. This offers significant improvements in the successful setup
   and recovery ratios for LSPs, especially in situations where a large
   number of setup requests are triggered at the same time.

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

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-crankback-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-crankback-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-crankback-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: Mon, 02 Feb 2004 17:24:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea
Date: Mon, 2 Feb 2004 17:21:23 -0000

FYI
----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Sent: Monday, February 02, 2004 3:48 PM
Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea

> There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, 
> Korea:
> 
> February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents)
> 
> All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be 
> submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions 
> (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate
> WG Chair before they can be processed or announced. WG Chair approval MUST be 
> received by Wednesday, February 4th, at 09:00 ET.
> 
> February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher)
> 
> All revised Internet-Drafts (-01 and higher) must be submitted by Monday, 
> February 16th, at 09:00 ET.
> 
> Initial and revised Internet-Drafts received after their respective cutoff dates 
> will NOT be made available in the Internet-Drafts directory OR announced, and will 
> have to be resubmitted.  Please do NOT wait until the last minute to submit.  
> The Secretariat will begin accepting Internet-Draft submissions starting Monday, 
> March 8th.
> 
> Thank you for your understanding and cooperation. If you have any questions or 
> concerns, then please send a message to [email-masked].
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th 
> IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html.

Delivery-date: Mon, 02 Feb 2004 14:14:41 +0000
Date: Mon, 02 Feb 2004 23:10:18 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked]
Subject: Re: Protection object in restoration signaling
Cc: [email-masked]

Hi Dimitri,

Please see inline.

On Sun, 01 Feb 2004 15:39:33 +0100,
[email-masked] wrote:

> hi, see in-line
> 
> Yoshihiko SUEMURA wrote:
> > P&R Design Team,
> > 
> > In the 1:1/Shared Mesh Restoration described in
> > draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> > secondary LSP is done only by a Path message. The Protection object is
> > carried only in a Path message.
> > However, I think a Resv message should also carry the Protection object.
> > 
> > Consider the following case.
> > 
> >    A-----------B
> >     \         /
> >      C-------D
> >     /         \
> >    E           F
> > 
> > A-B:     Primary LSP
> > A-C-D-B: Secondary LSP
> > E-C-D-F: Extra (preemptable) LSP
> > 
> > Activating the Secondary LSP using only a Path message may cause
> > unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> > LSP. 
> 
> here i would agree that there is a condition on the next_hop
> to delete the extra_lsp state before activating the xc for
> the secondary lsp and in order to guarantee this commit of
> the resources activation may be done upon resv reception
> 
> also the use of hard preemption before committing this
> operation decreases (if not completely elevates if used
> to commit action when received from D in this example)
> the time occurrence of this transient state:
> 
> - PathErr with PAth_State_Removed flag towards E and a PathTear
>    to the destination F
> - or a PathErr with Path_State_Removed flag towards F and a
>    PathTear towards E
> 
> therefore there are other faster triggers for this purpose
> the issue being at the end to either perform this operation
> as fast as possible when reaching the last common node,
> or simply delete in downstream direction and commit along
> the upstream direction as said above (there are more complex
> cases where this might be at the end more easy to process)
> 
> > This can be prevented by applying a two-way activation scheme using
> > both Path and Resv messages. 
> 
> nothing prevent this from the above (the paragraph that
> describes this doesn't say commit at the data plane this
> is left out to the implementation) some clarification in
> the document are certainly needed here
> 
> > You can delete the Extra LSP by the Path
> > message, and activate the Secondary LSP by the Resv message. 
> 
> you may want to apply this activation scheme, in such a case
> all the nodes would have their extra-traffic lsp deleted
> through the downstream path message

Yes. This is what I want to apply. I want to delete all the
extra-traffic LSPs through the downstream Path message, and then,
activate the secondary LSP through the upstream Resv message.

> 
> > However, if the Resv message for activation does not carry the
> > Protection object, it cannot be distinguished from a refresh Resv
> > message. This still causes unintended connection in the following case.
> > 
> > (1) At node C, a crossconnect for the Extra LSP is deleted when
> > receiving a Path message.
> >   
> > (2) Then, if node C receives a refresh Resv message from D, it sets up a
> > crossconnect for the Secondary LSP because it cannot distinguish the
> > refresh Resv message from a Resv message for activation.
> 
> referring to 2961 p12/13 don't see how see this could happen,
> would you clarify, in order to address this point in case, also
> the resv is considered implicitly here as trigger message

After (1), node C waits for the upstream Resv message for activating the
secondary LSP. However, it may receive a refresh Resv message (refresh
for a Resv message for PROVISIONING the secondary LSP) from D before
receiving the Resv for activation. Currently, C cannot distinguish it
from the Resv for activation because there is no difference between
their formats. This may trigger C to activate the secondary LSP
unintentionally before the downstream nodes delete their extra-traffic
LSPs.

Thank you,

Yoshihiko

> 
> > If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> > causes unintended connection between the Secondary LSP and the Extra LSP.
> > 
> > As a solution for the above problem, I propose to add the Protection
> > object to a Resv message. The unintended connection can be prevented
> > because you can distinguish a Resv message for activation from a refresh
> > Resv message by watching the S bit.
> 
> suggest to first clarify the previous point,
> 
> thanks,
> - dimitri.
> 
> > Best regards,
> > 
> > Yoshihiko
> > 
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA 
> > 
> > NEC Corporation
> > E-mail: [email-masked]
> > 
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [email-masked]
> E-mail : [email-masked]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 

-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [email-masked]

Delivery-date: Sun, 01 Feb 2004 21:43:21 +0000
Date: Sun, 01 Feb 2004 22:41:11 +0100
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: Protection object in restoration signaling

resend (apparently the mailing list bounced the message back)

---

hi, see in-line

Yoshihiko SUEMURA wrote:
> P&R Design Team,
> 
> In the 1:1/Shared Mesh Restoration described in
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> secondary LSP is done only by a Path message. The Protection object is
> carried only in a Path message.
> However, I think a Resv message should also carry the Protection object.
> 
> Consider the following case.
> 
>    A-----------B
>     \         /
>      C-------D
>     /         \
>    E           F
> 
> A-B:     Primary LSP
> A-C-D-B: Secondary LSP
> E-C-D-F: Extra (preemptable) LSP
> 
> Activating the Secondary LSP using only a Path message may cause
> unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> LSP. 

here i would agree that there is a condition on the next_hop
to delete the extra_lsp state before activating the xc for
the secondary lsp and in order to guarantee this commit of
the resources activation may be done upon Resv reception

also the use of hard preemption before performing this
operation decreases (if not completely elevates) if used
to commit action when received from D in this example,
the time occurrence of this transient state:

- PathErr with PAth_State_Removed flag towards E and a PathTear
   to the destination F
- or a PathErr with Path_State_Removed flag towards F and a
   PathTear towards E

therefore there are other faster triggers for this purpose
the issue being at the end to either perform this operation
as fast as possible when reaching the last common node,
or simply delete in downstream direction and commit along
the upstream direction as said above (there are more complex
cases where this might be at the end more easy to process)

> This can be prevented by applying a two-way activation scheme using
> both Path and Resv messages. 

nothing prevent this from the above (the paragraph that
describes this doesn't say commit at the data plane this
is left out to the implementation) some clarification in
the document are certainly needed here

> You can delete the Extra LSP by the Path
> message, and activate the Secondary LSP by the Resv message. 

you may want to apply this activation scheme, in such a case
all the nodes would have their extra-traffic lsp deleted
through the downstream path message (thanks for pointing
this)

> However, if the Resv message for activation does not carry the
> Protection object, it cannot be distinguished from a refresh Resv
> message. This still causes unintended connection in the following case.
> 
> (1) At node C, a crossconnect for the Extra LSP is deleted when
> receiving a Path message.
>   
> (2) Then, if node C receives a refresh Resv message from D, it sets up a
> crossconnect for the Secondary LSP because it cannot distinguish the
> refresh Resv message from a Resv message for activation.

referring to 2961 p12/13, don't see how see this could
happen, would you clarify in order to address this point
in case, also the resv is considered implicitly here as
trigger message

> If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> causes unintended connection between the Secondary LSP and the Extra LSP.
> 
> As a solution for the above problem, I propose to add the Protection
> object to a Resv message. The unintended connection can be prevented
> because you can distinguish a Resv message for activation from a refresh
> Resv message by watching the S bit.

suggest to first clarify the previous point,

thanks,
- dimitri.

> Best regards,
> 
> Yoshihiko
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> NEC Corporation
> E-mail: [email-masked]
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sun, 01 Feb 2004 08:48:01 +0000
Date: Sun, 01 Feb 2004 16:50:22 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked]
Subject: Protection object in restoration signaling
Reply-To: [email-masked]

P&R Design Team,

In the 1:1/Shared Mesh Restoration described in
draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
secondary LSP is done only by a Path message. The Protection object is
carried only in a Path message.
However, I think a Resv message should also carry the Protection object.

Consider the following case.

   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP

Activating the Secondary LSP using only a Path message may cause
unintended connection (A-C-D-F) between the Secondary LSP and the Extra
LSP. This can be prevented by applying a two-way activation scheme using
both Path and Resv messages. You can delete the Extra LSP by the Path
message, and activate the Secondary LSP by the Resv message. 
However, if the Resv message for activation does not carry the
Protection object, it cannot be distinguished from a refresh Resv
message. This still causes unintended connection in the following case.

(1) At node C, a crossconnect for the Extra LSP is deleted when
receiving a Path message.
  
(2) Then, if node C receives a refresh Resv message from D, it sets up a
crossconnect for the Secondary LSP because it cannot distinguish the
refresh Resv message from a Resv message for activation.
    
If (2) occurs before D deletes a crossconnect for the Extra LSP, it
causes unintended connection between the Secondary LSP and the Extra LSP.

As a solution for the above problem, I propose to add the Protection
object to a Resv message. The unintended connection can be prevented
because you can distinguish a Resv message for activation from a refresh
Resv message by watching the S bit.

Best regards,

Yoshihiko

-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [email-masked]

Delivery-date: Sun, 29 Feb 2004 09:11:52 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Sun, 29 Feb 2004 18:12:52 +0900

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_001_01C3FEA4.35579AF2
Content-Type: text/plain;
	charset="euc-kr"

Hi,

Thank you for your detailed explanation.

For your example of the call request for EPL of 10 M that I think is a uni-
directional case, 
if a GMPLS signaling protocol is used, maybe two LSPs will be established
with only uni-diretional connections
because their paths are different each other. The case is not my hope.

My intention is not to simplify the LCAS operation itself, but to simplify
the initiation processes invoked by EMS/NMS systems.

As indicated in G.7042, the operation of LCAS is uni-directional. This
means that in order to bi-directionally add or remove members the procedure
has to be repeated in the opposite direction.

If the two uni-directional(downstream and upstream) connections for a call
request have the same route,
EMS/NMS systems should invoke two times of the LCAS operations towards
ingress and egress nodes.
I want to reduce into only one time using a GMPLS signaling protocol.

Thanks,

Young.

------_=_NextPart_001_01C3FEA4.35579AF2
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[Re] Re: [Re] Re: =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your detailed explanation.</FONT>
</P>

<P><FONT SIZE=3D2>For your example of the call request for EPL of 10 M =
that I think is a uni-directional case, </FONT>
<BR><FONT SIZE=3D2>if a GMPLS signaling protocol is used, maybe two =
LSPs will be established with only uni-diretional connections</FONT>
<BR><FONT SIZE=3D2>because their paths are different each other. The =
case is not my hope.</FONT>
</P>

<P><FONT SIZE=3D2>My intention is not to simplify the LCAS operation =
itself, but to simplify</FONT>
<BR><FONT SIZE=3D2>the initiation processes invoked by EMS/NMS =
systems.</FONT>
</P>

<P><FONT SIZE=3D2>As indicated in G.7042, the operation of LCAS is =
uni-directional. This means that in order to bi-directionally add or =
remove members the procedure has to be repeated in the opposite =
direction.</FONT></P>

<P><FONT SIZE=3D2>If the two uni-directional(downstream and upstream) =
connections for a call request have the same route,</FONT>
<BR><FONT SIZE=3D2>EMS/NMS systems should invoke two times of the LCAS =
operations towards ingress and egress nodes.</FONT>
<BR><FONT SIZE=3D2>I want to reduce into only one time using a GMPLS =
signaling protocol.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Young.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FEA4.35579AF2--

Delivery-date: Sun, 29 Feb 2004 04:47:08 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Subject: Notices Required in IETF Documents
Date: Sun, 29 Feb 2004 04:44:36 +0000

All editors and authors, 

Please note the new RFC3667 on intelectual property rights and copyrights. 

In particular, section 5. "Notices Required in IETF Documents" modifies the 
boiler-plate requirements for inclusion in your drafts. 

Please read and update your drafts accordingly. 

Thanks,
Adrian