Subject: RE: Crankback [Was: Running out of RSVP-TE bits?]
From: "Don Fedyk" <[email-masked]>
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Date: Wed, 23 Jul 2003 22:01:40 -0400

Curtis

Comments inline:

> -----Original Message-----
> From: Curtis Villamizar

<snip> 
> Rarely is the minimal case of much interest compared to cases
> where a feature is exercised heavily.  This is no exception.
> 
> Links occasionally fail, sometimes even routers fail.  ISPs
> have reported (publicly I think, but at least privately) to 
> have more than 1,000 RSVP/TE LSPs through a single node with 
> close to 1,000 on a single link.  The ingress for those 
> failures would be many 10s of routers in either direction.  
> Topologies are meshed but not densely meshed.  This means 
> that these many 10s of ingress are all going to go for the 
> same resource which is now the best after the failure.  
> Setups occur very fast.  Often a large percentage of the LSPs 
> will fail admission.
> 
> This is an interesting case.  It is not mearly hypothetical,
> it is a common real world case.

I agree here. The value of crankback or feedback at the moment these LSPs
fail admission and signal back to the source is the key point.  There is a
race condition for the LSA (or other mechanisms when you get to multiarea).
The value of crankback avoids wasted control cycles either waiting for the
LSAs or (worse) retrying the same failed path. It is not a replacement for
the LSA nor is its scope as wide.  It piggybacks on existing signaling. 

<snip>
> 
> I am looking at MPLS as a means to setup very long lived
> connections for the purpose of traffic engineering an ISP 
> network.  These connections are intended to never go down if 
> that were possible.  When the network is quiescent there are 
> few if any setups.  Any setups during quiescent periods would 
> be due to residual optimizations as a result of prior change 
> to the network or change to reservable bandwidth of tunnels 
> that routinely occur (often weekly) as a result of evaluation 
> of prior traffic patterns.  These occasional setups during 
> quiescent periods are spaced far enough appart that it is 
> very rare not to have exact information.  It is only when a 
> major event, such as a link down, occurs that resource 
> contention occurs and then quite massive resource contention 
> occurs over a brief period.  In this case flooding the fact 
> that the resource is exhausted makes good sense.  Again, 
> flooding every change immediately is not at all practical, 
> but amount of change and time based triggers, combined with 
> immediate trigger on resource allocation failure makes sense.

The value of crankback here depends on the impact of the loss of the LSP. If
the LSP going down only means you don't have TE path and shortest path
routing kicks in, in the meantime, crankback only provides a minimal
improvement. 

> 
> I personally believe that MPLS using RSVP/TE was not intended
> for call routing of short lived connections and I have very 
> strong basis in past IETF meetings and mailing list 
> correspondence to support that.

Even long term connections that have no alternative routing when the
connection is down benefit from crankback or feedback. This is the case with
GMPLS. 

> 
> I also think that useless or not, we may end up implementing
> crankback simply because people either think we're solving 
> call routing of short connections, or people mistakenly think 
> crankback to be a good solution for the ISP situation.  
> Hopefully no implementor will think that crankback is a 
> viable substitute for reflooding when a resource allocation fails.

This is not a short lived LSP problem in my view. This is about making the
best call routing decisions without wasting or burning control plane cycles
during the interesting case you mentioned. You should reflood at an
appropriate rate but pushing flooding to a maximum rate _still_ leaves race
conditions between Signaling and LSAs. Crankback or feedback a good way to
address the race conditions for a low cost and allowing flooding at an
optimal interval.  

> Curtis
> 
> 

Cheers,
Don

Envelope-to: [email-masked]
Delivery-date: Wed, 23 Jul 2003 13:40:27 +0000
Message-ID: <[email-masked]>
From: "Don Fedyk" <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Crankback [Was: Running out of RSVP-TE bits?]
Date: Wed, 23 Jul 2003 09:37:05 -0400

Adrian

Two points in support of your arguments:

Crankback and our related draft feedback have proven with running code in
many systems to improve the response to failures. 

Historically both systems started by relying on the solely on IGP and then
improving the situation where the IGP cannot/should not keep up with the
rapid changes in bandwidth (not connectivity) that happen with a
redistribution of paths. 

Cheers,
Don

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, July 22, 2003 7:44 AM
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]
> Subject: Crankback [Was: Running out of RSVP-TE bits?]
> 
> 
> Curtis,
> 
> I think you have possibly missed the chief use of crankback 
> and focused on a side use.
> 
> The principal use is to handle LSP setup failures. When these 
> happen they tend to happen one at a time (that is not a whole 
> bunch of impacted LSPs that were using a link that has 
> failed). Crankback allows nodes on the LSP to attempt to 
> re-direct the LSP setup attempt without failing it back to 
> the ingress, and allows the collection of more detailed 
> failure information to aid the re-direction process.
> 
> In a nutshell, crankback targets rapid re-direction of LSP 
> setup attempts without waiting for IGP convergence. That 
> crankback can also be used for handling failed LSPs is an 
> 'interesting' additional feature.
> 
> Note that in no case does crankback increase the error 
> reporting message flow. It simply adds a little information 
> to error messages already used in RSVP-TE or GMPLS. In fact, 
> if crankback is in use and intermediate nodes are enabled as 
> crankback repair points, crankback can reduce the error 
> reporting message flows since they don't have to go all the 
> way to the ingress nodes.
> 
> > > Perhaps you could summarize some of the problems crankback will 
> > > cause. It would be good to get comments on these problems 
> from the 
> > > ITU-T members who have made this an ASON requirement.
> >
> > After a link fails zero to a large number of admission failures may 
> > occur on a few links that are considered desireable alternates (by 
> > multiple LSP ingress, each acting independently).  Crankback will 
> > provide individual signals to each ingress, probably for 
> each LSP that 
> > failed.
> 
> Well now: the number of signals is not a function of 
> crankback. It is an existing function of RSVP-TE error 
> reporting. Crankback simply adds information to the error 
> reporting so that the error may be repaired. It also 
> recognizes that non-ingress nodes may wish to repair errors.
> 
> > Just using the IGP flooding is far more efficient and proactively 
> > tells ingress that haven't sent LSP paths over the now overloaded 
> > link.
> 
> Efficiency is in the eye of the beholder on this issue. The 
> debate over flooding or signaling errors will probably go on 
> for a while (see Richard Rabbat's work in ccamp on the need 
> for a flooding mechanism for fail-over to a protection LSP 
> that may be carrying extra traffic). The efficiency surely 
> depends on the number of LSPs and the number of nodes/links 
> in the network.
> 
> To repeat: the crankback draft doesn't make any assumptions 
> about the efficiency, it simply uses existing mechanisms. In 
> fact, there is a significant issue with the use of a flooding 
> mechanism. Viz. the ingress may not be able to tell from a 
> description of the faulted resource which LSPs were impacted 
> - suppose a component link fails, or even an individual 
> laser. (You might as well say that soft pre-emption should be 
> reported through
> flooding!)
> 
> > Of course if you write specs before trying things you often 
> get things 
> > wrong, particularly where the dynamics of a protocol are concerned. 
> > That's where the running code thing comes in.
> 
> I agree with you whole-heartedly. It is so important to have 
> running code. Not sure why you bring it up in this context. 
> Are you trying to imply something?
> 
> > I think testing in an
> > environment where lots of LSP from many ingress traverse a 
> link that 
> > fails and all route to one or two links that become 
> overloaded should 
> > be a prerequisite for crankback, with improvement demonstrated.
> 
> As in my preamble, this is not what crankback is about.
> 
> >
> > Curtis
> >
> > ps - who cares about ASON?  or ITU for that matter?  :-)
> 
> Cheers,
> Adrian
> 
> 
> 

Delivery-date: Tue, 22 Jul 2003 21:15:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Crankback [Was: Running out of RSVP-TE bits?]
Date: Tue, 22 Jul 2003 12:43:39 +0100

Curtis,

I think you have possibly missed the chief use of crankback and focused on a side use.

The principal use is to handle LSP setup failures. When these happen they tend to happen
one at a time (that is not a whole bunch of impacted LSPs that were using a link that has
failed). Crankback allows nodes on the LSP to attempt to re-direct the LSP setup attempt
without failing it back to the ingress, and allows the collection of more detailed failure
information to aid the re-direction process.

In a nutshell, crankback targets rapid re-direction of LSP setup attempts without waiting
for IGP convergence. That crankback can also be used for handling failed LSPs is an
'interesting' additional feature.

Note that in no case does crankback increase the error reporting message flow. It simply
adds a little information to error messages already used in RSVP-TE or GMPLS. In fact, if
crankback is in use and intermediate nodes are enabled as crankback repair points,
crankback can reduce the error reporting message flows since they don't have to go all the
way to the ingress nodes.

> > Perhaps you could summarize some of the problems crankback will cause.
> > It would be good to get comments on these problems from the ITU-T members who
> > have made this an ASON requirement.
>
> After a link fails zero to a large number of admission failures may
> occur on a few links that are considered desireable alternates (by
> multiple LSP ingress, each acting independently).  Crankback will
> provide individual signals to each ingress, probably for each LSP that
> failed.

Well now: the number of signals is not a function of crankback. It is an existing function
of RSVP-TE error reporting.
Crankback simply adds information to the error reporting so that the error may be
repaired. It also recognizes that non-ingress nodes may wish to repair errors.

> Just using the IGP flooding is far more efficient and
> proactively tells ingress that haven't sent LSP paths over the now
> overloaded link.

Efficiency is in the eye of the beholder on this issue. The debate over flooding or
signaling errors will probably go on for a while (see Richard Rabbat's work in ccamp on
the need for a flooding mechanism for fail-over to a protection LSP that may be carrying
extra traffic). The efficiency surely depends on the number of LSPs and the number of
nodes/links in the network.

To repeat: the crankback draft doesn't make any assumptions about the efficiency, it
simply uses existing mechanisms. In fact, there is a significant issue with the use of a
flooding mechanism. Viz. the ingress may not be able to tell from a description of the
faulted resource which LSPs were impacted - suppose a component link fails, or even an
individual laser. (You might as well say that soft pre-emption should be reported through
flooding!)

> Of course if you write specs before trying things you often get things
> wrong, particularly where the dynamics of a protocol are concerned.
> That's where the running code thing comes in.

I agree with you whole-heartedly. It is so important to have running code.
Not sure why you bring it up in this context. Are you trying to imply something?

> I think testing in an
> environment where lots of LSP from many ingress traverse a link that
> fails and all route to one or two links that become overloaded should
> be a prerequisite for crankback, with improvement demonstrated.

As in my preamble, this is not what crankback is about.

>
> Curtis
>
> ps - who cares about ASON?  or ITU for that matter?  :-)

Cheers,
Adrian

Delivery-date: Mon, 21 Jul 2003 09:57:07 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: rfc 3473 notify security
Date: Mon, 21 Jul 2003 11:54:23 +0200

hi all,

at the last ietf meeting allison mankin pointed to rfc 3473 as being 
relevant for the nsis working group (from a protocol and security point of 
view). reading the security section i noticed that the notify message is 
sent in a non hop-by-hop fashion and therefore cannot be secured using the 
rsvp available security mechanisms (i.e. integrity object).

the usage of ipsec is suggested for protection. working on the "rsvp 
security properties" document i realized that ipsec protection for rsvp is 
not a simple task (due to a number of rsvp protocol characteristics).

if the notify message is sent using raw ip (protocol type 46) then it is not 
possible to secure the message appropriately since ike, ikev2 or kink are 
able to negotiate this type of traffic selector.

possible solution:

a) disable the non hop-by-hop transmission of the notify message
b) use udp encapsulation (although depricated)

considering the additional overhead of securing the notify message it seems 
to be much easier to consider (a) as a viable option.

(b) would allow the source/destination udp ports to be used as a traffic 
selector (in addition to the src/dst ip address).

further thoughs?

ciao
hannes

_________________________________________________________________
Messenger  -  Wer in Echtzeit kommunizieren will, lädt den MSN Messenger. 
Cool, kostenlos und mit 3D Emoticons:  http://messenger.msn.de

Delivery-date: Thu, 17 Jul 2003 19:15:27 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>, "MPLS" <[email-masked]>, "PPVPN" <[email-masked]>, "PEW3" <[email-masked]>
Cc: "Tom Nadeau" <[email-masked]>, "Monique J. Morrow" <[email-masked]>
Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers
Date: Thu, 17 Jul 2003 12:13:51 -0700

Folks,

Thanks to those who responded to our earlier announcement of
this Feature Topic issue, with an intent to contribute.

For those who may have missed the earlier email, or for those
who've been working in this area and thinking of contributing, we'd
very much encourage you to consider sending in your contributions.
It is your high-quality papers, thoughts, and insights that will
make this issue a valuable one for our industry.

So, if you'd like to submit a paper or if you have a question
or clarification, please do drop one of the Guest Editors a note, as that
is very useful in helping us plan the issue.

We look forward to your participation!

Thanks,
-Vishal

PS: The submission process is automated and very easy. Pl. check
instructions below.
*************************************
Vishal Sharma
Metanoia, Inc.
http://www.metanoia-inc.com
*************************************

====================================================================
CALL FOR PAPERS
IEEE Communications Magazine

Feature Topic on "OAM in MPLS-Based Networks"
**********************************************

As carriers and service providers converge multiple services and
associated networks on to an MPLS-based infrastructure, OAM functionality
becomes pivotal for enabling them to provide service level agreement
(SLA) guarantees, service assurance, quality of service (QoS) assurance
and overall interworking service management.  The advent of new applications
of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3
Virtual Private Networks (L3VPNs) also means the emergence of added OAM
requirements from operators deploying those networks. As a result, providers
today require more efficient means of monitoring network health,
performance, and robustness, and of quickly identifying and resolving
performance problems. This is leading to the emergence of improved or
novel tools and techniques, whose goal is to improve security and
billing/accounting, aid in verifying QoS commitments, and reduce
operating costs. Standards organizations such as the IETF and the
ITU have in the recent past done significant work in this area, and
this subject is also being investigated by the IEEE and the Metro
Ethernet Forum.

This feature topic issue of the IEEE Communications Magazine has
a dual focus: to highlight operator requirements and deployment
experiences with OAM in MPLS-based networks, and to present a
survey of the current engineering and research developments in
this area.

Thus, focused tutorial and survey contributions as well as
research papers are solicited on (but not limited to) the following:

* Operational consequences of inadequate OAM capabilities
* Service provider requirements for efficient OAM - current operational
  needs and future demands
* Deployment experiences with OAM over MPLS-based networks
* Overview or comparative analysis of different
  approaches/philosophies for OAM
* Standards activities
	o Emerging architectures
	o New mechanisms for OAM in development
         (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit
         connection verification (VCCV))
* Platform support for OAM
* OAM impact on edge services (such as metro Ethernet)
  using MPLS transport
* Interoperability issues, interworking with
  other technologies (e.g. ATM)
* Review of current research in the area - E.g. setting
  parameters for connectivity verification and their impact on
  LSP recovery, trade-offs between bandwidth usage by OAM traffic
  and efficiency of failure/anomaly detection, and results from testbed
  deployments or simulations

On-line CFP with submission instructions can be found at:
http://www.comsoc.org/pubs/commag/cfpcommag1004.htm

Submission

Articles should be tutorial in nature and should be written in
a style comprehensible to readers outside the specialty of the article.
Articles may be edited for clarity and grammatical accuracy, and
will be copyedited according to the Magazine's style. Mathematical
equations should not be used (in justified cases up to three simple
equations could be allowed, provided the consent of the Guest Editor;
more than three equations require permission from the Editor-in-Chief).
Articles should have no more than 4,500 words, no more than 6
tables/figures, and no more than 15 references. Guidelines for prospective
authors can be found on-line at:
http://www.comsoc.org/pubs/commag/sub_guidelines.html.
Please submit no later than November 30, 2003. Accepted papers will
also be included in Communications Interactive (CI), the online version
of Communications Magazine.

Schedule:

Manuscript Due:                November 30, 2003
Acceptance Notification:       February 28, 2004
Final Manuscript Due:          April 15, 2004
Publication Date:              October 2004

Guest Editors:

Monique J. Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland

Email: [email-masked]

Tom Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824, USA.

Email: [email-masked]

Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041, USA.

Email: [email-masked]

About the IEEE Communications Magazine:

The IEEE Comm. Mag. is the official technical publication of
conferences such as Supercomm, and has the unique distinction of
being the most widely read IEEE journal, with its over 50,000 paid
subscribers representing key communications engineers and
technical managers in our industry. More information
on the IEEE Comm. Mag., may be found here:
www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt

Delivery-date: Thu, 17 Jul 2003 15:38:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: Running out of RSVP-TE bits? 
Date: Thu, 17 Jul 2003 16:36:48 +0100

Hi Curtis,

Thanks for your opinion.

> > draft-iwata-mpls-crankback-06.txt uses all of the remaining
> > Session Attribute bits.
>
> Get rid of draft-iwata-mpls-crankback-06.txt.  It will cause more
> problems than it will solve, not just due to the use of RRO bits.

It doesn't use any RRO bits.
Perhpas you could summarize some of the problems crankback will cause.
It would be good to get comments on these problems from the ITU-T members who have made
this an ASON requirement.

> Soft preempt is a ISP requested feature (Global Crossing) and clearly
> the most useful of the features requesting this bit space.

That is not at issue.
The question is how to manage the remaining bits and how to handle future needs for bits.

> There may be other ways to accommodate the needs of
> draft-ietf-mpls-nodeid-subobject-01.txt, namely a new sub-object type
> for a IPv4 or IPv6 address that happens to be a router-ID.

Indeed.

Adrian

Delivery-date: Thu, 17 Jul 2003 12:12:38 +0000
Date: Thu, 17 Jul 2003 05:06:42 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Jonathan Sadler <[email-masked]>
cc: [email-masked], "" <[email-masked]>, "" <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard

Betts, Brungard, Dotaro, Grammel, Kompella, Papadimitriou, Prattico,
Sadler, Vigoureux and Zinin got together to iron out the last few
issues in the document "Routing Extensions in Support of GMPLS".

In the interests of progressing this document in a timely fashion,
we examined these issues from two points of view:
a) is the current document set fundamentally broken, and if not, what
   caveats should be stated?
b) how do we move forward and address these issues, whether in the
   current doc set or in the future?

The consensus we reached for (a) is that the current doc set is okay in a
single layer network, but it doesn't capture inter-layer relationships.
So, we will state that in draft-ietf-ccamp-gmpls-routing-06.txt, and
then progress it.

As for (b), this will be one of the charter items for the ASON Routing
Reqts DT.  They will be chartered to state clearly what the requirements
are, what relations should be captured in a technology/layer independent
document, and what should be part of the layer-dependent documents.
These will then be addressed in future documents.

Many thanks to all who took part for getting together on such short
notice, and for the courteous and productive discussion!

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Wed, 16 Jul 2003 07:32:04 +0000
Message-Id: <[email-masked]>
From: "The IESG" <[email-masked]>
To: IETF-Announce: ;
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
Subject: Document Action: 'Tracing Requirements for Generic Tunnels' to an Informational RFC (Revised)
Date: Wed, 16 Jul 2003 03:28:04 -0400

The IESG has approved the Internet-Draft 'Tracing Requirements for Generic 
Tunnels' <draft-ietf-ccamp-tracereq-05.txt> as an Informational RFC. This 
document is the product of the Common Control and Measurement Plane Working Group.
                                                                                
The IESG contact person is Bert Wijnen.

Delivery-date: Tue, 15 Jul 2003 16:39:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Running out of RSVP-TE bits?
Date: Tue, 15 Jul 2003 17:37:02 +0100

[cross-posted to ccamp and mpls lists]

Hi,

After a couple of conversations today I wonder if we should worry
about the way we allocate bits from the flags fields in the
Session Attribute object and the RRO subobject.

These flags are very rare and we need to assign them with the
greatest care. Is there currently any policy for managing this
resource to ensure that there will still be bits available when
they are needed? Or can we simply use them on a first-come,
first-served basis?

Note that draft-ietf-mpls-nodeid-subobject-01.txt takes the use of
the RRO subobject flag up to all but two bits used.
draft-iwata-mpls-crankback-06.txt uses all of the remaining
Session Attribute bits.

Thanks,
Adrian

Delivery-date: Tue, 15 Jul 2003 15:53:23 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Roberto Albanese'" <[email-masked]>, <[email-masked]>
Cc: "'fabio'" <[email-masked]>, "'Listanti'" <[email-masked]>, <[email-masked]>, "Richard Rabbat" <[email-masked]>
Subject: RE: Flooding using LMP extensions
Date: Tue, 15 Jul 2003 08:48:29 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C34AAD.DF9D2000
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for reading the document and extensive feedback. Please see my
comments inline.

=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of Roberto Albanese
> Sent: Monday, July 14, 2003 8:29 AM
> To: Richard Rabbat; [email-masked]
> Cc: fabio; Listanti; [email-masked]
> Subject: Re: Flooding using LMP extensions

>

> Hi Richard, hi all,
> i read your drafts and i' d like to make you some questions:
>
> -  in section 5.3.1 is written that=20
>   "in order for the protection algorithm to abide by=20
>    the T-rec ms recovery requirement, it needs to be either:=20
>     1. Aware of timing issues to be able to select=20
>        a proper path, or
>     2. Passed a set of nodes and links that satisfy=20
>        the timing constraints.
> =20
>    Due to the complexity of the first method, we believe=20
>    that the second method will be easier to develop and implement. =20
>    For example, a pruned topology may be considered for protection=20
>    path computation, where links/nodes that violate the strict=20
>    recovery time requirements are excluded."
>
=20
I agree with the analysis.  The first problem becomes similar to =
problems of
finding QoS routes, which are usually NP-hard. You can apply some =
heuristics
to find polynomial-time algorithms but the second method is cleaner.  We
prefer it as well.
=20
>    I see a problem in your example: since you consider=20
>    in each node a D queue max, you are taking account of=20
>    the worst-case. When the protection path travels more=20
>    than one node, you have the sum of these maximums.
>    Using a pruned topology for protection path calculation
>    you could be in a situation in which all the nodes/links=20
>    in the network are pruned.
>    Instead i thouhgt that an algorithm considers a cost in
>    each link/node (e.g. cost =3D D queue max + other delays...)
>    could be better.
>    This algorithm calculates the recovery paths and obtains=20
>    the best paths that minimize the total cost.=20
>    In this way we can ALWAYS obtain the best solution to
>    the requirements of the protection paths.=20
=20
I'm sorry about the confusion. My intention was exactly what you =
mentioned.
I will rephrase the paragraph in the next iteration. I definitely don't =
want
to include an algorithm in the draft and impose it on anybody, but will
indicate more information about possible solutions. I think at this =
point,
the draft is pretty general to accommodate any solution, barring the
misunderstanding that you mentioned.
=20
=20
>  -  in section 5.3.2 :
>
>  Table 1. Required and Optional Data for Fault Notifications=20
>   -------------------------------------------------------------------- =

>
>   Data Object    Fault   Fault Notify  Description=20
>                  Notify  Acknowledge=20
>   -------------------------------------------------------------------- =

>   Message ID        R         R        Identifies notification =
messages=20
>   Fault Link ID     R         -        Identifies the failed link=20
>   Fault ID          R         -        Identifies sequence of failure=20
>   Channel Status    O         -        Indication of link fault status =

>   Detecting Node ID O         -        Identifies the original node=20
>                                        that is reporting the failure=20
>   TTL               O         -        Time To Live field=20
>   -------------------------------------------------------------------- =

>   R: required, O: optional, -: not applicable=20
>
>    couldn' t be a misunderstanding in the description of
>    "Fault link ID"?=20
>    If it is used the "Channel Status " in the network too,=20
>    thinking to a starting scenario with no failures, there is
>    in the LMP extended messages  the association=20
>    "Identifier of the failed link" with "Channel Status" =3D OK =20
>    even if there has been no failure in the network.
>    If you agree with this, there could be a solution in making
>    - "Channel Status" Required and not optional=20
>       (in example KO =3D failure, OK =3D good link);
>    - "Fault Link ID" could become in example "Link ID".
=20
I'm not sure I understand you correctly. Let me explain a bit what we
currently have.
In the draft, the pair "Fault ID" + "Fault Link ID" uniquely identifies =
the
failure and therefore makes sure that you don't process duplicated =
"fault
Notify" messages.
We were using "Channel Status" to identify Loss of Light, Signal =
Degrade,
etc.
=20
If people adopt the LMP idea, we were also going to support "Channel =
Status"
OK for reversion, as an optional step.  Since this is a non =
time-sensitive
issue, signaling the ingress to revert to the old working path can also =
be
applied.
w/r to "fault link id" and "link id", I will check again the other =
drafts
and send you an answer on this particular point.
=20
> - in Appendix A.2 when written that
>   "The processing time D proc has been identified=20
>   in the literature [7] as a few tenths of a millisecond=20
>   in the case of an RSVP object.
>   This value is smaller in the case of a simpler LMP message=20
>   requesting the activation of an LSP path."=20
>
>   In the precedent period, did you consider the amount of processing
>   delay coming the introduction of flooding extensions in LMP?=20
>   I think that the implementation of this functionality in LMP=20
>   can add an important work in each node=20
>   (validation and checking of a message, timers, some of the=20
>   procedures we can find, in example, in OSPF ).
=20
>From our experience, we didn't have to add timers. The LMP security
implementation does add some overhead. But from our testbed experience, =
LMP
messages were processed pretty fast.  What this appendix points to is =
the
fact that one doesn't need to think that recovery of GMPLS networks =
cannot
be done within small time bounds.
=20
> Excuse me for misunderstandings.
=20
> Then i' m continuing to work on flooding fault=20
> notification using OSPF to be able to obtain
> performance results on this, so we can compare them;
=20
Great. We will be able to compare methods once you have running code.
=20
> you know i agree with you in the good potentialities=20
> of  flooding fault notification.
=20
Thanks.=20
=20
> Best regards.
> Roberto
>=20
> University of Rome - La Sapienza

=20

Richard.

=20

------=_NextPart_000_0001_01C34AAD.DF9D2000
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for reading the document and
extensive feedback. Please see my comments inline.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>&gt; -----Original Message-----<br>
&gt; <b><span style=3D'font-weight:bold'>From:</span></b> =
owner-</span></font><font
 size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>[email-masked]</span></=
font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[mailto:owner-</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>[email-masked]</span></font><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b></span></font><font =
size=3D2
 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Roberto =
Albanese</span></font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
&gt; <b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Monday, July
 14, 2003</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=3D2 face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>8:29 =
AM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
&gt; <b><span style=3D'font-weight:bold'>To:</span></b> =
</span></font><font
 size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Richard
 Rabbat</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>; </span></font><font size=3D2 face=3DTahoma><span
 =
style=3D'font-size:10.0pt;font-family:Tahoma'>[email-masked]</span></=
font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
&gt; <b><span style=3D'font-weight:bold'>Cc:</span></b> fabio; Listanti;
[email-masked]<br>
&gt; <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: =
Flooding using
LMP extensions</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>&gt;</span></font></p>

<pre><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; </span></font>Hi =
Richard, hi all,</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; </span></font>i read =
your drafts and i' d like to make you some questions:</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt;</span></font></pre><pr=
e><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; </span></font>-&nbsp; =
in section 5.3.1 is written that </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&quot;in order for the protection algorithm to =
abide by </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;the T-rec ms recovery requirement, it =
needs to be either:<font
face=3DTahoma><span style=3D'font-family:Tahoma'> =
</span></font></pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;&nbsp;1. Aware of timing issues to be =
able to select </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a proper path, =
or</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;&nbsp;2. Passed a set of nodes and links =
that satisfy </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the timing =
constraints.</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;Due to the complexity of the first =
method, we believe </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;that the second method will be easier to =
develop and implement.&nbsp; </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;For example, a pruned topology may be =
considered for protection </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;path computation, where links/nodes that =
violate the strict </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;recovery time requirements are =
excluded.&quot;</pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>I agree =
with the analysis.&nbsp; The first problem becomes similar to problems =
of finding QoS routes, which are usually NP-hard. You can apply some =
heuristics to find polynomial-time algorithms but the second method is =
cleaner.&nbsp; We prefer it as well.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;I see a problem in your example: since you consider =
</span></font></pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;in each node a D queue max, you are =
taking account of </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;the worst-case. When the protection path =
travels more </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;than one node, you have the sum of these =
maximums.</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;Using a pruned topology for protection =
path calculation</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;you could be in a situation in which all =
the nodes/links </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;in the network are =
pruned.</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;Instead i thouhgt that an algorithm =
considers a cost in</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;each link/node (e.g. cost =3D D queue =
max + other delays...)</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;could be better.</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;This algorithm calculates the recovery =
paths and obtains </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;the best paths that minimize the total =
cost. </pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;In this way we can ALWAYS obtain the =
best solution to</pre><pre><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>&gt; =
</span></font>&nbsp;&nbsp;&nbsp;the requirements of the protection =
paths. </pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>I&#8217;m =
sorry about the confusion. My intention was exactly what you mentioned. =
I will rephrase the paragraph in the next iteration. I definitely =
don&#8217;t want to include an algorithm in the draft and impose it on =
anybody, but will indicate more information about possible solutions. I =
think at this point, the draft is pretty general to accommodate any =
solution, barring the misunderstanding that you =
mentioned.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;-&nbsp; in section 5.3.2 :</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;Table 1. Required and Optional Data for Fault Notifications =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;-------------------------------------------------------------=
------- </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Data Object&nbsp;&nbsp;&nbsp; Fault&nbsp;&nbsp; Fault =
Notify&nbsp; Description </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Notify&nbsp; Acknowledge =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;-------------------------------------------------------------=
------- </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Message ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identifies notification =
messages </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Fault Link ID&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identifies the failed link =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Fault =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identifies sequence of =
failure </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Channel Status&nbsp;&nbsp;&nbsp; =
O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Indication of link fault =
status </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;Detecting Node ID =
O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identifies the original node =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;that is reporting the failure =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;TTL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; =
O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time To Live field =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;-------------------------------------------------------------=
------- </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;R: required, O: optional, -: not applicable =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;couldn' t be a misunderstanding in the description =
of</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&quot;Fault link ID&quot;? =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;If it is used the &quot;Channel Status &quot; in the =
network too, </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;thinking to a starting scenario with no failures, =
there is</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;in the LMP extended messages&nbsp; the association =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&quot;Identifier of the failed link&quot; with =
&quot;Channel Status&quot; =3D OK&nbsp; </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;even if there has been no failure in the =
network.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;If you agree with this, there could be a solution in =
making</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;- &quot;Channel Status&quot; Required and not optional =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(in example KO =3D failure, OK =3D =
good link);</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&nbsp;- &quot;Fault Link ID&quot; could become in example =
&quot;Link ID&quot;.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>I&#8217;m =
not sure I understand you correctly. Let me explain a bit what we =
currently have.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>In the =
draft, the pair &#8220;Fault ID&#8221; + &#8220;Fault Link ID&#8221; =
uniquely identifies the failure and therefore makes sure that you =
don&#8217;t process duplicated &#8220;fault Notify&#8221; =
messages.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>We were =
using &#8220;Channel Status&#8221; to identify Loss of Light, Signal =
Degrade, etc.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>If people =
adopt the LMP idea, we were also going to support &#8220;Channel =
Status&#8221; OK for reversion, as an optional step.&nbsp; Since this is =
a non time-sensitive issue, signaling the ingress to revert to the old =
working path can also be applied.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>w/r to =
&#8220;fault link id&#8221; and &#8220;link id&#8221;, I will check =
again the other drafts and send you an answer on this particular =
point.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; - in =
Appendix A.2 when written that</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;&quot;The processing time D proc has been identified =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;in the literature [7] as a few tenths of a millisecond =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;in the case of an RSVP object.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;This value is smaller in the case of a simpler LMP message =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;requesting the activation of an LSP path.&quot; =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp; In the precedent period, did you consider the amount of =
processing</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;delay coming the introduction of flooding extensions in LMP? =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt;&nbsp; &nbsp;I think that the =
implementation of this functionality in LMP =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;can add an important work in each node =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;(validation and checking of a message, timers, some of the =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
&nbsp;&nbsp;procedures we can find, in example, in OSPF =
).</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>From our =
experience, we didn&#8217;t have to add timers. The LMP security =
implementation does add some overhead. But from our testbed experience, =
LMP messages were processed pretty fast.&nbsp; What this appendix points =
to is the fact that one doesn&#8217;t need to think that recovery of =
GMPLS networks cannot be done within small time =
bounds.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
Excuse me for misunderstandings.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; Then =
i' m continuing to work on flooding fault </span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
notification using OSPF to be able to =
obtain</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
performance results on this, so we can compare =
them;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Great. We =
will be able to compare methods once you have running =
code.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; you =
know i agree with you in the good potentialities =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
of&nbsp; flooding fault notification.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Thanks. =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; Best =
regards.</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
Roberto</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
</span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>&gt; =
</span></font>University of Rome - La Sapienza</pre>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard.</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre></div>

</div>

</body>

</html>

------=_NextPart_000_0001_01C34AAD.DF9D2000--

Delivery-date: Tue, 15 Jul 2003 13:17:22 +0000
Date: Tue, 15 Jul 2003 06:15:39 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from ["JACQUENET Christian FTLD/IAP" <[email-masked]>]    (fwd)

Post from non-subscriber.

---------- Forwarded message ----------
From: "JACQUENET Christian FTLD/IAP" <[email-masked]>
To: "'Arthi Ayyangar'" <[email-masked]>
Cc: "'Jean-Philippe Vasseur \(Cisco\)'" <[email-masked]>,
    <[email-masked]>,
    <[email-masked]>
Subject: RE: Comments and questions to draft-ayyangar-inter-region-te-00.txt(long message)
Date: Thu, 10 Jul 2003 11:11:07 +0200

Hi Arthi,

Thanks for your clarifications - a couple of additional comments below.

[snip]

Hi Christian,

Thanks a lot for your detailed comments. I have tried to address
most of your questions/comments. Please find my replies inline.

> To me, BGP clusters and confederations could also be examples of an AS
which
> would be composed of multiple regions,
--------> Yes, BGP confederation could be yet another example of a region.
But if all the members of a confed run a single IGP, then it's not
clear why each member would form a region.

CJ: I'm not sure I understand your point. All I meant is that a sub-AS (as
part of a BGP confederation) could be viewed as a region by itself.

[snip]
Also, the notion of
> "transit LSPs transported across that region" should be defined, including
a
> comparison with FA-LSP and LSP segments...since both the latter may *also*
> be viewed as transit LSP paths, at least from an intra-region TE policy.
----------> The notion of 'transit' here depends on the originating and
terminating regions. While FA-LSPs and LSP segments start and terminate in
the same region (they are intra-region), LSPs that originate in some other
region and traverse this region are viewed to be 'transit LSPs'. As far as
the inter-region TE policy goes, therefore, the inter-region LSPs would be
treated as 'transit'. Ofcourse, other TE policies, local to the region,
could also be applicable to the intra-region LSPs that transport the
inter-region LSPs.
	I am not quite clear about your last sentence "since both the
latter may *also* be viewed as transit LSP paths, at least from an
intra-region TE policy". Could you elaborate ?

CJ: what I meant is that, since FA and segments are computed to convey
traffics that relate to inter-region LSP paths, both the FA and segment LSPS
can be viewed as transit LSPs within a given domain, whereas they may have
been (pre)-computed as part of the enforcement of an intra-domain TE policy.

[snip]

> The wording "...depending on the requirement of the operator of the
transit
> region" in the last paragraph should also deserve some elaboration, since
I
> suspect the need for (contractual) agreements between (participating)
> operators (i.e. operators who would participate in the dynamic enforcement
> of an inter-region TE policy), hence the need to exchange and possibly
> negotiate related QoS requirements and (TE) capabilities.
---------> Wouldn't this depend on the nature of the region itself ?
i.e. while the above may be true for an inter-AS LSP setup, especially
when the ASes belong to different SPs, it need not be applicable to an
inter-area LSP setup. Section 8.4 addresses this for inter-AS case.

CJ: I tend to agree with you, but I'm not sure your comment is strictly
relevant since the text refers to *the operator of the transit region*,
which, to me, implictly assumes an inter-AS context: otherwise, I don't see
why an operator of a given *area* should be different from the one who
manages another area...within a given domain.

Cheers,

Christian.

Delivery-date: Tue, 15 Jul 2003 13:15:16 +0000
Date: Tue, 15 Jul 2003 06:13:41 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Michael Lee <[email-masked]>]    (fwd)

Message from non-subscriber.

---------- Forwarded message ----------
To: IETF-Announce: ;
Cc: "RFC Editor" <[email-masked]>,
        "Internet Architecture Board" <[email-masked]>, [email-masked]
Subject: Document Action: 'Tracing Requirements for Generic
         Tunnels' to an Informational RFC
Date: Wed, 09 Jul 2003 16:58:18 -0400
From: Michael Lee <[email-masked]>

The IESG has no problem with the publication of the Internet-Draft 'Tracing
Requirements for Generic Tunnels' <draft-ietf-ccamp-tracereq-05.txt> as an
Informational RFC. This document is the product of the Common Control and
Measurement Plane Working Group.

The IESG contact person is Bert Wijnen.

Delivery-date: Tue, 15 Jul 2003 13:13:55 +0000
Date: Tue, 15 Jul 2003 06:12:22 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from ["Bhaskara P" <[email-masked]>]    (fwd)

Message from non-subscriber.

---------- Forwarded message ----------
Date: 9 Jul 2003 17:16:00 -0000
From: "Bhaskara P" <[email-masked]>
Reply-To: "Bhaskara P" <[email-masked]>
To: [email-masked], , [email-masked]
Cc: [email-masked], , [email-masked], , [email-masked]
Subject: unnumberted ERO and RRO

--Next_1057770960---0-203.199.83.246-27100
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=0A=0A
--Next_1057770960---0-203.199.83.246-27100
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Kireeti and Yokov,=0D=0A=0D=0AWhenever I read RFC 3477(Signalling Unnumb=
ered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)=
), it leaves me in more confusion than clarification.  If we have a simple =
topology of 3 node LSP like below,=0D=0A=0D=0A     Interfaces    1         =
2        3         4=0D=0A            Node A ----------- Node B -----------=
 Node C=0D=0A=0D=0ARFC 3477 suggests one can do ERO signalling from ingress=
 Node A in either of the following formats=0D=0A=0D=0A  format 1:   ERO wit=
h Router ID and out going interface Id of Node=0D=0A=0D=0A              <Ro=
uter Id of A>, <Interface 1>=0D=0A              <Router Id of B>, <Interfac=
e 3>=0D=0A=0D=0A  format 2:   ERO with Router ID and in coming interface of=
 the Node=0D=0A=0D=0A              <Router Id of B>, <interface 2>=0D=0A   =
           <Router Id of C>, <interface 4>=0D=0A=0D=0A1) If the above state=
ment is true, how should RRO for this LSP be encoded  i.e., in format 1 or =
format 2?. =0D=0A=0D=0A2) Which format  should the ingress node A, receive =
RRO object?   =0D=0A=0D=0A3) Is RRO always seen by ingress Node A, should b=
e always in the format of ERO singalled by ingress.  i.e., if ingress node =
singalls ERO in format 1, then it should recieve RRO in same format. or RRO=
 should follow always format 1 irrespective of ERO format.=0D=0A=0D=0AThese=
 formats are very important to inter-op between vendors. Can any please cla=
rify the above issues and how the RRO and ERO inerop between the vendors ac=
hieved?=0D=0A=0D=0Athank you=0D=0Abhaskara=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=
=0A=0D=0A                  =0A=0A
--Next_1057770960---0-203.199.83.246-27100--

Delivery-date: Tue, 15 Jul 2003 13:12:49 +0000
Date: Tue, 15 Jul 2003 06:10:57 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Michael Mandelberg <[email-masked]>]    (fwd)

Message from a non-subscriber.

---------- Forwarded message ----------
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: Please help me to resolve this ambiguity in the  RSVP_HOP object
	usage defined in rfc3473 (GMPLS extensions for RSVP-TE)
Date: Sun, 6 Jul 2003 23:35:07 -0400

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_01C34438.C3170930
Content-Type: text/plain;
	charset="windows-1252"

>From Section 8.1 I get:

      The choice of the data interface to use is always made by the
sender<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

   of the Path message. The choice of the data interface is indicated by

   the sender of the Path message by including the data channel's

   interface identifier in the message using a new RSVP_HOP object sub-

   type.  For bidirectional LSPs, the sender chooses the data interface

   in each direction.  In all cases but bundling, the upstream interface

   is implied by the downstream interface.  For bundling, the path

   sender explicitly identifies the component interface used in each

   direction.  The new RSVP_HOP object is used in Resv message to

   indicate the downstream node's usage of the indicated interface(s).

Suppose that LSR A sends a PATH message to LSR B, and later LSR B sends a
RESERVE message to LSR A. From all this I gather that:

1)  in the PATH message LSR A puts the 32-bit interface identifier(s) into
the RSVP_HOP object.

2) These identifiers are those configured on the LSR A. In other words, when
LSR B processes the PATH message, it will have to look up the mapping to
determine its local identifiers for these interfaces.

3) The last sentence in the quoted paragraph susggests that the RSVP_HOP
object in the RESERVE message should reference the interfaces using
identifiers configured on LSR B, so that when LSR A receives the RESERVE
message, it will have to look up the mapping to determine its local
identifiers for these interfaces.

Now, from Section 8.1.2:

   A node receiving one or more TLVs in a Path message saves their

   values and returns them in the HOP objects of subsequent Resv

   messages sent to the node that originated the TLVs.

This paragraph implies the opposite of point 3) above. It says that the
RSVP_HOP object in the RESERVE message sent by LSR B should contain the
*same* values as those it received.

There is a clear ambiguity, and a suggested contradiction here. What is the
intent, and what is the proper resolution?

Thanks

Michael Mandelberg

------_=_NextPart_001_01C34438.C3170930
Content-Type: text/html;
	charset="windows-1252"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">

<META content="MSHTML 6.00.2800.1170" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=921121403-07072003><FONT face=Arial color=#0000ff size=2>From
Section 8.1 I get:</FONT></SPAN></DIV>
<DIV><SPAN class=921121403-07072003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=921121403-07072003>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT face="Courier New"><FONT
size=2><SPAN class=921121403-07072003><FONT face=Arial
color=#0000ff>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;</FONT></SPAN>The choice of the
data interface to use is always made by the sender<?xml:namespace prefix = o ns
= "urn:schemas-microsoft-com:office:office"
/><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>of the
Path message. The choice of the data interface is indicated
by<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>the
sender of the Path message by including the data
channel's<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>interface
identifier in the message using a new RSVP_HOP object
sub-<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
</SPAN>type.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>For bidirectional
LSPs, the sender chooses the data interface<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>in each
direction.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>In all cases but
bundling, the upstream interface<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>is
implied by the downstream interface.<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>For bundling, the path<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>sender
explicitly identifies the component interface used in
each<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
</SPAN>direction.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The new RSVP_HOP
object is used in Resv message to<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>indicate
the downstream node's usage of the indicated
interface(s).<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New">&nbsp;</FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT size=2><FONT
face="Courier New"></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=921121403-07072003>Suppose that LSR A sends a
PATH message to LSR B, and later LSR B sends a RESERVE message to LSR A. From
all this I gather that:</SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=921121403-07072003>1) &nbsp;in the PATH message
LSR A puts the 32-bit interface identifier(s) into the RSVP_HOP
object.</SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=921121403-07072003>2) These identifiers are
those configured on the LSR A. In other words, when LSR B processes the PATH
message, it will have to look up the mapping to determine its local identifiers
for these interfaces.</SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=921121403-07072003>3) The last sentence in the
quoted paragraph susggests that the RSVP_HOP object in the RESERVE message
should reference the interfaces using identifiers configured on LSR B, so that
when LSR A receives the RESERVE message, it will have to look up the mapping to
determine its local identifiers for these
interfaces.</SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=921121403-07072003>Now, from Section
8.1.2:</SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff size=2><SPAN
class=921121403-07072003></SPAN></FONT></FONT></SPAN>&nbsp;</P><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT><FONT face=Arial
color=#0000ff><SPAN class=921121403-07072003>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT color=#000000><FONT
face="Courier New"><FONT size=2><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
</SPAN>A node receiving one or more TLVs in a Path message saves
their<o:p></o:p></FONT></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT color=#000000><FONT
face="Courier New"><FONT size=2><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
</SPAN>values and returns them in the HOP objects of subsequent
Resv<o:p></o:p></FONT></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
style="mso-fareast-font-family: 'MS Mincho'"><FONT color=#000000><FONT
face="Courier New"><FONT size=2><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
</SPAN>messages sent to the node that originated the
TLVs.<o:p></o:p></FONT></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><FONT size=2></FONT>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003><FONT size=2>This paragraph implies the opposite of
point 3) above. It says that the RSVP_HOP object in the&nbsp;RESERVE message
sent by&nbsp;LSR B should&nbsp;contain the *same* values as those it
received.</FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003><FONT size=2>There&nbsp;is a clear ambiguity, and a
suggested contradiction here. What is the intent, and what is the proper
resolution?</FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003><FONT size=2>Thanks</FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003></SPAN>&nbsp;</P>
<P class=MsoPlainText style="MARGIN: 0in 0in 0pt"><SPAN
class=921121403-07072003><FONT size=2>Michael
Mandelberg</FONT>&nbsp;</SPAN></SPAN></FONT></FONT></SPAN></P></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C34438.C3170930--

Delivery-date: Tue, 15 Jul 2003 13:02:10 +0000
Date: Tue, 15 Jul 2003 05:59:12 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from ["JACQUENET Christian FTLD/IAP" <[email-masked]>]    (fwd)

Post from a non-subscriber.

---------- Forwarded message ----------
>From [email-masked] Thu Jul 10 09:14:54 2003
From: "JACQUENET Christian FTLD/IAP" <[email-masked]>
To: "'Arthi Ayyangar'" <[email-masked]>
Cc: "'Jean-Philippe Vasseur \(Cisco\)'" <[email-masked]>,
    <[email-masked]>,
    <[email-masked]>
Subject: RE: Comments and questions to draft-ayyangar-inter-region-te-00.txt(long message)
Date: Thu, 10 Jul 2003 11:11:07 +0200

Hi Arthi,

Thanks for your clarifications - a couple of additional comments below.

[snip]

Hi Christian,

Thanks a lot for your detailed comments. I have tried to address
most of your questions/comments. Please find my replies inline.

> To me, BGP clusters and confederations could also be examples of an AS
which
> would be composed of multiple regions,
--------> Yes, BGP confederation could be yet another example of a region.
But if all the members of a confed run a single IGP, then it's not
clear why each member would form a region.

CJ: I'm not sure I understand your point. All I meant is that a sub-AS (as
part of a BGP confederation) could be viewed as a region by itself.

[snip]
Also, the notion of
> "transit LSPs transported across that region" should be defined, including
a
> comparison with FA-LSP and LSP segments...since both the latter may *also*
> be viewed as transit LSP paths, at least from an intra-region TE policy.
----------> The notion of 'transit' here depends on the originating and
terminating regions. While FA-LSPs and LSP segments start and terminate in
the same region (they are intra-region), LSPs that originate in some other
region and traverse this region are viewed to be 'transit LSPs'. As far as
the inter-region TE policy goes, therefore, the inter-region LSPs would be
treated as 'transit'. Ofcourse, other TE policies, local to the region,
could also be applicable to the intra-region LSPs that transport the
inter-region LSPs.
	I am not quite clear about your last sentence "since both the
latter may *also* be viewed as transit LSP paths, at least from an
intra-region TE policy". Could you elaborate ?

CJ: what I meant is that, since FA and segments are computed to convey
traffics that relate to inter-region LSP paths, both the FA and segment LSPS
can be viewed as transit LSPs within a given domain, whereas they may have
been (pre)-computed as part of the enforcement of an intra-domain TE policy.

[snip]

> The wording "...depending on the requirement of the operator of the
transit
> region" in the last paragraph should also deserve some elaboration, since
I
> suspect the need for (contractual) agreements between (participating)
> operators (i.e. operators who would participate in the dynamic enforcement
> of an inter-region TE policy), hence the need to exchange and possibly
> negotiate related QoS requirements and (TE) capabilities.
---------> Wouldn't this depend on the nature of the region itself ?
i.e. while the above may be true for an inter-AS LSP setup, especially
when the ASes belong to different SPs, it need not be applicable to an
inter-area LSP setup. Section 8.4 addresses this for inter-AS case.

CJ: I tend to agree with you, but I'm not sure your comment is strictly
relevant since the text refers to *the operator of the transit region*,
which, to me, implictly assumes an inter-AS context: otherwise, I don't see
why an operator of a given *area* should be different from the one who
manages another area...within a given domain.

Cheers,

Christian.

Delivery-date: Tue, 15 Jul 2003 06:21:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ashok Narayanan" <[email-masked]>, <[email-masked]>
Cc: "Ashok Narayanan" <[email-masked]>, "Jim Gibson" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Clarification on contents of Label Set object
Date: Tue, 15 Jul 2003 07:19:25 +0100

Re-send after smtp failure here in Vienna.
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Ashok Narayanan" <[email-masked]>;
<[email-masked]>
Cc: "Ashok Narayanan" <[email-masked]>; "Jim
Gibson" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 14, 2003 12:52 PM
Subject: Re: Clarification on contents of Label
Set object

> Your interpretation of 3471 is correct (IMNSHO).
> Your extrapolation to Acceptable Label Set is
> consistent with 3471 and with implementations in
> the field.
> Adrian
> ----- Original Message ----- 
> From: "Ashok Narayanan" <[email-masked]>
> To: <[email-masked]>
> Cc: "Ashok Narayanan" <[email-masked]>; "Jim
> Gibson" <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Tuesday, July 08, 2003 1:21 AM
> Subject: Clarification on contents of Label Set
> object
>
>
> >
> > Folks,
> >
> > We are seeking clarification with regards to
the
> label values to be
> > included in a Label-Set object and
> Accetable-Label-Set object.
> >
> > In general, it is possible for a data-link
using
> LSC or FSC switching
> > to have different label values on either side
of
> the link.  The two
> > sides must agree on which side does the
mapping:
> the object sender or
> > the object receiver.
> >
> > For the case of sending
> Label-Set/Acceptable-Label-Set, rfc3473 does
> > not state explicitly whether the labels in the
> object should be from
> > the the point of view of the object sender or
> object receiver of the
> > object.
> >
> > Our conclusion based on RFC3471, Section
3.2.1.1
> is that the labels
> > always reflect the object sender's point of
view
> and are mapped by the
> > object receiver.  For instance, in the case
that
> an upstream node is
> > including a Label-Set in a Path message, the
> labels included should be
> > from the space of labels used by the upstream
> node, and the downstream
> > node translate them before selecting one.
> Correspondingly, when a
> > PathError message carries an
> Acceptable-Label-Set, the receiver of the
> > PathError message (the upstream node) would
> first translate the
> > elements before selecting one.
> >
> > Are there any alternate views?
> >
> > Thanks
> > -Ashok
> >
> > --- Asok the
> Intern ----------------------------------------
> > Ashok Narayanan
> > IOS Network Protocols, Cisco Systems
> > 1414 Mass Ave, Boxborough MA 01719
> > Ph: 978-936-1608.  Fax: 978-936-2218 (Attn:
> Ashok Narayanan)
> >
> >
> >
>

Delivery-date: Mon, 14 Jul 2003 15:32:24 +0000
Date: Mon, 14 Jul 2003 17:29:04 +0200
From: Roberto Albanese <[email-masked]>
To: Richard Rabbat <[email-masked]>, [email-masked]
CC: fabio <[email-masked]>, Listanti <[email-masked]>, [email-masked]
Subject: Re: Flooding using LMP extensions

<!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>
 
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
         
<pre><font face="Courier New, Courier, monospace">Hi Richard, hi all,
i read your drafts and i' d like to make you some questions:

-  in section 5.3.1 is written that 
  "in order for the protection algorithm to abide by 
   the T-rec ms recovery requirement, it needs to be either:
    1. Aware of timing issues to be able to select 
       a proper path, or
    2. Passed a set of nodes and links that satisfy 
       the timing constraints.
 
   Due to the complexity of the first method, we believe 
   that the second method will be easier to develop and implement.  
   For example, a pruned topology may be considered for protection 
   path computation, where links/nodes that violate the strict 
   recovery time requirements are excluded."

</font><font face="Courier New, Courier, monospace">   I see a problem in your example: since you consider 
   in each node a D queue max, you are taking account of 
   the worst-case. When the protection path travels more 
   than one node, you have the sum of these maximums.
   Using a pruned topology for protection path calculation
   you could be in a situation in which all the nodes/links 
   in the network are pruned.
   Instead i thouhgt that an algorithm considers a cost in
   each link/node (e.g. cost = D queue max + other delays...)
   could be better.
   This algorithm calculates the recovery paths and obtains 
   the best paths that minimize the total cost. 
   In this way we can ALWAYS obtain the best solution to
   the requirements of the protection paths. 

&nbsp;-  in section 5.3.2 :

 Table 1. Required and Optional Data for Fault Notifications 
  -------------------------------------------------------------------- 
  Data Object    Fault   Fault Notify  Description 
                 Notify  Acknowledge 
  -------------------------------------------------------------------- 
  Message ID        R         R        Identifies notification messages 
  Fault Link ID     R         -        Identifies the failed link 
  Fault ID          R         -        Identifies sequence of failure 
  Channel Status    O         -        Indication of link fault status 
  Detecting Node ID O         -        Identifies the original node 
                                       that is reporting the failure 
  TTL               O         -        Time To Live field 
  -------------------------------------------------------------------- 
  R: required, O: optional, -: not applicable 

   couldn' t be a misunderstanding in the description of
   "Fault link ID"? 
   If it is used the "Channel Status " in the network too, 
   thinking to a starting scenario with no failures, there is
   in the LMP extended messages  the association 
   "Identifier of the failed link" with "Channel Status" = OK  
   even if there has been no failure in the network.
   If you agree with this, there could be a solution in making
   - "Channel Status" Required and not optional 
      (in example KO = failure, OK = good link);
   - "Fault Link ID" could become in example "Link ID".

- in Appendix A.2 when written that
  "The processing time D proc has been identified 
  in the literature [7] as a few tenths of a millisecond 
  in the case of an RSVP object.
  This value is smaller in the case of a simpler LMP message 
  requesting the activation of an LSP path."

 &nbsp;In the precedent period, did you consider the amount of processing
  delay coming the introduction of flooding extensions in LMP?
  I think that the implementation of this functionality in LMP 
  can add an important work in each node 
  (validation and checking of a message, timers, some of the 
  procedures  we can find, in example, in OSPF ).

Excuse me for misunderstandings.

Then i' m continuing to work on flooding fault 
notification using OSPF to be able to obtain
performance results on this, so we can compare them;
you know i agree with you in the good potentialities 
of  flooding fault notification.

Best regards.
Roberto

University of Rome - La Sapienza</font></pre>
       
</body>
</html>

Envelope-to: [email-masked]
Delivery-date: Thu, 10 Jul 2003 14:39:04 +0000
Message-Id: <[email-masked]>
From: "The IESG" <[email-masked]>
To: IETF-Announce: ;
Cc: "RFC Editor" <[email-masked]>, "Internet Architecture Board" <[email-masked]>, [email-masked]
Subject: Document Action: 'Tracing Requirements for Generic Tunnels' to an Informational RFC
Date: Thu, 10 Jul 2003 10:35:10 -0400

The IESG has no problem with the publication of the Internet-Draft 'Tracing
Requirements for Generic Tunnels' <draft-ietf-ccamp-tracereq-05.txt> as an
Informational RFC. This document is the product of the Common Control and
Measurement Plane Working Group.
                                                                                
The IESG contact person is Bert Wijnen.

Delivery-date: Thu, 10 Jul 2003 02:10:16 +0000
From: Michael Mandelberg <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Ambiguity in the  RSVP_HOP object usage defined in rfc3473 (GMPLS extensions for RSVP-TE)
Date: Wed, 9 Jul 2003 22:05:01 -0400 

>From Section 8.1 I get: 
The choice of the data interface to use is always made by the sender
of the Path message. The choice of the data interface is indicated by
the sender of the Path message by including the data channel's
interface identifier in the message using a new RSVP_HOP object sub-
type. For bidirectional LSPs, the sender chooses the data interface
in each direction. In all cases but bundling, the upstream interface
is implied by the downstream interface. For bundling, the path
sender explicitly identifies the component interface used in each
direction. The new RSVP_HOP object is used in Resv message to
indicate the downstream node's usage of the indicated interface(s).
Suppose that LSR A sends a PATH message to LSR B, and later LSR B sends a
RESERVE message to LSR A. From all this I gather that:
1) in the PATH message LSR A puts the 32-bit interface identifier(s) into
the RSVP_HOP object.
2) These identifiers are those configured on the LSR A. In other words, when
LSR B processes the PATH message, it will have to look up the mapping to
determine its local identifiers for these interfaces.
3) The last sentence in the quoted paragraph susggests that the RSVP_HOP
object in the RESERVE message should reference the interfaces using
identifiers configured on LSR B, so that when LSR A receives the RESERVE
message, it will have to look up the mapping to determine its local
identifiers for these interfaces.
Now, from Section 8.1.2:
A node receiving one or more TLVs in a Path message saves their
values and returns them in the HOP objects of subsequent Resv
messages sent to the node that originated the TLVs.
This paragraph implies the opposite of point 3) above. It says that the
RSVP_HOP object in the RESERVE message sent by LSR B should contain the
*same* values as those it received.
There is a clear ambiguity, and a suggested contradiction here. What is the
intent, and what is the proper resolution?
Thanks
Michael Mandelberg 

Lambda Optical Systems

Delivery-date: Tue, 08 Jul 2003 16:22:13 +0000
Date: Tue, 08 Jul 2003 18:19:53 +0200
From: [email-masked]
Reply-To: [email-masked]
Organization: ALCATEl - R&I
To: [email-masked]
Subject: Question on vertical interworking

Il s'agit d'un message multivolet au format MIME.
--------------D1A838B8E91598B16F1A0377
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hi all,

considering contributions from new authors as well as a clarification
between inter and multi region networks, a new version of the mrn draft
is available:
http://www.ietf.org/internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn-02.txt

The draft focuses on intra domain vertical interworking with the
following question
as a background:

How many control planes instances are needed to control
network elements supporting multiple switch caps ?

>From the reduction of multiple instances interactions' complexity to
a consistent multi-switch-cap routing model using forwarding
adjacencies, this memo highlights the issues of vertical interworking.

Feedbacks highly appreciated.

Regards,

Martin

--------------D1A838B8E91598B16F1A0377
Content-Transfer-Encoding: 7bit
Content-Type: text/x-vcard; charset=us-ascii;
 name="martin.vigoureux.vcf"
Content-Description: Carte pour Martin VIGOUREUX
Content-Disposition: attachment;
 filename="martin.vigoureux.vcf"

begin:vcard 
n:VIGOUREUX;Martin
tel;fax:+33 (0)1 69 63 18 65
tel;work:+33 (0)1 69 63 18 52
x-mozilla-html:FALSE
url:www.alcatel.fr
org:ALCATEL - R&I;SART
adr:;;Route de Nozay;Marcoussis Cedex;;91461;France
version:2.1
email;internet:[email-masked]
title:Research Engineer
fn:Martin VIGOUREUX
end:vcard

--------------D1A838B8E91598B16F1A0377--

Delivery-date: Tue, 08 Jul 2003 00:49:21 +0000
Date: Mon, 7 Jul 2003 17:47:51 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: JACQUENET Christian FTLD/IAP <[email-masked]>
cc: "'Jean-Philippe Vasseur (Cisco)'" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: Re: Comments and questions to draft-ayyangar-inter-region-te-00.txt (long message)

Hi Christian,

Thanks a lot for your detailed comments. I have tried to address
most of your questions/comments. Please find my replies inline.

> To me, BGP clusters and confederations could also be examples of an AS which
> would be composed of multiple regions,
--------> Yes, BGP confederation could be yet another example of a region.
But if all the members of a confed run a single IGP, then it's not
clear why each member would form a region.

> I assume that there may be several LSP segments that may be inserted into an
> inter-region LSP split, correct, although the last sentence of this
> paragraph seems to tell the contrary (and I don't see the restriction in
> such a case)?
--------> Do you mean per region or overall ? So, as the inter-region
TE LSP traverses different regions, more that one region along the
path could decide to stitch this TE LSP onto some intra-region LSP segment.
In any case, I will modify the text to clarify this.

> Section 1, page 3: the notion of *local* protection should
deserve some elaboration, unless the notion of "local" is applied to the
scale of a region, as defined previously. If so, I would replace the
current wording by "...requesting protection at the scale of a region (as
defined previously) within the context of [FAST-REROUTE]..."
--------> The notion of 'local protection' here is applicable within a
region as well as across regions as explained in Section 6.

> I would spend a line or two in this introductory section explaining the
> interaction between this document and the [INTER-AS] document: maybe the
> intent is to incorporate the contents of [INTER-AS] into this document?
-------> Not as of now; the solution proposed in [INTER-AS] is different
from the solution proposed here. Section 2 which is the introductory
section does explain the basic difference.

> The fact that ASes are mentioned in parenthesis when quoting "different
> regions" is somehow confusing, since it introduces a 1:1 relationship
> between the two notions, as opposed to the more generic definition stated in
> section 1. I would either delete the parenthesis or extend it to areas,
> sub-ASes, etc.
--------> I'll delete the parenthesis.

[clipped..]

> The notion of "complete control" on FA-LSP and LSP segment should deserve
> some elaboration as well, especially when the corresponding path computation
> MAY be triggered by an incoming inter-region LSP Setup request, which, by
> definition, is out of the control of a given ISP.
---------> The idea is that since the FA-LSP and LSP segment are
originated per region, local policies/configurations can control how
and when these get setup. I shall elaborate on the above in the next
revision.

Also, the notion of
> "transit LSPs transported across that region" should be defined, including a
> comparison with FA-LSP and LSP segments...since both the latter may *also*
> be viewed as transit LSP paths, at least from an intra-region TE policy.
----------> The notion of 'transit' here depends on the originating and
terminating regions. While FA-LSPs and LSP segments start and terminate in
the same region (they are intra-region), LSPs that originate in some other
region and traverse this region are viewed to be 'transit LSPs'. As far as
the inter-region TE policy goes, therefore, the inter-region LSPs would be
treated as 'transit'. Ofcourse, other TE policies, local to the region,
could also be applicable to the intra-region LSPs that transport the
inter-region LSPs.
	I am not quite clear about your last sentence "since both the
latter may *also* be viewed as transit LSP paths, at least from an
intra-region TE policy". Could you elaborate ?

> Section 3, page 4:
>
> According to the first paragraph, I assume inter-area TE is a usage example
> of the solution proposed in this document. I would tehrefore suggest a
> reference to Jim's recent contribution as far as inter-area TE requirements
> are concerned, and how (well) this document addresses such requirements.
--------> Will do so in the next revision.

> The penultimate sentence of the third paragraph seems to make auto-discovery
> mechanism (at least for the dynamic resolution of a next-hop boundary LSR)
> somewhat *mandatory* for the completion of an inter-region TE solution, and
> I think this should be clarified, especially when reading the previous
> sentence ("In the absence of...").
--------> Auto-discovery was not intended to be a mandatory mechanism. The
reason it was stressed here was so that the LSP paths (EROs) are specified
correctly.

> The wording "...depending on the requirement of the operator of the transit
> region" in the last paragraph should also deserve some elaboration, since I
> suspect the need for (contractual) agreements between (participating)
> operators (i.e. operators who would participate in the dynamic enforcement
> of an inter-region TE policy), hence the need to exchange and possibly
> negotiate related QoS requirements and (TE) capabilities.
---------> Wouldn't this depend on the nature of the region itself ?
i.e. while the above may be true for an inter-AS LSP setup, especially
when the ASes belong to different SPs, it need not be applicable to an
inter-area LSP setup. Section 8.4 addresses this for inter-AS case.

> Section 3, page 4:
>
> Dynamic bandwidth adjustment by HE LSR routers which computre FA LSP paths
> relies upon a specific knowledge which is the number of inter-region LSP
> paths that may be carried by the FA LSP: how such a knowledge can be
> acquired, since I assume this knowledge refers to predictable requests?
> Traffic matrices? Else? I would suggest that this document be more explicit
> on this engineering issue, which is one of the primary concerns of
> operators, from a resource planning and optimisation standpoint.
--------> This is an error in the text. I will correct it.
The dynamic bandwidth adjustment was to be based not on the number of
inter-region TE LSPs, but on the cumulative b/w requested by these
inter-region TE LSPs.

> What's a "resource affinity"? Does the notion of "color" refer to a specific
> DSCP marking (if so, I would use this wording)?
---------> The semantics are as defined in RFC 2702. I will add
the appropriate reference there.

> What's the use for an exit point to be able to determine the FA LSP or the
> LSP segment the received Path message relates to, since I understand this
> exit point is mostly used to propagate the inter-region LSP path Setup
> towards the next hop region?
------------> One of the reasons it is needed, is because depending on
whether the HE has done stitching or nesting, the egress LSR for the
FA-LSP/LSP segment needs to do correct label allocations (in the Resv
messages sent back upstream). This has been explained in section 5.

> Section 4.1, page 5:
>
> The second sentence introduces quite an important restriction I don't
> understand. I guess operators could engineer FA LSP paths (if not LSP
> segments) as specific transit LSP paths, without waiting for an incoming
> inter-region LSP path Setup message, i.e. intra-region MPLS TE could also be
> used to somehow *dedicate* specific LSPs for the "provisioning" of FA-LSP
> that would convey the traffic transported in inter-region LSP paths.
--------> Absolutely. That is exactly what the first sentence tries to
convey: "FA-LSPs or LSP segments can be pre-configured on any region
boundary LSR".
	The second sentence only says that in case of dynamic FA-LSP or
LSP segment setup (i.e. when they are *not* pre-provisioned), it is the
region boundary LSRs which are at the entry to the region which will
trigger the setup of the intra-region LSPs. So this is just stating who
is the default candidate for dynamic FA-LSP/LSP segment setup. This is
useful so that a region boundary LSR can determine if it needs to trigger
the setup of an intra-region LSP.

>Also,
> the notion of "source" should be more explicit: I assume you meant the
> originating region or HE LSR for the computation of a given inter-region LSP
> path, correct?
---------> Yes, the "source" here is the HE LSR for the inter-region LSP.
I will calrify this.

> Section 4.1, page 6:
>
> In the first paragraph, what if there is no auto-discovery mechanism
> (somewhat related to one of the previous comments above)?
---------> Then it is assumed that the nexthop in the ERO would specify
the region boundary LSR for that region, so that the previous hop can
expand the loose hop and compute a path to the region boundary LSR.
Section 3 explains this in detail.

> In the third paragraph, the notion of "FA-LSP/LSP segment candidate" should
> deserve some elaboration. What would be the rules for eligibility, and do
> you envision a dynamic "election" mechanism?
---------> By default, it would be the entry region boundary LSR. The
first paragraph in 4.1 defines exactly this.

> Section 4.2, page 7:
>
> In the example, I'm not sure I understand the decision criteria which would
> make router B establish a FA-LSP rather than a LSP segment (or vice versa).
---------> That is a decision local to the region (based on configuration
on the LSR) whether it wants to do nesting or stitching. If the goal is
say, scalability, then in order to transport several inter-region LSPs
over an intra-region LSP the operator may want to nest all the
inter-region LSPs on a FA-LSP. On the other hand, if the operator would
rather have one intra-region LSP per inter-region LSP, then he may choose
to do stitching with an LSP segment in that region.

> Section 4.2, page 8:
>
> The notion of "some specific inter-region LSPs" (end of first paragraph)
> should be defined.
> In the second paragraph, I still don't see the triggering mechanism that
> makes B select a FA or a LSP segment in area 0, sicne the problem is related
> to area 2 (hence the business of C, apart from sending the PathErr message
> to B).
---------> Please see explanation above.

> Also, I don't see the need of mentioning R0, R1 and R2 for this example.
---------> Okay. I'll remove them if they remain unused.

> Section 4.3, page 9:
>
> Does the notion of "a single hop link (between two ASBR routers" implicitly
> refer to the notion of eBGP multihop? If so, please be more specific.
> In the case of ASBR-ASBR links and the corresponding TE information, you
> mention the possibility of using a CSPF algorithm for path computation,
> which seems rather odd from an inter-domain path computation standpoint,
> especially because flooding path computation information between domains is
> not really recommended.
----------> It is not expected that path computation information be
flooded between different domains (regions). Here, we are only interested
in obtaining the TE-information associated with the local links originated
by the ASBR in the ASBR's TED. e.g. in the example discussed in 4.3, the
TE information associated with link BC would be added to B's TED.
Secondly, so that path computation in AS1 can take into account the TE
information for links BC, B'C', the ASBRs B and B' would need to advertise
the TE information for BC, B'C' in AS1's IGP.

> Also, I somehow disagree with the assmption that states that propagation of
> TE-related information between routers of a domain is implementation
> specific: my guess is that such routers should support Opaque LSAs (in the
> case of OSPF, together with the support of the TE extensions of OSPF as
> defined in Katz' draft) and the equivalent in IS-IS, and the document should
> at least provide a pointer to these references.
------------> I will add the references to these documents. Also, it was
*not* the mechanism used for propagation of TE information (TE extensions
for OSPF/ISIS) which was to be 'implementation specific'. It was the
mechanism used to determine the node (ASBR) and the links to the node
(ASBR-ASBR links) for which TE information is to be advertised, that was
supposed to be implementation specific.  I will rephrase the document to
clarify this.

> The advertisement of ASBR-ASBR-link-related TE information should be more
> precisely defined: do you mean the propagation of such information between
> ASBR routers and/or within a given domain, for redistribution purposes for
> example?
---------> See explanation above.

> Section 4.3, page 10:
>
> The first sentence of the paragraph may yield some scalability issue, as far
> as the volume of the TE information that will be flooded (presumably across
> domains) is concerned.
-----------> No TE information is expected to be flooded across domains,
as explained above.

[clipped..]

> Section 5, page 11:
>
> What are the "in-between" LSRs (under the 0x04 LSP stitching wording)? What
> would happen is such LSR changed the flag?
-----------> In case a region boundary LSR decides to do LSP stitching
then it would set the above flag for the intra-region LSP segment. The
flag is examined by the egress LSR for the intra-region LSP segment. All
other LSRs in that region are "in-between". This flag is not expected to
be changed because it is used for signaling an attribute for that
intra-region LSP session and indicates the behavior of the HE LSR.

[clipped..]
> Scetion 6.1, page 12:
>
> I don't understand why there is no traffic disruption during the repair
> period (end of the page), while C is computing a new path for the FA/LSP
> segment that are affected by the "old" path which has been torn down.
-----------> The paths for local protection are pre-computed and
pre-established as per [FAST-REROUTE]. So when failure occurs, you would
only need to switch to the backup path causing minimum traffic loss.
This is similar to MPLS Fast-reroute mechanisms which exist today.
Will rephrase.

> Section 6.2, page 13:
>
> What's the influence of having the knowledge of the TE information on the
> backup path algorithm?
-------> So that they can be computed instead of being configured
statically.

> The notion of "partial" CSPF computation should deserve some elaboration -
> does that refer to vendor-specific incremental SPF computations?
-------> No, it does not refer to any vendor-specific incremental SPF
computations. It means expanding the ERO upto the first reachable
boundary LSR in the region (which has either been specified as loose hop
in the ERO or has been determined via auto-discovery mechanism). I will
fix the text to elaborate this.

> Also, the notion of "main" LSP path has not been defined (before section
> 6.3).
-------> This is an error in text, I'll fix it.

> Section 7, page 15:
>
> Should the re-optimisation parameters be taken into account by the CSPF
> computation?
--------> Yes.

> Section 8: I would put the contents of this section in the appropriate
> requirements document ([INTER-AS]?).
----------> This section is meant to show that the solution proposed
in this draft satisfies requirements for Inter-AS TE as specified in
[INTER-AS-TE-REQTS] in case the region is an AS.

Thanks again for all the comments!

thanks,
-arthi

Delivery-date: Tue, 08 Jul 2003 00:25:12 +0000
Date: Mon, 07 Jul 2003 20:24:36 -0400
From: Ron Bonica <[email-masked]>
Subject: Proposed CCAMP Agenda for IETF 57
To: [email-masked]

9:00 - 9:10  Chairs	   Agenda bashing/Blue Sheets/Note takers
     - 9:25  Chairs  	   Doc status
     - 9:35  Alanqar	   ITU Liaisons
     - 9:45  Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
     - 9:55  Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
     -10:05  Papadimitriou Protection and Recovery update
     -10:15  Farrel	   draft-iwata-mpls-crankback-06.txt
     -10:25  Kim	         draft-kim-ccamp-cc-protection-03.txt
     -10:30  Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
     -10:35  Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
     -10:45  Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
     -10:55  Ali
draft-zamfir-explicit-resource-control-bundle-01.txt
     -11:05  Choi	         draft-choi-gmpls-resource-mapping-00.txt
     -11:15  Fu		   draft-fu-ccamp-traceroute-00.txt
     -11:30  Chairs	   Wrap up

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"If a man marches out of step with his
fellows it may be that he hears the sound
of a different drummer or, perhaps that
he has a poor sense of rhythm."
            -- Henry David Thoreau

Delivery-date: Tue, 08 Jul 2003 00:24:39 +0000
Date: Mon, 7 Jul 2003 20:21:12 -0400
From: Ashok Narayanan <[email-masked]>
To: [email-masked]
Cc: Ashok Narayanan <[email-masked]>, Jim Gibson <[email-masked]>, [email-masked], [email-masked]
Subject: Clarification on contents of Label Set object

Folks,

We are seeking clarification with regards to the label values to be
included in a Label-Set object and Accetable-Label-Set object.

In general, it is possible for a data-link using LSC or FSC switching
to have different label values on either side of the link.  The two
sides must agree on which side does the mapping: the object sender or
the object receiver.

For the case of sending Label-Set/Acceptable-Label-Set, rfc3473 does
not state explicitly whether the labels in the object should be from
the the point of view of the object sender or object receiver of the
object.

Our conclusion based on RFC3471, Section 3.2.1.1 is that the labels
always reflect the object sender's point of view and are mapped by the
object receiver.  For instance, in the case that an upstream node is
including a Label-Set in a Path message, the labels included should be
from the space of labels used by the upstream node, and the downstream
node translate them before selecting one. Correspondingly, when a
PathError message carries an Acceptable-Label-Set, the receiver of the
PathError message (the upstream node) would first translate the
elements before selecting one.

Are there any alternate views?

Thanks
-Ashok

--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: 978-936-2218 (Attn: Ashok Narayanan)

Delivery-date: Mon, 07 Jul 2003 00:52:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Subject: Re: New draft on Extra class LSP
Date: Mon, 7 Jul 2003 01:49:08 +0100

Vishal,

> I'm sorry, but I'm still not clear on the meaning of "extra traffic."
> Perhaps I need to go back and look again at it, and think about it
> a bit.

> As an alternative, perhaps some other folks on the list who are clear
> on these definitions could take a stab at helping those of us who are
still
> unclear understand them.

My attempt...

I think there is a subtle difference between ordinary pre-emption and extra
traffic.
That is, when resources are pre-empted in the ordinary way and then the
pre-empting LSP is torn down, the resources are freed up and completely
unused.
When resources for a secondary LSP are used for extra traffic and then the
extra traffic LSP is torn down, the resources revert to their "reserved for
the secondary LSP" state. This means that those resources are only available
for
- full pre-emption
- extra traffic use
They are not made available for general use.

> (And, I'd certainly like to find out from the list,
> if I'm the only one confused here, and, if so, see if people can point
> me in the right direction.)

I think this is a reasonable subject for confusion! It gets talked about as
a concept far more than it get deployed as a workable option.

Perhaps a couple of detailed paragraphs should be added to one of the
protection drafts.

Adrian

Delivery-date: Mon, 07 Jul 2003 00:51:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Subject: Re: New draft on Extra class LSP
Date: Mon, 7 Jul 2003 01:41:38 +0100

Vishal,

Sorry, I'm a bit out of sync with this thread...

> I agree that priority could be used to setup LSPs that use the
> resources reserved (but not cross-connected) for recovery.
>
> However, the end-effect one wants to achieve is to have these
> LSPs be pre-empted by no other than working LSPs that legitimately
> need to use those resources when a fault affecting those working
> LSPs occurs.

I disagree!
Suppose I have three services Gold, Silver and Bronze.
Bronze is unprotected, low priority.
Silver is protected, medium priority, allows extra traffic on protection
path.
Gold is high priority, 1+1 protected.

One would accept that Silver or Gold LSPs can pre-empt a Bronze LSP.
Why would you not allow a Gold LSP to pre--empt the protection path of a
Silver LSP?

Clearly you would not allow a Silver LSP to pre-empt another Silver LSP
(although you might - as a short-term measure - allow a Silver LSP working
path to pre-empt a Silver LSP protection path, it being better to have two
services set up unprotected than only one service: but this would be a
network policy matter)

> As I said in that note, perhaps it is indeed possible, by
> an appropriate choice of priority allocations and rules, to achieve
> this effect, but it appears to me that this is an area worth some
> thought, which the extra-class LSP draft seems to have initiated.

I agree that it is worthy of thought and debate and that the draft has been
a very useful stimulus. The disucssion of a BCP may be premature unless some
vendors and SPs have deployment experience of this issue.  I guess before
going too much further down the path of "extra-class" I'd like to be certain
that we really don't have adequate mechanisms to handle the issues.

Cheers,
Adrian

Delivery-date: Sun, 06 Jul 2003 22:27:03 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Sun, 6 Jul 2003 15:24:16 -0700

Hi Dimitri,

Thanks for the clarifications.

Some comments in-line.

-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, July 06, 2003 2:15 PM
> To: [email-masked]
> Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
>
>
> vishal,
>
> point A has been clarified on the list (and i think that
> the suggestion that was made/received on the list makes
> perfectly sense)

I'm assuming the suggestion you refer to above is yours and/or
Adrian's endorsement of your explanation.
Namely, use the reserved (but not cross-connected)
resources for setting up low-priority LSPs using available
mechanisms.

As I said, this is fine, with the caveat that one has to
then come up with an appropriate priority scheme that will
satisfy the requirement that such LSPs not be pre-empted
during the ordinary course of events (and only be pre-empted
when a working LSP needs to use the resources being used by
these LSPs).

I'm not saying it cannot be done, I'm just saying it needs
some thought and is not obvious (at least to me).

> point B (note: in your e-mail neither i) or ii) translates
> exactly the terms of the terminology draft, and none of your
> inferences are entirely correct, i have explain it to you
> already) in particular after the clarification on point A
> has been given, the term "1:1 re-routing without extra-traffic"
> (ref. also in the terminology i-d) should have been also
> understood that it meant that *this recovery lsp* (+) is not
> able to carry any traffic referred (per the terminology i-d)
> as "extra-traffic" (if this lsp would have been fully
> provisioned) what you call circular is just consistence.
>
> (+) from the early beginning you refer to other lsp's (ie
> the lower priority ones - see point A) than the one the sig
> i-d refers to for this recovery type
>

I'm sorry, but I'm still not clear on the meaning of "extra traffic."
Perhaps I need to go back and look again at it, and think about it
a bit.
I'll then come back with any follow-up questions, either on the list
or perhaps discuss off-line.

As an alternative, perhaps some other folks on the list who are clear
on these definitions could take a stab at helping those of us who are still
unclear understand them.
(And, I'd certainly like to find out from the list,
if I'm the only one confused here, and, if so, see if people can point
me in the right direction.)

>
> Vishal Sharma wrote:
> > Dimitri,
> >
> > (A) I see your point about reusing the priority mechanism to setup
> > low-priority pre-emptible LSPs over the resources reserved for
> > restoration. However, there is still the issue that such LSPs
> > ought not to be pre-empted by anything other than working LSPs
> > that need to use those recovery resources. They should not, for example,
> > be pre-empted by other higher priority LSPs (whether working or
> > protection LSPs).
> >
> > So, it appears there does need to be some thought given to how
> > this will be achieved, and how the resources reserved for
> > restoration will be advertised.
> >
> > Perhaps it is matter of sitting down and working through a priority
> > allocation scheme to these
> > different types of LSPs that will achieve such consistent behavior.
> > The point being that some thinking along those lines is needed,
> > which is what the extra-class LSP draft, I guess, tries to initiate.
> >
> > (B) Now a question about the definition of "extra traffic"
> >
> > Are _both_ of the following "extra traffic" per the
> > terminology draft?
> >
> > i) Traffic that uses resources reserved and cross-connected for
> > a protection path, and travels between the same source-destination pair
> > as the protection path.
> >
> > ii) Traffic that uses resources reserved (but not cross-connected)
> > for recovery. This traffic is sent by setting up low-priority
> > pre-emptible LSPs on those reserved resources.
> >
> > From your initial reply to Shiomoto-san (repeated below so people
> > can follow the context) and some of your subsequent
> > explanation it appears that this is the case (since you said that
> > this definition is designed to "cover any cases of extra-traffic
> > that we may encounter").
> >
> > "in the case of pre-planned re-routing without extra-traffic
> > the unallocated protecting resource can be used by other
> > (lower priority LSPs) at the condition that the resources
> > are preempted when the working LSP fails (hint: i wanted
> > to point out also that this should be obvious otherwise
> > there is no reason for having this "path protection only")"
> >
> > If so, the term "pre-planned re-routing without extra traffic"
> is circular,
> > since the type of traffic that can used those pre-planned (but
> > not cross-connected) resources is "extra traffic."
> >
> > If not, then it appears that "extra-traffic" only covers traffic
> > of type (i) above, and the definition should make that clear.
> > Or else, the term "pre-planned re-routing without extra traffic"
> > should be changed to be consistent with the terminology doc.
> >
> >
> > -Vishal
> >
> >
> >>-----Original Message-----
> >>From: [email-masked]
> >>[mailto:[email-masked]]
> >>Sent: Saturday, July 05, 2003 5:01 AM
> >>To: [email-masked]
> >>Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> >>Subject: Re: New draft on Extra class LSP
> >>
> >>
> >>vishal,
> >>
> >>[snip]
> >>
> >>
> >>>In the latter case, however, the only way any traffic could use the
> >>>reserved resources would be for one to setup a low-priority,
> >>
> >>pre-emptible
> >>
> >>>LSP using those resources, with the distinction that these particular
> >>>low-priority LSPs are not subject to pre-emption unless a working
> >>>LSP that needs to use those reserved resources fails (This what
> >>>Shiomoto-san more accurately calls "extra-LSP".)
> >>
> >>the point is to have a network wide homogeneous allocation
> >>of resources, starting to have allocation based on the
> >>reason why the lower priority lsp can be preempted leads you
> >>to the issue of how many of such conditions can we have
> >>in a network ? or do you plan to start defining one class
> >>of lsp and priority per such event ? the idea behind the
> >>"re-use" of these preemptible resources is to abstract its
> >>complexity not to spread it network wide - this while what
> >>we have today works perfectly -
> >>
> >>
> >>>So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-)
> >>
> >>and let's
> >>
> >>>clearly define "extra traffic" in the terminology doc., because I don't
> >>>think the definition, as it stands, in precise enough, unfortunately.
> >>
> >>the proposed definition (in the terminology i-d) is generic
> >>enough to cover any cases of extra-traffic that we may
> >>encounter, as said before in the "e2e" signaling i-d this
> >>definition is applied in this "e2e" context, there is here
> >>absolutely no reason (for the time being) to change the
> >>definition in the terminology document due to its usage
> >>in the signaling i-d - the only reason to change a def.
> >>in the terminology i-d would be that it doesn't cover the
> >>case of a concept developed in one of the subsequent i-d's
> >>not the other way around
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>
> >
> >
>
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
>

Delivery-date: Sun, 06 Jul 2003 22:25:20 +0000
Date: Mon, 07 Jul 2003 00:21:17 +0200
From: [email-masked]
To: [email-masked]
Cc: Adrian Farrel <[email-masked]>, Kohei Shiomoto <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

vishal,

i concur with the idea expressed here saying "this is
a network operator's choice (or the subject of a BCP)."

from the early beginning we have asked to the community
(ie the user community) if they would like to be guided
in such "policy decisions" and their response was "this
is our business" as such it means that two things either
you list *all the policies* or none of them, since it
is practically impossible to achieve the first one, we
opted(*) for the secund, therefore, here the only remaining
possibility is "guidelines through a bcp, using here the
initial user community input" (**) but before this happens
it would have been of great interest to have first this
input - any other views (also from the user community) ?

(*) the tewg bw discussions gives you a sample of what
such policy definition might generate

(**) i think that the analysis i-d gives a fair overview
of the complexity such policy would imply

thanks,
- dimitri.

Vishal Sharma wrote:
> Adrian,
> 
> Please see my reply to Dimitri.
> 
> I agree that priority could be used to setup LSPs that use the
> resources reserved (but not cross-connected) for recovery.
> 
> However, the end-effect one wants to achieve is to have these
> LSPs be pre-empted by no other than working LSPs that legitimately
> need to use those resources when a fault affecting those working
> LSPs occurs.
> 
> As I said in that note, perhaps it is indeed possible, by
> an appropriate choice of priority allocations and rules, to achieve
> this effect, but it appears to me that this is an area worth some
> thought, which the extra-class LSP draft seems to have initiated.
> 
> -Vishal
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Adrian Farrel
>>Sent: Saturday, July 05, 2003 10:46 AM
>>To: [email-masked]; [email-masked]
>>Cc: Kohei Shiomoto; [email-masked]
>>Subject: Re: New draft on Extra class LSP
>>
>>
>>I agree with Dimitri here.
>>
>>There is no reason to assume that (the resources for) a protection LSP
>>should not pre-empted by some other LSP. That is the nature of pre-emption
>>and it is a Good Thing (TM).
>>
>>Just as the working LSP might itself be pre-empted, so might the
>>protection
>>LSP.
>>
>>One might invent all sorts of schemes to help manage this (such as making
>>protection LSPs operate at a higher priority than working LSPs),
>>but this is
>>a network operator's choice (or the subject of a BCP). No new
>>protocol would
>>appear to be necessary to manage this.
>>
>>Adrian
>>
>>----- Original Message -----
>>From: <[email-masked]>
>>
>>>>In the latter case, however, the only way any traffic could use the
>>>>reserved resources would be for one to setup a low-priority,
>>>
>>pre-emptible
>>
>>>>LSP using those resources, with the distinction that these particular
>>>>low-priority LSPs are not subject to pre-emption unless a working
>>>>LSP that needs to use those reserved resources fails (This what
>>>>Shiomoto-san more accurately calls "extra-LSP".)
>>>
>>>the point is to have a network wide homogeneous allocation
>>>of resources, starting to have allocation based on the
>>>reason why the lower priority lsp can be preempted leads you
>>>to the issue of how many of such conditions can we have
>>>in a network ? or do you plan to start defining one class
>>>of lsp and priority per such event ? the idea behind the
>>>"re-use" of these preemptible resources is to abstract its
>>>complexity not to spread it network wide - this while what
>>>we have today works perfectly -
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sun, 06 Jul 2003 21:17:09 +0000
Date: Sun, 06 Jul 2003 23:14:43 +0200
From: [email-masked]
To: [email-masked]
Cc: Kohei Shiomoto <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

vishal,

point A has been clarified on the list (and i think that
the suggestion that was made/received on the list makes
perfectly sense)

point B (note: in your e-mail neither i) or ii) translates
exactly the terms of the terminology draft, and none of your
inferences are entirely correct, i have explain it to you
already) in particular after the clarification on point A
has been given, the term "1:1 re-routing without extra-traffic"
(ref. also in the terminology i-d) should have been also
understood that it meant that *this recovery lsp* (+) is not
able to carry any traffic referred (per the terminology i-d)
as "extra-traffic" (if this lsp would have been fully
provisioned) what you call circular is just consistence.

(+) from the early beginning you refer to other lsp's (ie
the lower priority ones - see point A) than the one the sig
i-d refers to for this recovery type

thanks,
- dimitri.

Vishal Sharma wrote:
> Dimitri,
> 
> (A) I see your point about reusing the priority mechanism to setup
> low-priority pre-emptible LSPs over the resources reserved for
> restoration. However, there is still the issue that such LSPs
> ought not to be pre-empted by anything other than working LSPs
> that need to use those recovery resources. They should not, for example,
> be pre-empted by other higher priority LSPs (whether working or
> protection LSPs).
> 
> So, it appears there does need to be some thought given to how
> this will be achieved, and how the resources reserved for
> restoration will be advertised. 
> 
> Perhaps it is matter of sitting down and working through a priority 
> allocation scheme to these
> different types of LSPs that will achieve such consistent behavior.
> The point being that some thinking along those lines is needed, 
> which is what the extra-class LSP draft, I guess, tries to initiate.
> 
> (B) Now a question about the definition of "extra traffic" 
> 
> Are _both_ of the following "extra traffic" per the 
> terminology draft?
> 
> i) Traffic that uses resources reserved and cross-connected for
> a protection path, and travels between the same source-destination pair
> as the protection path.
> 
> ii) Traffic that uses resources reserved (but not cross-connected)
> for recovery. This traffic is sent by setting up low-priority
> pre-emptible LSPs on those reserved resources.
> 
> From your initial reply to Shiomoto-san (repeated below so people
> can follow the context) and some of your subsequent
> explanation it appears that this is the case (since you said that
> this definition is designed to "cover any cases of extra-traffic
> that we may encounter").
> 
> "in the case of pre-planned re-routing without extra-traffic
> the unallocated protecting resource can be used by other
> (lower priority LSPs) at the condition that the resources
> are preempted when the working LSP fails (hint: i wanted
> to point out also that this should be obvious otherwise
> there is no reason for having this "path protection only")"
> 
> If so, the term "pre-planned re-routing without extra traffic" is circular,
> since the type of traffic that can used those pre-planned (but
> not cross-connected) resources is "extra traffic." 
> 
> If not, then it appears that "extra-traffic" only covers traffic
> of type (i) above, and the definition should make that clear.
> Or else, the term "pre-planned re-routing without extra traffic"
> should be changed to be consistent with the terminology doc.
> 
> 
> -Vishal
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Saturday, July 05, 2003 5:01 AM
>>To: [email-masked]
>>Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
>>Subject: Re: New draft on Extra class LSP
>>
>>
>>vishal,
>>
>>[snip]
>>
>>
>>>In the latter case, however, the only way any traffic could use the
>>>reserved resources would be for one to setup a low-priority, 
>>
>>pre-emptible
>>
>>>LSP using those resources, with the distinction that these particular
>>>low-priority LSPs are not subject to pre-emption unless a working
>>>LSP that needs to use those reserved resources fails (This what
>>>Shiomoto-san more accurately calls "extra-LSP".)
>>
>>the point is to have a network wide homogeneous allocation
>>of resources, starting to have allocation based on the
>>reason why the lower priority lsp can be preempted leads you
>>to the issue of how many of such conditions can we have
>>in a network ? or do you plan to start defining one class
>>of lsp and priority per such event ? the idea behind the
>>"re-use" of these preemptible resources is to abstract its
>>complexity not to spread it network wide - this while what
>>we have today works perfectly -
>>
>>
>>>So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-) 
>>
>>and let's
>>
>>>clearly define "extra traffic" in the terminology doc., because I don't
>>>think the definition, as it stands, in precise enough, unfortunately.
>>
>>the proposed definition (in the terminology i-d) is generic
>>enough to cover any cases of extra-traffic that we may
>>encounter, as said before in the "e2e" signaling i-d this
>>definition is applied in this "e2e" context, there is here
>>absolutely no reason (for the time being) to change the
>>definition in the terminology document due to its usage
>>in the signaling i-d - the only reason to change a def.
>>in the terminology i-d would be that it doesn't cover the
>>case of a concept developed in one of the subsequent i-d's
>>not the other way around
>>
>>thanks,
>>- dimitri.
>>
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sun, 06 Jul 2003 19:57:22 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Sun, 6 Jul 2003 12:54:26 -0700

Adrian,

Please see my reply to Dimitri.

I agree that priority could be used to setup LSPs that use the
resources reserved (but not cross-connected) for recovery.

However, the end-effect one wants to achieve is to have these
LSPs be pre-empted by no other than working LSPs that legitimately
need to use those resources when a fault affecting those working
LSPs occurs.

As I said in that note, perhaps it is indeed possible, by
an appropriate choice of priority allocations and rules, to achieve
this effect, but it appears to me that this is an area worth some
thought, which the extra-class LSP draft seems to have initiated.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Saturday, July 05, 2003 10:46 AM
> To: [email-masked]; [email-masked]
> Cc: Kohei Shiomoto; [email-masked]
> Subject: Re: New draft on Extra class LSP
>
>
> I agree with Dimitri here.
>
> There is no reason to assume that (the resources for) a protection LSP
> should not pre-empted by some other LSP. That is the nature of pre-emption
> and it is a Good Thing (TM).
>
> Just as the working LSP might itself be pre-empted, so might the
> protection
> LSP.
>
> One might invent all sorts of schemes to help manage this (such as making
> protection LSPs operate at a higher priority than working LSPs),
> but this is
> a network operator's choice (or the subject of a BCP). No new
> protocol would
> appear to be necessary to manage this.
>
> Adrian
>
> ----- Original Message -----
> From: <[email-masked]>
>
> > > In the latter case, however, the only way any traffic could use the
> > > reserved resources would be for one to setup a low-priority,
> pre-emptible
> > > LSP using those resources, with the distinction that these particular
> > > low-priority LSPs are not subject to pre-emption unless a working
> > > LSP that needs to use those reserved resources fails (This what
> > > Shiomoto-san more accurately calls "extra-LSP".)
> >
> > the point is to have a network wide homogeneous allocation
> > of resources, starting to have allocation based on the
> > reason why the lower priority lsp can be preempted leads you
> > to the issue of how many of such conditions can we have
> > in a network ? or do you plan to start defining one class
> > of lsp and priority per such event ? the idea behind the
> > "re-use" of these preemptible resources is to abstract its
> > complexity not to spread it network wide - this while what
> > we have today works perfectly -
>
>

Delivery-date: Sun, 06 Jul 2003 19:45:19 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Sun, 6 Jul 2003 12:41:33 -0700

Dimitri,

(A) I see your point about reusing the priority mechanism to setup
low-priority pre-emptible LSPs over the resources reserved for
restoration. However, there is still the issue that such LSPs
ought not to be pre-empted by anything other than working LSPs
that need to use those recovery resources. They should not, for example,
be pre-empted by other higher priority LSPs (whether working or
protection LSPs).

So, it appears there does need to be some thought given to how
this will be achieved, and how the resources reserved for
restoration will be advertised. 

Perhaps it is matter of sitting down and working through a priority 
allocation scheme to these
different types of LSPs that will achieve such consistent behavior.
The point being that some thinking along those lines is needed, 
which is what the extra-class LSP draft, I guess, tries to initiate.

(B) Now a question about the definition of "extra traffic" 

Are _both_ of the following "extra traffic" per the 
terminology draft?

i) Traffic that uses resources reserved and cross-connected for
a protection path, and travels between the same source-destination pair
as the protection path.

ii) Traffic that uses resources reserved (but not cross-connected)
for recovery. This traffic is sent by setting up low-priority
pre-emptible LSPs on those reserved resources.

>From your initial reply to Shiomoto-san (repeated below so people
can follow the context) and some of your subsequent
explanation it appears that this is the case (since you said that
this definition is designed to "cover any cases of extra-traffic
that we may encounter").

"in the case of pre-planned re-routing without extra-traffic
the unallocated protecting resource can be used by other
(lower priority LSPs) at the condition that the resources
are preempted when the working LSP fails (hint: i wanted
to point out also that this should be obvious otherwise
there is no reason for having this "path protection only")"

If so, the term "pre-planned re-routing without extra traffic" is circular,
since the type of traffic that can used those pre-planned (but
not cross-connected) resources is "extra traffic." 

If not, then it appears that "extra-traffic" only covers traffic
of type (i) above, and the definition should make that clear.
Or else, the term "pre-planned re-routing without extra traffic"
should be changed to be consistent with the terminology doc.

-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Saturday, July 05, 2003 5:01 AM
> To: [email-masked]
> Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
> 
> 
> vishal,
> 
> [snip]
> 
> > In the latter case, however, the only way any traffic could use the
> > reserved resources would be for one to setup a low-priority, 
> pre-emptible
> > LSP using those resources, with the distinction that these particular
> > low-priority LSPs are not subject to pre-emption unless a working
> > LSP that needs to use those reserved resources fails (This what
> > Shiomoto-san more accurately calls "extra-LSP".)
> 
> the point is to have a network wide homogeneous allocation
> of resources, starting to have allocation based on the
> reason why the lower priority lsp can be preempted leads you
> to the issue of how many of such conditions can we have
> in a network ? or do you plan to start defining one class
> of lsp and priority per such event ? the idea behind the
> "re-use" of these preemptible resources is to abstract its
> complexity not to spread it network wide - this while what
> we have today works perfectly -
> 
> > So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-) 
> and let's
> > clearly define "extra traffic" in the terminology doc., because I don't
> > think the definition, as it stands, in precise enough, unfortunately.
> 
> the proposed definition (in the terminology i-d) is generic
> enough to cover any cases of extra-traffic that we may
> encounter, as said before in the "e2e" signaling i-d this
> definition is applied in this "e2e" context, there is here
> absolutely no reason (for the time being) to change the
> definition in the terminology document due to its usage
> in the signaling i-d - the only reason to change a def.
> in the terminology i-d would be that it doesn't cover the
> case of a concept developed in one of the subsequent i-d's
> not the other way around
> 
> thanks,
> - dimitri.
> 
> 
> 

Delivery-date: Sun, 06 Jul 2003 06:04:36 +0000
From: "Jonathan" <[email-masked]>
To: "'Yoshihiko SUEMURA'" <[email-masked]>, <[email-masked]>, "'Kohei Shiomoto'" <[email-masked]>
Cc: <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Sat, 5 Jul 2003 23:01:14 -0700

Yoshihiko,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yoshihiko SUEMURA
> Sent: Saturday, July 05, 2003 1:50 AM
> To: [email-masked]; Kohei Shiomoto
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
> 
> 
> Dimitri,
> 
> Are you saying the following?
> 
> - In Shared Mesh Restoration, bandwidth reserved for recovery LSPs can
>   be advertised by using the "Max LSP Bandwidth at priority 
> X" field in
>   the Interface Switching Capability sub-TLV.
>   
> - You can setup a low priority LSP (or an Extra-LSP) by 
> setting priority
>   X at the Setup Priority field of the Session Attribute 
> object in the RSVP
>   message.
This is exactly right.  We should probably add these two bullet points
to the P&R drafts for clarification.

Thanks,
Jonathan

> 
> This makes sense to me. But, I am still wondering if it is 
> the way the priority mechanism should be used.
> 
> Regards,
> 
> Yoshihiko
> 
> On Fri, 04 Jul 2003 14:04:04 +0200, 
> [email-masked] wrote:
> 
> > hi kohei,
> > 
> > in between "1:1 lsp protection with extra-traffic lsp" (covered in 
> > section 6 of the termino and section 7 of the signaling 
> i-d) and "1:1 
> > lsp re-routing without extra-traffic lsp" (defined in 
> section 7 of the 
> > termino and section 8 of the signaling i-d) where it is 
> assumed that 
> > these resources can be re-used by lower priority lsp which is of 
> > course *not* the recovery lsp associated to the working 
> lsp, i do not 
> > see where additional markup is needed from a signaling perspective 
> > (since these extra-traffic lsp have their specific bit 
> setting in the 
> > protection object), while the lower priority lsp 
> established using the 
> > preemptible recovery resources are also signaled using 
> existing rfc's 
> > and wg i-d's (but this is not within in the scope of the 
> signaling i-d 
> > i am referring to), and for what relates to the signaling 
> i-d i think 
> > that the distinction has been clearly made for the 
> extra-traffic lsps 
> > (that can or not carry carry traffic).
> > 
> > now of course you can always tell me here the following: once the 
> > recovery lsp is (control-plane) established in a 
> shared-mesh recovery 
> > scheme, it gives raise to a "new class" of resources from which the 
> > resources have been pre-selected but the assumption made 
> here (see the 
> > analysis i-d) is that this pool is already within the priority list 
> > already made available in gmpls-routing i-d's isc sub-tlv - this is 
> > the baseline from which we started in atlanta (note: this 
> may evolve 
> > but i don't have for the time being any strong rationale to 
> make this 
> > evolving except that it would complexify the control of an already 
> > complex recovery scheme - i mean here shared mesh recovery).
> > 
> > what i would thus suggest, since by the time even the relatively 
> > simple recovery schemes have already shown to be more complex (than
> > expected) once control plane driven, it is to clearly 
> provide us, the 
> > (potential) rationales to perform this separation and 
> achieve further 
> > expected optimization or see it from the other way around - because 
> > this is probably the main issue - what are the protocol 
> aspects that 
> > are not affected by the current baseline, that would be in 
> case such 
> > kind of mechanism is introduced ? in any case you would fall into a 
> > scope that we don't cover here since the proposed approach does not 
> > assume any additional gmpls routing extensions (see also 
> conclusion of 
> > the analysis i-d, thus here i do not think appropriate to 
> make a come 
> > back now on a consensus made last year) but if people can 
> demonstrate 
> > that new paradigms and further optimization based on gmpls-routing 
> > extensions would better meet their future expected needs 
> and thus fall 
> > into a new charter item, really fine with me (i would be 
> glad to help 
> > in this effort, in
> > case)
> > 
> > thanks,
> > - dimitri.
> > 
> > Kohei Shiomoto wrote:
> > > Hi, Dimitri,
> > > 
> > > In the extra LSP draft, we want to make clear distinction between 
> > > lower priority LSP and extra LSP.
> > > 
> > > Priority mechanism is used to differentiate the service 
> quality for 
> > > working resource. The resource for working LSPs is contended by 
> > > working LSPs of different priority classes. Service quality is 
> > > dependent on traffic ratio of different priority classes; service 
> > > quality of lower priority LSP degrades if higher priority LSP 
> > > request comes frequently. Resource for protecting LSP in 
> shared mesh 
> > > restoration is preempted only when the working LSP fails. Service 
> > > quality does not depend on traffic ratio of different priority 
> > > class. We could define another service class which does 
> not depend 
> > > on the traffic ratio of different priority class by using 
> resources 
> > > for protecting LSP in shared mesh restoration. Priority 
> mechanism is 
> > > used for service differentiation based on relative traffic volume 
> > > difference while extra LSP is preempted only when the working LSP 
> > > fails. So we should make distinction between lower 
> priority LSP and 
> > > extra LSP.
> > > 
> > > Thanks.
> > > --
> > > Kohei
> > > 
> > > 
> > >>hi vishal,
> > >>
> > >>see in-line...
> > >>
> > >>Vishal Sharma wrote:
> > >>
> > >>
> > >>>Hi Dimitri,
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: [email-masked] 
> [mailto:[email-masked]]On
> > >>>>Behalf Of [email-masked]
> > >>>>Sent: Thursday, July 03, 2003 2:45 AM
> > >>>>To: Kohei Shiomoto
> > >>>>Cc: Adrian Farrel; [email-masked]
> > >>>>Subject: Re: New draft on Extra class LSP
> > >>>>
> > >>>>
> > >>>>hi adrian, kohei,
> > >>>>
> > >>>>in the case of pre-planned re-routing without extra-traffic the 
> > >>>>unallocated protecting resource can be used by other (lower 
> > >>>>priority LSPs) at the condition that the resources are 
> preempted 
> > >>>>when the working LSP fails (hint: i wanted to point out 
> also that 
> > >>>>this should be obvious otherwise there is no reason for having 
> > >>>>this "path protection only")
> > >>>
> > >>>
> > >>>
> > >>>Actually, I think the terminology choice "without 
> extra-traffic" is 
> > >>>a bit confusing. It wasn't clear how the document distinguishes 
> > >>>between "extra traffic" and "low priority traffic that can be 
> > >>>pre-empted"?
> > >>
> > >>
> > >>it distinguishes between protection and (pre-planned) re- 
> routing, 
> > >>for the former it thus refers to protection with 
> extra-traffic & the 
> > >>latter re-routing without extra-traffic (see also section 
> 7.1 of the 
> > >>terminology doc.) since the end-to-end association 
> delivering path 
> > >>protection does not allow to carry any extra-traffic, now 
> the fact 
> > >>that these resources can be used for lower priority 
> traffic boils us
> > >>down to the setup of low priority lsp (that may be thus
> > >>preempted) but this is not anymore a specific "p&r" issue
> > >>except the fact the trigger for this preemption is internal
> > >>to the network and not an external provisioning or config
> > >>event (but anyway an additional sentence here would more
> > >>than certainly not hurt)
> > >>
> > >>
> > >>>>and the below i-d points out specific aspects (that are covered 
> > >>>>"partially" by other gmpls i-d's) see below:
> > >>>>- advertize the bandwidth: -> gmpls-routing (and bw acct)
> > >>>>- extra class LSP indication in signaling message -> 
> priority in 
> > >>>>(g)mpls signaling
> > >>>>- extra class LSP preemption signaling -> PathErr with 
> SR Flag and 
> > >>>>PathTear (to release the lower priority LSP) but this can be 
> > >>>>qualified here as an "hard preemption" mechanism
> > >>>>- preventing unintended connections -> it is a transient
> > >>>>behaviour that may occur at an intermediate node e.g.
> > >>>>if the previous point is not used, and cross-connection
> > >>>>is fully performed in the downstream direction
> > >>>>
> > >>>
> > >>>
> > >>>I endorse the need to focus seriously on the last point, 
> since, if 
> > >>>during dropping "extra traffic" or "low priority pre-emptable 
> > >>>traffic", the intermediate nodes end up misconnecting 
> traffic (even 
> > >>>for a short while), it would be a real violation of SLAs.
> > >>
> > >>
> > >>well the issue i wanted to point out is that these lower priority 
> > >>lsp's can be established outside of the scope of the p&r 
> context it 
> > >>refers to larger scope issue (*) - note that this 
> misconnection (as 
> > >>currently specified) does not occur for lsp protection with 
> > >>extra-traffic (see section 7) or if you want the only reason for 
> > >>preemption is protection switching that occurs only on and end-to 
> > >>end basis
> > >>
> > >>(*) i refer here to the mpls mailing list discussion
> > >>
> > >>thanks,
> > >>- dimitri.
> > >>
> > >>
> > >>>I would suspect it
> > >>>would make customer's with mission critical traffic (and their 
> > >>>service providers, implementing such a scheme) very 
> uncomfortable 
> > >>>to know that this is even a remote possibility! :-)
> > >>>
> > >>>-Vishal
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Kohei Shiomoto wrote:
> > >>>>
> > >>>>
> > >>>>>Hi, Adrian
> > >>>>>
> > >>>>>In Section 9 of 
> > >>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
> > >>>>>the shared mesh restoration is addressed. Extra 
> traffic cannot be
> > >>>>>carried because the protecting LSPs are not 
> instantiated in shared
> > >>>>>mesh
> > >>>>>restoration networks. But the resource for the 
> protecting LSPs are
> > >>>>>reserved to back up the failure of primary LSPs. The 
> reserved resource
> > >>>>>could be allocated for extra traffic to enhance the network
> > >>>>>utilization.
> > >>>>>
> > >>>>>The purpose of our draft is to initiate the discussion 
> on how to 
> > >>>>>handle extra class LSP using the reserved link resource for the
> > >>>>
> > >>>>
> > >>>>protecting LSPs
> > >>>>
> > >>>>
> > >>>>>while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
> > >>>>
> > >>>>
> > >>>>addresses
> > >>>>
> > >>>>
> > >>>>>the signaling of primary and protecting LSPs.
> > >>>>>
> > >>>>>Regarding extra class LSP, the following issues need to be 
> > >>>>>addressed:
> > >>>>>(1) advertisement of available resource for extra 
> class LSP, (2) extra
> > >>>>>class LSP indication in signaling message (3) extra class LSP
> > >>>>
> > >>>>
> > >>>>preemption
> > >>>>
> > >>>>
> > >>>>>signaling, and (4) preventing unintended connections. Our draft
> > >>>>
> > >>>>
> > >>>>provides
> > >>>>
> > >>>>
> > >>>>>the problem statement of these issues.
> > >>>>>
> > >>>>>Hope this clarify the difference.
> > >>>>>Thank you for your interest.
> > >>>>>---
> > >>>>>Kohei
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Shiomoto_san,
> > >>>>>>
> > >>>>>>Could you help us prepare for Vienna by summarizing the 
> > >>>>>>difference between your draft and
> > >>>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt 
> especially with
> > >>>>>>reference to the carrying of "extra traffic" on the 
> resources of a
> > >>>>>>protection path in a mesh network.
> > >>>>>>
> > >>>>>>Thanks,
> > >>>>>>Adrian
> > >>>>>>
> > >>>>>>----- Original Message -----
> > >>>>>>From: "Kohei Shiomoto" <[email-masked]>
> > >>>>>>To: <[email-masked]>
> > >>>>>>Sent: Tuesday, July 01, 2003 3:18 AM
> > >>>>>>Subject: New draft on Extra class LSP
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>Sorry for the incorrect subject in the previous mail. I
> > >>>>>>
> > >>>>>>
> > >>>>resend it with a
> > >>>>
> > >>>>
> > >>>>>>>new subject.
> > >>>>>>>
> > >>>>>>>Hi, all
> > >>>>>>>
> > >>>>>>>Please notice that a new internet-draft has been posted. The 
> > >>>>>>>draft is targeted at the IETF57 ccamp meeting. The draft is 
> > >>>>>>>prepared
> > >>>>>>
> > >>>>>>
> > >>>>to initiate
> > >>>>
> > >>>>
> > >>>>>>>the discussion at the ccamp-wg on the extra class 
> LSP service, 
> > >>>>>>>which makes use of reserved but unallocated bandwidth for the
> > >>>>>>
> > >>>>>>
> > >>>>protecting LSPs
> > >>>>
> > >>>>
> > >>>>>>>in the pre-planned LSP re-routing recovery method (including
> > >>>>>>
> > >>>>>>
> > >>>>shared mesh
> > >>>>
> > >>>>
> > >>>>>>>restoration). Comments and feedbacks are highly appreciated. 
> > >>>>>>>Thanks.
> > >>>>>>>--
> > >>>>>>>Kohei Shiomoto
> > >>>>>>>NTT Network Innovation Laboratories
> > >>>>>>>Phone +81 422 59 4402, Fax +81 422 59 6387
> > >>>>>>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> > >>>>>>>
> > >>>>>>
> > 
> >>>>------------------------------------------------------------------
> > >>>>--------
> > >>>>
> > >>>>
> > >>>>>>----------------------
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>Title : Extra class LSP service using protecting
> > >>>>>>
> > >>>>>>
> > >>>>resources in
> > >>>>
> > >>>>
> > >>>>>>>GMPLS networks
> > >>>>>>>Author(s) : K. Shimano et al.
> > >>>>>>>Filename : draft-pil-ccamp-extra-lsp-00.txt
> > >>>>>>>
> > >>>>>>>This document provides the problem statement on a 
> extra class 
> > >>>>>>>LSP
> > >>>>>>>ser-
> > >>>>>>>vice and addresses the issues. The extra class LSP 
> uses the resource
> > >>>>>>>reserved but not allocated for the protecting LSPs in the
> > >>>>>>>pre-planned
> > >>>>>>>LSP re-routing without extra-traffic (including shared mesh)
> > >>>>>>>recovery
> > >>>>>>>method. Network utilization is improved because the resource
> > >>>>>>>reserved
> > >>>>>>>for the protecting LSPs are used for the extra class 
> LSPs. The extra
> > >>>>>>>class LSP is preempted less frequently than the conventional
> > >>>>>>>priority
> > >>>>>>>mechanism using setup and holding priorities because 
> the resource
> > >>>>>>>reserved for the protecting LSPs is allocated only 
> if the working
> > >>>>>>>LSP
> > >>>>>>>fails, which is usually expected to rarely occur. 
> This document pro-
> > >>>>>>>poses the extra class LSP service using the resource 
> reserved but
> > >>>>>>>not
> > >>>>>>>allocated for the protecting LSP at the provisioning phase.
> > >>>>>>
> > >>>>>>
> > >>>>This docu-
> > >>>>
> > >>>>
> > >>>>>>>ment addresses the issues on the extra class LSP: (1) 
> > >>>>>>>advertisement of available resource, (2) extra class LSP 
> > >>>>>>>indication in
> > >>>>>>
> > >>>>>>
> > >>>>signaling message
> > >>>>
> > >>>>
> > >>>>>>>(3) extra class LSP preemption signaling, and (4) preventing
> > >>>>>>
> > >>>>>>
> > >>>>unintended
> > >>>>
> > >>>>
> > >>>>>>>connections.
> > >>>>>>>
> > >>>>>>>A URL for this Internet-Draft is: 
> > 
> >>>>>>>http://www.ietf.org/internet->
drafts/draft-pil-ccamp-extra-lsp-0
> > >>>>>>>0.txt
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>--
> > >>>>Papadimitriou Dimitri
> > >>>>E-mail : [email-masked]
> > >>>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >>>>E-mail : [email-masked]
> > >>>>Public : http://psg.com/~dpapadimitriou/
> > >>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >>>>Phone : +32 3 240-8491
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > > 
> > 
> > 
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491
> > 
> > 
> 
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> Networking Research Laboratories, 
> NEC Corporation
> E-mail: [email-masked]
> Phone: +81 44 856 8109, FAX: +81 44 856 8071
> 
> 

Delivery-date: Sat, 05 Jul 2003 19:53:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Sat, 5 Jul 2003 19:55:30 +0100

Hi Vishal,

Please see comments in previous mail to Richard et alia.

> > 2. Fault repair
> >
> >   I don't see anything in your draft that discusses fault repair. How
> >   does the reporting node revoke its fault report?
>
> The reporting node will invoke "fault repair" using normal channels
> (possibly just the routing protocol in use in the network). This is
> because the "fault repaired" info. isn't really time critical. It's
> only purpose is to make sure (as you observe below) that repaired
> resources don't remain stranded indefinitely.
>
> I think the existing P&R drafts don't make explicit mention of
> fault repair either, probably for this very reason. (They also assume,
> like we do, that the "fault repair" indication is a background activity
> that happens via normal channels.)

I agree, but my point is that when you spread the information distribution
between two protocols you have no way of knowing for certain wheter a
resource is available or faulted. Which notification will you believe?

I think that the need to resolve this conflict means that all of the points
I raised below are relevant.

> >   This would appear to be a requirement otherwise repaired
> >   resources will never be made available again. I think that when
> >   you add this function and add the necessary controls to ensure
> >   that each node has the right state (fault or no fault) you will have
> >   invented a link state protocol.
>
> Based on the explanation above, we don't really see the need to add
> this functionality to a fault notification protocol of the type proposed
in
> draft-rabbat-fault-notification-protocol-03.txt.
> So fault notification retains it lightweight character, as desired.
>
> >   At this point I don't see what LMP gives you that an existing
> >   link-state protocol doesn't already deliver. Certainly the
> >   speed of reporting of faults to every node in the network
> >   will be lost once you have to prevent "thrash" of fault and
> >   fault clear notifications.
>
> Given that the "no fault" indication isn't time critical, as discussed
> above, one still derives the benefit of lightweight fault notification
> using LMP.
>
> Some of the drawbacks of adapting a link-state routing protocol to
> achieve such notification were discussed in the thread a few ago,
> in response to Roberto Albenese's email (which also pointed out
> the difficulty of scaling a signaling-based notification scheme
> when there are multiple LSP/lambdas on a link, and they don't
> share the same ingress/egress pairs, thus reducing the effectiveness
> of bundling Notifys.)

Agreed, but...
Please distinguish between notifying repair points about a failed LSP and
notifying repair points about the availability of resources in the network.
Also note that Notify Request objects may be modified within the network to
change how Notify messages are propagated making fault notification
propagation approximate to your LMP flooding close to the fault and
approximate to one-for-one notification further from the fault.

> Finally, the "thrashing" you refer to would be an issue even in
> signaling-based notification. If you send a Notify message to a
> repair point and then learn that the fault has been repaired,
> what does a detecting entity do? I think it pretty much allows
> the recovery action to proceed.

Notify messages do not inform the CSPF database: That is updated by the
routing protocol. The Notify message may supply input to the CSPF
calculation (see the crankback draft).

> The assumption here is that there is a fault correlation phase
> preceding the notification phase. If the fault correlation fuction
> determines that a fault has occured that requires the initiation of
> a recovery action, I would think the action wouldn't really be
> turned off midway.
> Rather, the recovery action would proceed, and,
> upon learning of the fault repair (via normal channels), policy
> would have to decide how to use the repaired resources.

Again, the distinction is between LSP fault notification and resource fault
notification. no-one (I hope) is suggesting that an RSVP-TE message should
feed information into the traffic engineering database.

> >  In any case, it is not clear to me that
> >   every node in the network needs rapid notification of faults -
> >   only those nodes that constitute repair points for the LSPs
> >   that used the failed resource need to know quickly and they
> >   hear about the problem through a directed Notify message
> >   that must propagate faster than any hop-by-hop protocol
> >   can.
>
> Actually, that's an interesting point, probably worth discussing.
>
> The flooding-based notification ensures that the fault notification
> gets to the repair point in the minimum number of hops.

Not necessarily so. The LMP method (with out-of-band signaling)
may require many IP hops between each LMP-capable switch.

> (The signaling-based
> notification allows the message to follow the "shortest path" to the
> repair point, where the shortest path is based on metrics for plain IP
> routing, which don't necessarily ensure that it gets there in the least
> number of hops; it only ensures that it gets there following the "shortest
> path" per the applicable metrics.)

Recall that not all nodes on the control plane are (G)MPLS switches.
So this isn't as simple as it may seem. In the IP network it may be just one
hop from ingress to egress even though there are many LSRs on the LSP. This
is made more significant when LSPs are routed using TE considerations.

> The second observation is that in shared mesh recovery, not only repair
> points but all intermediate nodes along the recovery path need to learn
> of the fault (so that they may reconfigure their cross-connects to carry
> the working traffic coming down the recovery path).

Yes, but...
When notified of a fault, the repair path does not know that the working
path has failed and that the protection path is about to be activated unless
- it knows about the full route of the working path
- it knows about all other faults in the network
- it knows about the policy applied at repair points
(consider, at least, n protects m situations)

> Using signaling-based notification, this requires an additional 2 or 3
phase
> handshake between the LSP end-points, which lengthens recovery time.

Yes. This a considerable draw-back of "extra traffic" usage. That is why
this is a lower grade protection service comapred to straight 1:1 or 1+1
protection.

> Additonally, there is the issue of scaling signaling when a large number
> of LSPs are affected by a given fault (e.g. a fiber cut).
>
> However, using controlled flooding-based notification, as proposed
> in draft-rabbat, it is shown (in the draft) that by an adequate choice
> of recovery paths, it's possible to ensure that all nodes along the
> recovery path learn of the fault (on the working path) by the time the
> end-nodes learn about it. This has two benefits: multiple nodes along
> the recovery path that learn of the fault may reconfigure themselves in
> parallel (saving time), and no additional handshaking is needed once the
> repair point learns of the fault.

Sure they will all learn of the fault, but how will they learn which LSPs
are impacted?  The implication is that every node has a full label-enabled
RRO available to it and that each time it receives a fault report from
anywhere in the network it processes all RROs in all LSPs that transit it.
This is non-trivial processing.

> And, of course there is the potential advantage that flooding allows for
> (in the worst case) no more than one message per link per fault, whereas
> signaling will require (in the worst case) a number of messages equal to
> the no. of LSPs to be sent by the detecting entity to the LSP repair
points.

But, as in my email to Richard, this could be looked at the other way.

In the worst case, flooding requires a message and processing on every link
and node in the network, where in signaling (in the worst case) only two
messages are sent for each impacted LSP.

Cheers,
Adrian

Delivery-date: Sat, 05 Jul 2003 19:53:18 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Vishal Sharma \(E-mail 2\)'" <[email-masked]>
Subject: Re: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Sat, 5 Jul 2003 19:21:26 +0100

Hi Richard,

> > 1. In section 3 you say
> >
> >  [Optional]: If the receiving node has activated one or more recovery
> >   paths, it sends a RecoveryCompleteNotify message to either the egress
> >   nodes of the recovery LSPs or to the NMS.  It continues sending
> >   RecoveryCompleteNotify messages periodically until it receives a
> >   RecoveryCompleteNotifyAck message or a timer to retry sending
> >   expires.
> >
> >   ...Isn't this a change to the way LMP operates? That is, before this
> >   message, LMP is a neighbor-to-neighbor protocol.
>
> That is true. We did use LMP in our prototype testbed for these optional
> messages to make the NMS aware that the recovery is complete, but that was
> just because our NMS talked LMP.  As our draft discusses, this message is
> specified as [optional], but we thought it would be good to have some kind
> of communication to tell the NMS that the recovery was completed, since it
> is aware of the fault at some point.
> We do not advocate the use of LMP for this message and did not specify its
> format in the draft for that reason.  We'll clarify that is in not an LMP
> message in our next draft submission. If people think this message is not
> needed, we could drop it altogether.

Sure.
If we determine the message *is* needed, we have a problem.
Time for another protocol?

> > 2. Fault repair
> >
> >   I don't see anything in your draft that discusses fault repair. How
> >  does the reporting node revoke its fault report?
> >
> > This would appear to be a requirement otherwise repaired
> >  resources will never be made available again. I think that when
> >  you add this function and add the necessary controls to ensure
> >  that each node has the right state (fault or no fault) you will have
> >  invented a link state protocol.
>
> If I understand your point correctly, you are concerned about sending the
> state -let's call it: "Fault Repaired"- as part of our protocol. We do not
> think the "Fault repaired" is a time-critical message and it could be
> propagated through the regular channels.  Ultimately, a policy issue could
> decide what to do about a "Fault Repaired" message. This could involve
> reactivating previously working paths, or keeping traffic on the activated
> recovery paths.  Therefore, we use LMP for Fault Notification *only*.

You are correct that "Fault repaired" is not as time critical.

When you talk about "regular channels" I'm concerned you are setting
yourself up for problems. Suppose OSPF-TE is your regular channel. When a
"Fault" and "Fault repaired" are received in close succession (in either
order) you will need to determine which really applies. By using different
protocols you make this more difficult than by using a single protocol.

> >   At this point I don't see what LMP gives you that an existing
> >   link-state protocol doesn't already deliver. Certainly the
> >   speed of reporting of faults to every node in the network
> >   will be lost once you have to prevent "thrash" of fault and
> >   fault clear notifications.
>
> I think this problem exists in all situations, whether you use signaling
or
> flooding. In the case of "fault clear" notifications using signaling, you
> could send the message to the egress that has already started the
activation
> of the recovery path. Then the egress has to do something about it. I
think
> the best way to deal with it is to complete the activation process and
look
> at policy to decide what to do about a "Fault repaired" message.

As above, the issue is not what to do when receiving a "Fault repaired",
but how to achieve temporal reconcilliation between "Fault" and "Fault
repaired" in an unreliable network.

> >  In any case, it is not clear to me that
> >  every node in the network needs rapid notification of faults -
> >  only those nodes that constitute repair points for the LSPs
> >  that used the failed resource need to know quickly and they
> >  hear about the problem through a directed Notify message
> >  that must propagate faster than any hop-by-hop protocol
> >  can.
>
> I'm not sure about that. Your directed Notify message has to initiate
> signaling on the recovery path, which would have to go on the path and
back,
> whereas a probably shorter route will exist between the detecting node and
> the nodes on the recovery paths, leading to faster recovery.

There are two separate issues here.
- The Notify *will* go by the shortest route. It does not follow the
   path of the LSP, but is routed by the SPF. It is not processed
   by each router that sees it (indeed they need not be MPLS capable).
   Thus, the Notify achieves faster fault notification (to designated LSRs)
   than hop-by-hop LMP flooding can.
- Signaling for transition to recovery paths is needed in all cases
   regardless of the fault notification method unless the path is
presignaled
   in which case no signaling is required.

> In addition, assuming that you will have one or few Notify messages is not
> going to work in a large mesh network:
> 1. recovery paths have to be calculated using whatever
> protection/restoration algorithm which tries to increase network
efficiency

I don't believe the protection/recovery algorithm changes the way that
Notifications are propagated.

> 2. they likely will have different egress points since they will be
> protecting LSPs with differing ingress(es)/egress(es).

This is true. However, you must contrast the worst case (one Notify in each
direction for each impacted LSP) with the other worst case (flooding of LMP
fault notification to every node in the network)

> The assumption about lots of recovery paths being the same for the same
> fiber fault is restrictive.

Agreed.

> Please let me know if I understood you correctly.

Progress is being made!

Adrian

Delivery-date: Sat, 05 Jul 2003 19:53:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Subject: Re: New draft on Extra class LSP
Date: Sat, 5 Jul 2003 18:46:17 +0100

I agree with Dimitri here.

There is no reason to assume that (the resources for) a protection LSP
should not pre-empted by some other LSP. That is the nature of pre-emption
and it is a Good Thing (TM).

Just as the working LSP might itself be pre-empted, so might the protection
LSP.

One might invent all sorts of schemes to help manage this (such as making
protection LSPs operate at a higher priority than working LSPs), but this is
a network operator's choice (or the subject of a BCP). No new protocol would
appear to be necessary to manage this.

Adrian

----- Original Message ----- 
From: <[email-masked]>

> > In the latter case, however, the only way any traffic could use the
> > reserved resources would be for one to setup a low-priority,
pre-emptible
> > LSP using those resources, with the distinction that these particular
> > low-priority LSPs are not subject to pre-emption unless a working
> > LSP that needs to use those reserved resources fails (This what
> > Shiomoto-san more accurately calls "extra-LSP".)
>
> the point is to have a network wide homogeneous allocation
> of resources, starting to have allocation based on the
> reason why the lower priority lsp can be preempted leads you
> to the issue of how many of such conditions can we have
> in a network ? or do you plan to start defining one class
> of lsp and priority per such event ? the idea behind the
> "re-use" of these preemptible resources is to abstract its
> complexity not to spread it network wide - this while what
> we have today works perfectly -

Delivery-date: Sat, 05 Jul 2003 14:47:01 +0000
Date: Sat, 05 Jul 2003 16:43:51 +0200
From: [email-masked]
To: Yoshihiko SUEMURA <[email-masked]>
Cc: Kohei Shiomoto <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

hi,

see in-line...

Yoshihiko SUEMURA wrote:
> Dimitri,
> 
> Are you saying the following?
> 
> - In Shared Mesh Restoration, bandwidth reserved for recovery LSPs can
>   be advertised by using the "Max LSP Bandwidth at priority X" field in
>   the Interface Switching Capability sub-TLV.

yes, you can

> - You can setup a low priority LSP (or an Extra-LSP) by setting priority
>   X at the Setup Priority field of the Session Attribute object in the RSVP
>   message.

yes, you can

> This makes sense to me. But, I am still wondering if it is the way the
> priority mechanism should be used.

that's the whole point in fact, and the reason why it'd make sense
is because there is no real difference in the preemption mechanisms
that'd happen during "classical" provisioning and the ones applied
to preempt the resources of these lower priority lsp's thus here
shared-mesh is from a bandwidth per priority accounting pespective
a particular case that can make use of the toolbox made available
by the existing gmpls i-d's: there is no "pre-defined" absolute
semantic to these priorities when taken one by one but only their
relationships is known on a network wide scope (for instance you
know priority Y > X, and X can be preempted by Y), here what can
be considered in the shared mesh context is to define this specific
relation ship among priorities (thus X and Y) and this may also be
extended to more than two priorities as long as we keep X for this
specific purpose (thus to some extend introducing shared mesh bw
accounting determines the usage of the priority level X but as you
have seen it does not *require* to define for this purpose a "new"
one since this level is definitely used by lsp's that have exactly
the same status than those of an upper or a lower level from a
preemption perspective) this means that once resources have been
allocated for these lsp's they behave as any other lower priority
lsp's, closing the loop with what vishal said, giving them a real
specific status due to the reason why these lsp's can be preempted
breaks the homogeneity of the resource selection and allocation
mechanisms (at the end does it make any difference to know that
the level X is using the "shared mesh recovery resources" on a
network wide scope, i think that the trully important information
is to know this level can be preempted, we do not gain anything
by spreading on a network wide basis the semantic of the preemption
rules between the X and Y levels)

thanks,
- dimitri.

> Regards,
> 
> Yoshihiko
> 
> On Fri, 04 Jul 2003 14:04:04 +0200,
> [email-masked] wrote:
> 
> 
>>hi kohei,
>>
>>in between "1:1 lsp protection with extra-traffic lsp" (covered in
>>section 6 of the termino and section 7 of the signaling i-d) and
>>"1:1 lsp re-routing without extra-traffic lsp" (defined in section
>>7 of the termino and section 8 of the signaling i-d) where it is
>>assumed that these resources can be re-used by lower priority lsp
>>which is of course *not* the recovery lsp associated to the working
>>lsp, i do not see where additional markup is needed from a signaling
>>perspective (since these extra-traffic lsp have their specific
>>bit setting in the protection object), while the lower priority
>>lsp established using the preemptible recovery resources are also
>>signaled using existing rfc's and wg i-d's (but this is not within
>>in the scope of the signaling i-d i am referring to), and for
>>what relates to the signaling i-d i think that the distinction has
>>been clearly made for the extra-traffic lsps (that can or not carry
>>carry traffic).
>>
>>now of course you can always tell me here the following: once the
>>recovery lsp is (control-plane) established in a shared-mesh recovery
>>scheme, it gives raise to a "new class" of resources from which the
>>resources have been pre-selected but the assumption made here (see
>>the analysis i-d) is that this pool is already within the priority
>>list already made available in gmpls-routing i-d's isc sub-tlv -
>>this is the baseline from which we started in atlanta (note: this
>>may evolve but i don't have for the time being any strong rationale
>>to make this evolving except that it would complexify the control
>>of an already complex recovery scheme - i mean here shared mesh
>>recovery).
>>
>>what i would thus suggest, since by the time even the relatively
>>simple recovery schemes have already shown to be more complex (than
>>expected) once control plane driven, it is to clearly provide us,
>>the (potential) rationales to perform this separation and achieve
>>further expected optimization or see it from the other way around -
>>because this is probably the main issue - what are the protocol
>>aspects that are not affected by the current baseline, that would
>>be in case such kind of mechanism is introduced ? in any case you
>>would fall into a scope that we don't cover here since the proposed
>>approach does not assume any additional gmpls routing extensions
>>(see also conclusion of the analysis i-d, thus here i do not think
>>appropriate to make a come back now on a consensus made last year)
>>but if people can demonstrate that new paradigms and further
>>optimization based on gmpls-routing extensions would better meet
>>their future expected needs and thus fall into a new charter item,
>>really fine with me (i would be glad to help in this effort, in
>>case)
>>
>>thanks,
>>- dimitri.
>>
>>Kohei Shiomoto wrote:
>>
>>>Hi, Dimitri,
>>>
>>>In the extra LSP draft, we want to make clear distinction between lower
>>>priority LSP and extra LSP.
>>>
>>>Priority mechanism is used to differentiate the service quality for
>>>working resource. The resource for working LSPs is contended by working
>>>LSPs of different priority classes. Service quality is dependent on
>>>traffic ratio of different priority classes; service quality of lower
>>>priority LSP degrades if higher priority LSP request comes frequently.
>>>Resource for protecting LSP in shared mesh restoration is preempted only
>>>when the working LSP fails. Service quality does not depend on traffic
>>>ratio of different priority class. We could define another service class
>>>which does not depend on the traffic ratio of different priority class
>>>by using resources for protecting LSP in shared mesh restoration.
>>>Priority mechanism is used for service differentiation based on relative
>>>traffic volume difference while extra LSP is preempted only when the
>>>working LSP fails. So we should make distinction between lower priority
>>>LSP and extra LSP.
>>>
>>>Thanks.
>>>--
>>>Kohei
>>>
>>>
>>>
>>>>hi vishal,
>>>>
>>>>see in-line...
>>>>
>>>>Vishal Sharma wrote:
>>>>
>>>>
>>>>
>>>>>Hi Dimitri,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>>>Behalf Of [email-masked]
>>>>>>Sent: Thursday, July 03, 2003 2:45 AM
>>>>>>To: Kohei Shiomoto
>>>>>>Cc: Adrian Farrel; [email-masked]
>>>>>>Subject: Re: New draft on Extra class LSP
>>>>>>
>>>>>>
>>>>>>hi adrian, kohei,
>>>>>>
>>>>>>in the case of pre-planned re-routing without extra-traffic
>>>>>>the unallocated protecting resource can be used by other
>>>>>>(lower priority LSPs) at the condition that the resources
>>>>>>are preempted when the working LSP fails (hint: i wanted
>>>>>>to point out also that this should be obvious otherwise
>>>>>>there is no reason for having this "path protection only")
>>>>>
>>>>>
>>>>>
>>>>>Actually, I think the terminology choice "without extra-traffic"
>>>>>is a bit confusing. It wasn't clear how the document distinguishes
>>>>>between "extra traffic" and "low priority traffic that can be
>>>>>pre-empted"?
>>>>
>>>>
>>>>it distinguishes between protection and (pre-planned) re-
>>>>routing, for the former it thus refers to protection with
>>>>extra-traffic & the latter re-routing without extra-traffic
>>>>(see also section 7.1 of the terminology doc.) since the
>>>>end-to-end association delivering path protection does not
>>>>allow to carry any extra-traffic, now the fact that these
>>>>resources can be used for lower priority traffic boils us
>>>>down to the setup of low priority lsp (that may be thus
>>>>preempted) but this is not anymore a specific "p&r" issue
>>>>except the fact the trigger for this preemption is internal
>>>>to the network and not an external provisioning or config
>>>>event (but anyway an additional sentence here would more
>>>>than certainly not hurt)
>>>>
>>>>
>>>>
>>>>>>and the below i-d points out specific aspects (that are
>>>>>>covered "partially" by other gmpls i-d's) see below:
>>>>>>- advertize the bandwidth: -> gmpls-routing (and bw acct)
>>>>>>- extra class LSP indication in signaling message -> priority
>>>>>>in (g)mpls signaling
>>>>>>- extra class LSP preemption signaling -> PathErr with SR
>>>>>>Flag and PathTear (to release the lower priority LSP)
>>>>>>but this can be qualified here as an "hard preemption"
>>>>>>mechanism
>>>>>>- preventing unintended connections -> it is a transient
>>>>>>behaviour that may occur at an intermediate node e.g.
>>>>>>if the previous point is not used, and cross-connection
>>>>>>is fully performed in the downstream direction
>>>>>>
>>>>>
>>>>>
>>>>>I endorse the need to focus seriously on the last point, since,
>>>>>if during dropping "extra traffic" or "low priority pre-emptable
>>>>>traffic",
>>>>>the intermediate nodes end up misconnecting traffic (even for a short
>>>>>while), it would be a real violation of SLAs. 
>>>>
>>>>
>>>>well the issue i wanted to point out is that these lower priority
>>>>lsp's can be established outside of the scope of the p&r context
>>>>it refers to larger scope issue (*) - note that this misconnection
>>>>(as currently specified) does not occur for lsp protection with
>>>>extra-traffic (see section 7) or if you want the only reason for
>>>>preemption is protection switching that occurs only on and end-to
>>>>end basis
>>>>
>>>>(*) i refer here to the mpls mailing list discussion
>>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>
>>>>
>>>>>I would suspect it
>>>>>would make customer's with mission critical traffic (and their
>>>>>service providers, implementing such a scheme) very uncomfortable to
>>>>>know
>>>>>that this is even a remote possibility! :-)
>>>>>
>>>>>-Vishal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Kohei Shiomoto wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi, Adrian
>>>>>>>
>>>>>>>In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
>>>>>>>the shared mesh restoration is addressed. Extra traffic cannot be
>>>>>>>carried because the protecting LSPs are not instantiated in shared
>>>>>>>mesh
>>>>>>>restoration networks. But the resource for the protecting LSPs are
>>>>>>>reserved to back up the failure of primary LSPs. The reserved resource
>>>>>>>could be allocated for extra traffic to enhance the network
>>>>>>>utilization.
>>>>>>>
>>>>>>>The purpose of our draft is to initiate the discussion on how to
>>>>>>>handle
>>>>>>>extra class LSP using the reserved link resource for the
>>>>>>
>>>>>>
>>>>>>protecting LSPs
>>>>>>
>>>>>>
>>>>>>
>>>>>>>while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
>>>>>>
>>>>>>
>>>>>>addresses
>>>>>>
>>>>>>
>>>>>>
>>>>>>>the signaling of primary and protecting LSPs.
>>>>>>>
>>>>>>>Regarding extra class LSP, the following issues need to be addressed:
>>>>>>>(1) advertisement of available resource for extra class LSP, (2) extra
>>>>>>>class LSP indication in signaling message (3) extra class LSP
>>>>>>
>>>>>>
>>>>>>preemption
>>>>>>
>>>>>>
>>>>>>
>>>>>>>signaling, and (4) preventing unintended connections. Our draft
>>>>>>
>>>>>>
>>>>>>provides
>>>>>>
>>>>>>
>>>>>>
>>>>>>>the problem statement of these issues.
>>>>>>>
>>>>>>>Hope this clarify the difference.
>>>>>>>Thank you for your interest.
>>>>>>>---
>>>>>>>Kohei
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Shiomoto_san,
>>>>>>>>
>>>>>>>>Could you help us prepare for Vienna by summarizing the difference
>>>>>>>>between
>>>>>>>>your draft and
>>>>>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>>>>>>>>reference to the carrying of "extra traffic" on the resources of a
>>>>>>>>protection path in a mesh network.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Adrian
>>>>>>>>
>>>>>>>>----- Original Message -----
>>>>>>>>From: "Kohei Shiomoto" <[email-masked]>
>>>>>>>>To: <[email-masked]>
>>>>>>>>Sent: Tuesday, July 01, 2003 3:18 AM
>>>>>>>>Subject: New draft on Extra class LSP
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Sorry for the incorrect subject in the previous mail. I
>>>>>>>>
>>>>>>>>
>>>>>>resend it with a
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>new subject.
>>>>>>>>>
>>>>>>>>>Hi, all
>>>>>>>>>
>>>>>>>>>Please notice that a new internet-draft has been posted. The
>>>>>>>>>draft is
>>>>>>>>>targeted at the IETF57 ccamp meeting. The draft is prepared
>>>>>>>>
>>>>>>>>
>>>>>>to initiate
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>the discussion at the ccamp-wg on the extra class LSP service, which
>>>>>>>>>makes use of reserved but unallocated bandwidth for the
>>>>>>>>
>>>>>>>>
>>>>>>protecting LSPs
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>in the pre-planned LSP re-routing recovery method (including
>>>>>>>>
>>>>>>>>
>>>>>>shared mesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>restoration). Comments and feedbacks are highly appreciated.
>>>>>>>>>Thanks.
>>>>>>>>>-- 
>>>>>>>>>Kohei Shiomoto
>>>>>>>>>NTT Network Innovation Laboratories
>>>>>>>>>Phone +81 422 59 4402, Fax +81 422 59 6387
>>>>>>>>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>>>>>>>>
>>>>>>>>
>>>>>>------------------------------------------------------------------
>>>>>>--------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>----------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Title : Extra class LSP service using protecting
>>>>>>>>
>>>>>>>>
>>>>>>resources in
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>GMPLS networks
>>>>>>>>>Author(s) : K. Shimano et al.
>>>>>>>>>Filename : draft-pil-ccamp-extra-lsp-00.txt
>>>>>>>>>
>>>>>>>>>This document provides the problem statement on a extra class LSP
>>>>>>>>>ser-
>>>>>>>>>vice and addresses the issues. The extra class LSP uses the resource
>>>>>>>>>reserved but not allocated for the protecting LSPs in the
>>>>>>>>>pre-planned
>>>>>>>>>LSP re-routing without extra-traffic (including shared mesh)
>>>>>>>>>recovery
>>>>>>>>>method. Network utilization is improved because the resource
>>>>>>>>>reserved
>>>>>>>>>for the protecting LSPs are used for the extra class LSPs. The extra
>>>>>>>>>class LSP is preempted less frequently than the conventional
>>>>>>>>>priority
>>>>>>>>>mechanism using setup and holding priorities because the resource
>>>>>>>>>reserved for the protecting LSPs is allocated only if the working
>>>>>>>>>LSP
>>>>>>>>>fails, which is usually expected to rarely occur. This document pro-
>>>>>>>>>poses the extra class LSP service using the resource reserved but
>>>>>>>>>not
>>>>>>>>>allocated for the protecting LSP at the provisioning phase.
>>>>>>>>
>>>>>>>>
>>>>>>This docu-
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>ment addresses the issues on the extra class LSP: (1)
>>>>>>>>>advertisement of
>>>>>>>>>available resource, (2) extra class LSP indication in
>>>>>>>>
>>>>>>>>
>>>>>>signaling message
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>(3) extra class LSP preemption signaling, and (4) preventing
>>>>>>>>
>>>>>>>>
>>>>>>unintended
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>connections.
>>>>>>>>>
>>>>>>>>>A URL for this Internet-Draft is:
>>>>>>>>>http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>-- 
>>>>>>Papadimitriou Dimitri
>>>>>>E-mail : [email-masked]
>>>>>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>>>>>E-mail : [email-masked]
>>>>>>Public : http://psg.com/~dpapadimitriou/
>>>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>>>Phone : +32 3 240-8491
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : [email-masked]
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
>>
> 
> 
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> Networking Research Laboratories, 
> NEC Corporation
> E-mail: [email-masked]
> Phone: +81 44 856 8109, FAX: +81 44 856 8071
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sat, 05 Jul 2003 12:04:52 +0000
Date: Sat, 05 Jul 2003 14:00:35 +0200
From: [email-masked]
To: [email-masked]
Cc: Kohei Shiomoto <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

vishal,

[snip]

> In the latter case, however, the only way any traffic could use the
> reserved resources would be for one to setup a low-priority, pre-emptible
> LSP using those resources, with the distinction that these particular
> low-priority LSPs are not subject to pre-emption unless a working
> LSP that needs to use those reserved resources fails (This what
> Shiomoto-san more accurately calls "extra-LSP".)

the point is to have a network wide homogeneous allocation
of resources, starting to have allocation based on the
reason why the lower priority lsp can be preempted leads you
to the issue of how many of such conditions can we have
in a network ? or do you plan to start defining one class
of lsp and priority per such event ? the idea behind the
"re-use" of these preemptible resources is to abstract its
complexity not to spread it network wide - this while what
we have today works perfectly -

> So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-) and let's
> clearly define "extra traffic" in the terminology doc., because I don't
> think the definition, as it stands, in precise enough, unfortunately.

the proposed definition (in the terminology i-d) is generic
enough to cover any cases of extra-traffic that we may
encounter, as said before in the "e2e" signaling i-d this
definition is applied in this "e2e" context, there is here
absolutely no reason (for the time being) to change the
definition in the terminology document due to its usage
in the signaling i-d - the only reason to change a def.
in the terminology i-d would be that it doesn't cover the
case of a concept developed in one of the subsequent i-d's
not the other way around

thanks,
- dimitri.

Delivery-date: Sat, 05 Jul 2003 08:52:36 +0000
Date: Sat, 05 Jul 2003 17:50:21 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked], Kohei Shiomoto <[email-masked]>
Subject: Re: New draft on Extra class LSP
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked]

Dimitri,

Are you saying the following?

- In Shared Mesh Restoration, bandwidth reserved for recovery LSPs can
  be advertised by using the "Max LSP Bandwidth at priority X" field in
  the Interface Switching Capability sub-TLV.
  
- You can setup a low priority LSP (or an Extra-LSP) by setting priority
  X at the Setup Priority field of the Session Attribute object in the RSVP
  message.

This makes sense to me. But, I am still wondering if it is the way the
priority mechanism should be used.

Regards,

Yoshihiko

On Fri, 04 Jul 2003 14:04:04 +0200,
[email-masked] wrote:

> hi kohei,
> 
> in between "1:1 lsp protection with extra-traffic lsp" (covered in
> section 6 of the termino and section 7 of the signaling i-d) and
> "1:1 lsp re-routing without extra-traffic lsp" (defined in section
> 7 of the termino and section 8 of the signaling i-d) where it is
> assumed that these resources can be re-used by lower priority lsp
> which is of course *not* the recovery lsp associated to the working
> lsp, i do not see where additional markup is needed from a signaling
> perspective (since these extra-traffic lsp have their specific
> bit setting in the protection object), while the lower priority
> lsp established using the preemptible recovery resources are also
> signaled using existing rfc's and wg i-d's (but this is not within
> in the scope of the signaling i-d i am referring to), and for
> what relates to the signaling i-d i think that the distinction has
> been clearly made for the extra-traffic lsps (that can or not carry
> carry traffic).
> 
> now of course you can always tell me here the following: once the
> recovery lsp is (control-plane) established in a shared-mesh recovery
> scheme, it gives raise to a "new class" of resources from which the
> resources have been pre-selected but the assumption made here (see
> the analysis i-d) is that this pool is already within the priority
> list already made available in gmpls-routing i-d's isc sub-tlv -
> this is the baseline from which we started in atlanta (note: this
> may evolve but i don't have for the time being any strong rationale
> to make this evolving except that it would complexify the control
> of an already complex recovery scheme - i mean here shared mesh
> recovery).
> 
> what i would thus suggest, since by the time even the relatively
> simple recovery schemes have already shown to be more complex (than
> expected) once control plane driven, it is to clearly provide us,
> the (potential) rationales to perform this separation and achieve
> further expected optimization or see it from the other way around -
> because this is probably the main issue - what are the protocol
> aspects that are not affected by the current baseline, that would
> be in case such kind of mechanism is introduced ? in any case you
> would fall into a scope that we don't cover here since the proposed
> approach does not assume any additional gmpls routing extensions
> (see also conclusion of the analysis i-d, thus here i do not think
> appropriate to make a come back now on a consensus made last year)
> but if people can demonstrate that new paradigms and further
> optimization based on gmpls-routing extensions would better meet
> their future expected needs and thus fall into a new charter item,
> really fine with me (i would be glad to help in this effort, in
> case)
> 
> thanks,
> - dimitri.
> 
> Kohei Shiomoto wrote:
> > Hi, Dimitri,
> > 
> > In the extra LSP draft, we want to make clear distinction between lower
> > priority LSP and extra LSP.
> > 
> > Priority mechanism is used to differentiate the service quality for
> > working resource. The resource for working LSPs is contended by working
> > LSPs of different priority classes. Service quality is dependent on
> > traffic ratio of different priority classes; service quality of lower
> > priority LSP degrades if higher priority LSP request comes frequently.
> > Resource for protecting LSP in shared mesh restoration is preempted only
> > when the working LSP fails. Service quality does not depend on traffic
> > ratio of different priority class. We could define another service class
> > which does not depend on the traffic ratio of different priority class
> > by using resources for protecting LSP in shared mesh restoration.
> > Priority mechanism is used for service differentiation based on relative
> > traffic volume difference while extra LSP is preempted only when the
> > working LSP fails. So we should make distinction between lower priority
> > LSP and extra LSP.
> > 
> > Thanks.
> > --
> > Kohei
> > 
> > 
> >>hi vishal,
> >>
> >>see in-line...
> >>
> >>Vishal Sharma wrote:
> >>
> >>
> >>>Hi Dimitri,
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [email-masked] [mailto:[email-masked]]On
> >>>>Behalf Of [email-masked]
> >>>>Sent: Thursday, July 03, 2003 2:45 AM
> >>>>To: Kohei Shiomoto
> >>>>Cc: Adrian Farrel; [email-masked]
> >>>>Subject: Re: New draft on Extra class LSP
> >>>>
> >>>>
> >>>>hi adrian, kohei,
> >>>>
> >>>>in the case of pre-planned re-routing without extra-traffic
> >>>>the unallocated protecting resource can be used by other
> >>>>(lower priority LSPs) at the condition that the resources
> >>>>are preempted when the working LSP fails (hint: i wanted
> >>>>to point out also that this should be obvious otherwise
> >>>>there is no reason for having this "path protection only")
> >>>
> >>>
> >>>
> >>>Actually, I think the terminology choice "without extra-traffic"
> >>>is a bit confusing. It wasn't clear how the document distinguishes
> >>>between "extra traffic" and "low priority traffic that can be
> >>>pre-empted"?
> >>
> >>
> >>it distinguishes between protection and (pre-planned) re-
> >>routing, for the former it thus refers to protection with
> >>extra-traffic & the latter re-routing without extra-traffic
> >>(see also section 7.1 of the terminology doc.) since the
> >>end-to-end association delivering path protection does not
> >>allow to carry any extra-traffic, now the fact that these
> >>resources can be used for lower priority traffic boils us
> >>down to the setup of low priority lsp (that may be thus
> >>preempted) but this is not anymore a specific "p&r" issue
> >>except the fact the trigger for this preemption is internal
> >>to the network and not an external provisioning or config
> >>event (but anyway an additional sentence here would more
> >>than certainly not hurt)
> >>
> >>
> >>>>and the below i-d points out specific aspects (that are
> >>>>covered "partially" by other gmpls i-d's) see below:
> >>>>- advertize the bandwidth: -> gmpls-routing (and bw acct)
> >>>>- extra class LSP indication in signaling message -> priority
> >>>>in (g)mpls signaling
> >>>>- extra class LSP preemption signaling -> PathErr with SR
> >>>>Flag and PathTear (to release the lower priority LSP)
> >>>>but this can be qualified here as an "hard preemption"
> >>>>mechanism
> >>>>- preventing unintended connections -> it is a transient
> >>>>behaviour that may occur at an intermediate node e.g.
> >>>>if the previous point is not used, and cross-connection
> >>>>is fully performed in the downstream direction
> >>>>
> >>>
> >>>
> >>>I endorse the need to focus seriously on the last point, since,
> >>>if during dropping "extra traffic" or "low priority pre-emptable
> >>>traffic",
> >>>the intermediate nodes end up misconnecting traffic (even for a short
> >>>while), it would be a real violation of SLAs. 
> >>
> >>
> >>well the issue i wanted to point out is that these lower priority
> >>lsp's can be established outside of the scope of the p&r context
> >>it refers to larger scope issue (*) - note that this misconnection
> >>(as currently specified) does not occur for lsp protection with
> >>extra-traffic (see section 7) or if you want the only reason for
> >>preemption is protection switching that occurs only on and end-to
> >>end basis
> >>
> >>(*) i refer here to the mpls mailing list discussion
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>I would suspect it
> >>>would make customer's with mission critical traffic (and their
> >>>service providers, implementing such a scheme) very uncomfortable to
> >>>know
> >>>that this is even a remote possibility! :-)
> >>>
> >>>-Vishal
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Kohei Shiomoto wrote:
> >>>>
> >>>>
> >>>>>Hi, Adrian
> >>>>>
> >>>>>In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
> >>>>>the shared mesh restoration is addressed. Extra traffic cannot be
> >>>>>carried because the protecting LSPs are not instantiated in shared
> >>>>>mesh
> >>>>>restoration networks. But the resource for the protecting LSPs are
> >>>>>reserved to back up the failure of primary LSPs. The reserved resource
> >>>>>could be allocated for extra traffic to enhance the network
> >>>>>utilization.
> >>>>>
> >>>>>The purpose of our draft is to initiate the discussion on how to
> >>>>>handle
> >>>>>extra class LSP using the reserved link resource for the
> >>>>
> >>>>
> >>>>protecting LSPs
> >>>>
> >>>>
> >>>>>while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
> >>>>
> >>>>
> >>>>addresses
> >>>>
> >>>>
> >>>>>the signaling of primary and protecting LSPs.
> >>>>>
> >>>>>Regarding extra class LSP, the following issues need to be addressed:
> >>>>>(1) advertisement of available resource for extra class LSP, (2) extra
> >>>>>class LSP indication in signaling message (3) extra class LSP
> >>>>
> >>>>
> >>>>preemption
> >>>>
> >>>>
> >>>>>signaling, and (4) preventing unintended connections. Our draft
> >>>>
> >>>>
> >>>>provides
> >>>>
> >>>>
> >>>>>the problem statement of these issues.
> >>>>>
> >>>>>Hope this clarify the difference.
> >>>>>Thank you for your interest.
> >>>>>---
> >>>>>Kohei
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Shiomoto_san,
> >>>>>>
> >>>>>>Could you help us prepare for Vienna by summarizing the difference
> >>>>>>between
> >>>>>>your draft and
> >>>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
> >>>>>>reference to the carrying of "extra traffic" on the resources of a
> >>>>>>protection path in a mesh network.
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Adrian
> >>>>>>
> >>>>>>----- Original Message -----
> >>>>>>From: "Kohei Shiomoto" <[email-masked]>
> >>>>>>To: <[email-masked]>
> >>>>>>Sent: Tuesday, July 01, 2003 3:18 AM
> >>>>>>Subject: New draft on Extra class LSP
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Sorry for the incorrect subject in the previous mail. I
> >>>>>>
> >>>>>>
> >>>>resend it with a
> >>>>
> >>>>
> >>>>>>>new subject.
> >>>>>>>
> >>>>>>>Hi, all
> >>>>>>>
> >>>>>>>Please notice that a new internet-draft has been posted. The
> >>>>>>>draft is
> >>>>>>>targeted at the IETF57 ccamp meeting. The draft is prepared
> >>>>>>
> >>>>>>
> >>>>to initiate
> >>>>
> >>>>
> >>>>>>>the discussion at the ccamp-wg on the extra class LSP service, which
> >>>>>>>makes use of reserved but unallocated bandwidth for the
> >>>>>>
> >>>>>>
> >>>>protecting LSPs
> >>>>
> >>>>
> >>>>>>>in the pre-planned LSP re-routing recovery method (including
> >>>>>>
> >>>>>>
> >>>>shared mesh
> >>>>
> >>>>
> >>>>>>>restoration). Comments and feedbacks are highly appreciated.
> >>>>>>>Thanks.
> >>>>>>>-- 
> >>>>>>>Kohei Shiomoto
> >>>>>>>NTT Network Innovation Laboratories
> >>>>>>>Phone +81 422 59 4402, Fax +81 422 59 6387
> >>>>>>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> >>>>>>>
> >>>>>>
> >>>>------------------------------------------------------------------
> >>>>--------
> >>>>
> >>>>
> >>>>>>----------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Title : Extra class LSP service using protecting
> >>>>>>
> >>>>>>
> >>>>resources in
> >>>>
> >>>>
> >>>>>>>GMPLS networks
> >>>>>>>Author(s) : K. Shimano et al.
> >>>>>>>Filename : draft-pil-ccamp-extra-lsp-00.txt
> >>>>>>>
> >>>>>>>This document provides the problem statement on a extra class LSP
> >>>>>>>ser-
> >>>>>>>vice and addresses the issues. The extra class LSP uses the resource
> >>>>>>>reserved but not allocated for the protecting LSPs in the
> >>>>>>>pre-planned
> >>>>>>>LSP re-routing without extra-traffic (including shared mesh)
> >>>>>>>recovery
> >>>>>>>method. Network utilization is improved because the resource
> >>>>>>>reserved
> >>>>>>>for the protecting LSPs are used for the extra class LSPs. The extra
> >>>>>>>class LSP is preempted less frequently than the conventional
> >>>>>>>priority
> >>>>>>>mechanism using setup and holding priorities because the resource
> >>>>>>>reserved for the protecting LSPs is allocated only if the working
> >>>>>>>LSP
> >>>>>>>fails, which is usually expected to rarely occur. This document pro-
> >>>>>>>poses the extra class LSP service using the resource reserved but
> >>>>>>>not
> >>>>>>>allocated for the protecting LSP at the provisioning phase.
> >>>>>>
> >>>>>>
> >>>>This docu-
> >>>>
> >>>>
> >>>>>>>ment addresses the issues on the extra class LSP: (1)
> >>>>>>>advertisement of
> >>>>>>>available resource, (2) extra class LSP indication in
> >>>>>>
> >>>>>>
> >>>>signaling message
> >>>>
> >>>>
> >>>>>>>(3) extra class LSP preemption signaling, and (4) preventing
> >>>>>>
> >>>>>>
> >>>>unintended
> >>>>
> >>>>
> >>>>>>>connections.
> >>>>>>>
> >>>>>>>A URL for this Internet-Draft is:
> >>>>>>>http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>-- 
> >>>>Papadimitriou Dimitri
> >>>>E-mail : [email-masked]
> >>>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> >>>>E-mail : [email-masked]
> >>>>Public : http://psg.com/~dpapadimitriou/
> >>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>>>Phone : +32 3 240-8491
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> > 
> 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
> 

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

Networking Research Laboratories, 
NEC Corporation
E-mail: [email-masked]
Phone: +81 44 856 8109, FAX: +81 44 856 8071

Delivery-date: Sat, 05 Jul 2003 04:22:06 +0000
From: "yhwkim" <[email-masked]>
To: <[email-masked]>
Subject: A Updated Draft on Requirements for Control Channel Protection
Date: Sat, 5 Jul 2003 13:20:35 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C342F8.37BA3A60
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: base64

------=_NextPart_000_0014_01C342F8.37BA3A60
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: base64

------=_NextPart_000_0014_01C342F8.37BA3A60--

Delivery-date: Sat, 05 Jul 2003 00:43:27 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Fri, 4 Jul 2003 17:40:06 -0700

Dimitri,

I think we're getting to a clearer definition of things ...

Some comments in-line.

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Friday, July 04, 2003 1:21 PM
> To: [email-masked]
> Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
>
>
> vishal,
>
> see in-line...
>
> Vishal Sharma wrote:
>
> [snip]
>
> > If that is so, then it appears that you are limiting the definition of
> > "extra-traffic" to merely traffic that has the exact same ingress-egress
> > as the working path for which the recovery resources are reserved.
>
> you should make a distinction between the "extra-traffic lsp"
> meaning the lsp establish to protect the working lsp from
> the "traffic" in itself when carried over such lsp/span's is
> referred to as "extra-traffic", i think this where the whole
> point is

It appears then that an "extra-traffic LSP" is really a backup LSP
that has been _set up_ between a certain ingress-egress pair
(namely for which resources have been both been
reserved and cross-connected), and "extra traffic" is traffic
that uses the resources of such an LSP.

My point is that the current definition of "extra traffic" in the
terminology document does not make this clear.

Upon reading that definition, one comes away with the impression
that traffic that
uses the resources of a previously set up backup LSP _or_ traffic
that uses the resources that have merely been reserved for a backup
LSP, but haven't been cross-connected, are _both_  "extra traffic."

In the latter case, however, the only way any traffic could use the
reserved resources would be for one to setup a low-priority, pre-emptible
LSP using those resources, with the distinction that these particular
low-priority LSPs are not subject to pre-emption unless a working
LSP that needs to use those reserved resources fails (This what
Shiomoto-san more accurately calls "extra-LSP".)

Also, if we indeed call a "cat a cat" :-), then for everything other
than 1:1 protection/restoration, there would really be no "extra-traffic",
only low-priority, pre-emptible LSPs that happen to use the resources
reserved (but not cross-connected) for shared recovery.

So let's call an "extra-traffic LSP" an "extra-traffic LSP" :-) and let's
clearly define "extra traffic" in the terminology doc., because I don't
think the definition, as it stands, in precise enough, unfortunately.

> > So if all of the above are true, the following needs to happen:
>
> i think that what should first happen, is that you call a
> cat a cat, if an lsp is establish using preemptible recovery
> resources there is no reason to call it "extra-traffic lsp"
> it is simply a "lower priority (preemptible) lsp"
>
> > i) The definition of "extra-traffic" needs to be made very
> precise in the
> > terminology doc. (At present, it seems to have the meaning that I have
> > defined above in brackets **).
>
> i think the definition is as precise as it can be for the
> definition of extra-traffic (as said above you should diff.
> the lsp with the definition of the traffic it carries)
>
> > ii) The terminology document needs to clearly define/state that the
> > resources reserved but not cross-connected can be reused by
> low-priority,
> > pre-emptible LSPs, and that the setting up of those is outside the scope
> > of the P&R doc.
>
> an i-d says what it does and refers to other, i-d's when
> it borrows mechanisms that it uses, in the present scope
> setting up "lsp's with a given priority" is a well-known
> mechanism as well its hard (see rfc3473) and soft (see
> 2205/3209) preemption
>
> > iii) We need to have further discussion of Shiomoto-san's draft, to see
> > if what is proposed there can be accomplished by existing mechanisms?
> > (I think Shiomoto-san made a good point about not using the existing
> > priority mechanisms (that work for service differentiation between
> > LSPs of the _same type (all working or all recovery)) to distinguish
> > between extra LSP and low-priority LSP.)
>
> yes, and this is what i understood from him as well but
> before that it is still very unclear what is the real
> purpose of it ? and it would be of interest why this
> is not enough to have achieve a common baseline ? what's
> missing to be capable to setup "low priority lsp's using
> preemptible resources" from the set of gmpls i-d's ?
>
> > iv) The terminology and signaling documents need to make clear that
> > even in the case of 1:1 LSP re-routing without extra-traffic,
> the reserved
> > resources can be used by (using Shiomoto-san's term) extra LSPs
> (since as
> > he rightly observes, extra-LSPs are not pre-empted based on
> traffic volumes,
> > only upon a failure in one of the working paths whose recovery requires
> > resources
> > being used by an extra LSP).
>
> well i think it is clear that we do not cover other
> aspects than re-using recovery resources upon failures
> (as defined in the terminology) of the working resources,
> but this is to have a specific scope and goal based on
> what p&r means
>
> thanks,
> - dimitri.
>

Delivery-date: Fri, 04 Jul 2003 20:24:05 +0000
Date: Fri, 04 Jul 2003 22:21:12 +0200
From: [email-masked]
To: [email-masked]
Cc: Kohei Shiomoto <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

vishal,

see in-line...

Vishal Sharma wrote:

[snip]

> If that is so, then it appears that you are limiting the definition of
> "extra-traffic" to merely traffic that has the exact same ingress-egress
> as the working path for which the recovery resources are reserved.

you should make a distinction between the "extra-traffic lsp"
meaning the lsp establish to protect the working lsp from
the "traffic" in itself when carried over such lsp/span's is
referred to as "extra-traffic", i think this where the whole
point is

> So if all of the above are true, the following needs to happen:

i think that what should first happen, is that you call a
cat a cat, if an lsp is establish using preemptible recovery
resources there is no reason to call it "extra-traffic lsp"
it is simply a "lower priority (preemptible) lsp"

> i) The definition of "extra-traffic" needs to be made very precise in the
> terminology doc. (At present, it seems to have the meaning that I have
> defined above in brackets **).

i think the definition is as precise as it can be for the
definition of extra-traffic (as said above you should diff.
the lsp with the definition of the traffic it carries)

> ii) The terminology document needs to clearly define/state that the
> resources reserved but not cross-connected can be reused by low-priority,
> pre-emptible LSPs, and that the setting up of those is outside the scope
> of the P&R doc.

an i-d says what it does and refers to other, i-d's when
it borrows mechanisms that it uses, in the present scope
setting up "lsp's with a given priority" is a well-known
mechanism as well its hard (see rfc3473) and soft (see
2205/3209) preemption

> iii) We need to have further discussion of Shiomoto-san's draft, to see
> if what is proposed there can be accomplished by existing mechanisms?
> (I think Shiomoto-san made a good point about not using the existing
> priority mechanisms (that work for service differentiation between
> LSPs of the _same type (all working or all recovery)) to distinguish
> between extra LSP and low-priority LSP.)

yes, and this is what i understood from him as well but
before that it is still very unclear what is the real
purpose of it ? and it would be of interest why this
is not enough to have achieve a common baseline ? what's
missing to be capable to setup "low priority lsp's using
preemptible resources" from the set of gmpls i-d's ?

> iv) The terminology and signaling documents need to make clear that
> even in the case of 1:1 LSP re-routing without extra-traffic, the reserved
> resources can be used by (using Shiomoto-san's term) extra LSPs (since as
> he rightly observes, extra-LSPs are not pre-empted based on traffic volumes,
> only upon a failure in one of the working paths whose recovery requires
> resources
> being used by an extra LSP).

well i think it is clear that we do not cover other
aspects than re-using recovery resources upon failures
(as defined in the terminology) of the working resources,
but this is to have a specific scope and goal based on
what p&r means

thanks,
- dimitri.

> Also, see some comments in-line.
> 
> -Vishal
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Friday, July 04, 2003 3:23 AM
>>To: [email-masked]
>>Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
>>Subject: Re: New draft on Extra class LSP
>>
>>
>>hi vishal
>>
>>see inline
>>
>>[snip]
>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>>>Behalf Of [email-masked]
>>>>>>Sent: Thursday, July 03, 2003 2:45 AM
>>>>>>To: Kohei Shiomoto
>>>>>>Cc: Adrian Farrel; [email-masked]
>>>>>>Subject: Re: New draft on Extra class LSP
>>>>>>
>>>>>>
>>>>>
> <snip>
> 
>>>>>Actually, I think the terminology choice "without extra-traffic"
>>>>>is a bit confusing. It wasn't clear how the document distinguishes
>>>>>between "extra traffic" and "low priority traffic that can be
>>>>>pre-empted"?
>>>>
>>>>it distinguishes between protection and (pre-planned) re-
>>>>routing, for the former it thus refers to protection with
>>>>extra-traffic & the latter re-routing without extra-traffic
>>>>(see also section 7.1 of the terminology doc.)
>>>
>>>
>>>I'm a little unclear what you mean here. As far as I can tell,
>>>the terminology document uses the term "pre-planned LSP
>>>restoration" (Section 7.1 of terminology doc.)
>>>for the case when you have pre-planned rerouting
>>>*with extra-traffic.*
>>
>>pre-planned lsp restoration or pre-planned lsp re-routing
>>refers to the same things (termino i-d):
>>
>>"7.1 Pre-planned LSP Restoration
>>
>>    Also referred to as pre-planned LSP re-routing."
> 
> 
> I fully understand that pre-planned LSP restoration and
> pre-planned LSP re-routing are the same thing. That wasn't my
> question. I asked whether pre-planned LSP rerouting, _in its
> very definition_, means you can use the reserved (but not cross-connected)
> resources for "extra traffic"?
> 
> (I understand the phrase "not cross-connected" to simply mean that the
> intervening cross-connects aren't configured to carry the traffic
> of a specific working path, but (since link resources have been reserved
> anyway)
> they could be configured to carry other traffic (the "extra traffic").)
> 
> If yes, then I'm not sure what "pre-planned LSP rerouting without
> extra traffic" means.
> If no, then the definitions in the terminology document
> need to be improved, as that isn't what one necessarily gets by
> reading the definition in Section 7.1.
> 
> 
> 
>>>Also, the definition of "extra-traffic" given earlier on in
>>>the terminology document, seems to imply that "pre-emptible
>>>low priority traffic" is precisely what extra-traffic is, whereas
>>>in your earlier response you seem to distinguish between
>>>the two.
>>
>>come to the point please, "extra-traffic" is defined
>>section 4.2 of the terminology document and the use
>>of 1:1 lsp re-routing without extra-traffic (lsp) come
>>simply from the fact that the recovery lsp is not cross-
>>connected
>>
>>
>>>>since the
>>>>end-to-end association delivering path protection does not
>>>>allow to carry any extra-traffic,
>>>
>>>
>>>I agree that for the case of end-to-end path *protection*
>>>it would be true that no extra-traffic is possible, by definition.
>>>But then this would be because the resources in that case are
>>>not only reserved, but also cross-connected. Thus, the issue
>>>of extra-traffic does not even arise there.
>>
>>we say the same thing here.
>>
>>
>>>>now the fact that these
>>>>resources can be used for lower priority traffic boils us
>>>>down to the setup of low priority lsp (that may be thus
>>>>preempted) but this is not anymore a specific "p&r" issue
>>>>except the fact the trigger for this preemption is internal
>>>>to the network and not an external provisioning or config
>>>>event (but anyway an additional sentence here would more
>>>>than certainly not hurt)
>>>
>>>
>>>Actually, for path *protection*, this is a moot point, since
>>>no extra-traffic is possible there. Thus, the only case in which
>>>extra-traffic comes into play is when one has pre-planned
>>>restoration with extra-traffic.
>>
>>not true, 1:1 lsp protection allows for extra traffic
>>and is definitelly different from 1:1 lsp re-routing
>>in the latter case for the recovery lsp does not carry
>>extra-traffic, this is why and very logically it has
>>been referred to as 1:1 lsp re-routing without extra-
>>traffic (lsp), while in the former the lsp associated
>>to the recovery entity may carry extra_traffic
>>
>>
>>>(That is, resources are set
>>>aside for recovery, but are not cross-connected, thus allowing
>>>for the reserved capacity to be used by other "extra-traffic"
>>>LSPs (or low-priority pre-emptible LSPs).)
>>><<snip>>
>>>
>>>>>I endorse the need to focus seriously on the last point, since,
>>>>>if during dropping "extra traffic" or "low priority
>>>>
>>>>pre-emptable traffic",
>>>>
>>>>
>>>>>the intermediate nodes end up misconnecting traffic (even for a short
>>>>>while), it would be a real violation of SLAs.
>>>>
>>>>well the issue i wanted to point out is that these lower priority
>>>>lsp's can be established outside of the scope of the p&r context
>>>>it refers to larger scope issue (*) - note that this misconnection
>>>>(as currently specified) does not occur for lsp protection with
>>>>extra-traffic (see section 7) or if you want the only reason for
>>>>preemption is protection switching that occurs only on and end-to
>>>>end basis
>>>
>>>
>>>Actually, I'm not sure one can have "LSP _protection_ with
>>>extra-traffic," (and Section 7 doesn't seem to have that category)
>>>since in the case of protection, my understanding
>>>is that no additional signaling should be needed, which would
>>>imply that the backup resources are both reserved and cross-connected.
>>>
>>>What one could have is pre-planned LSP re-routing with extra-traffic,
>>>which is what I started the discussion with.
>>
>>please re-read:
>>- for 1:1 lsp protection: section 6 of the termino and section 7 of
>>   the signaling i-d)
>>- for 1:1 lsp re-routing: section 7 of the termino and section 8 of
>>   the signaling i-d)
>>
>>
>>
>>--
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : [email-masked]
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 04 Jul 2003 19:08:38 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Fri, 4 Jul 2003 12:04:43 -0700

Dimitri,

Let me just recap what I think I understand so far. We can then discuss
the specific areas in which I think the documents need to be clearer.

First, from the definitions in the terminology doc., Section 4.3 A and B,
backup resources are reserved _both_ in the case of protection and
restoration.

The difference being that for protection, they are also cross-connected
(because
it is known exactly which working LSP a given backup LSP will protect).
For restoration, the resources are reserved but not cross-connected,
because, barring the 1:1 case, in any shared scheme (1:N, M:N, shared mesh),
it isn't known which particular working path the backup resources
may end up protecting.

Now "extra-traffic" could be carried in _both_ of the above cases. **
(If we
assume that "extra-traffic" is simply traffic that is using recovery
resources, and will be discarded when those resources are required to
recover the working traffic of a particular working LSP.)

The difference is that "extra-traffic" using protection resources _must_
have the same ingress-egress as the working path that the protection
resources
are reserved and cross-connected for.
(This is what allows for there to be "extra-traffic" even in the 1:1
protection
case, as you say below.)

"Extra-traffic" using restoration resources may, however, have _any_
ingress-egress,
as long as _some of the links_ on the path of the "extra-traffic" LSP share
some of the restoration resources reserved to recover a working path.

It seems to me that you are saying that for this second case, the reserved
(but not cross-connected) resources can be used by setting up low-priority
pre-emptible
LSPs. But, the use of these resources by such LSPs is something that is
_independent_
of the scope of the P&R effort, since it can (mostly) be accomplished by
existing
LSP setup mechanisms, and since the bandwidth reserved (but not cross
connected)
can (it appears) be advertized using standards GMPLS OSPF-TE. Yes?

If that is so, then it appears that you are limiting the definition of
"extra-traffic" to merely traffic that has the exact same ingress-egress
as the working path for which the recovery resources are reserved.

So if all of the above are true, the following needs to happen:

i) The definition of "extra-traffic" needs to be made very precise in the
terminology doc. (At present, it seems to have the meaning that I have
defined above in brackets **).

ii) The terminology document needs to clearly define/state that the
resources reserved but not cross-connected can be reused by low-priority,
pre-emptible LSPs, and that the setting up of those is outside the scope
of the P&R doc.

iii) We need to have further discussion of Shiomoto-san's draft, to see
if what is proposed there can be accomplished by existing mechanisms?
(I think Shiomoto-san made a good point about not using the existing
priority mechanisms (that work for service differentiation between
LSPs of the _same type (all working or all recovery)) to distinguish
between extra LSP and low-priority LSP.)

iv) The terminology and signaling documents need to make clear that
even in the case of 1:1 LSP re-routing without extra-traffic, the reserved
resources can be used by (using Shiomoto-san's term) extra LSPs (since as
he rightly observes, extra-LSPs are not pre-empted based on traffic volumes,
only upon a failure in one of the working paths whose recovery requires
resources
being used by an extra LSP).

Also, see some comments in-line.

-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, July 04, 2003 3:23 AM
> To: [email-masked]
> Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
>
>
> hi vishal
>
> see inline
>
> [snip]
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [email-masked] [mailto:[email-masked]]On
> >>>>Behalf Of [email-masked]
> >>>>Sent: Thursday, July 03, 2003 2:45 AM
> >>>>To: Kohei Shiomoto
> >>>>Cc: Adrian Farrel; [email-masked]
> >>>>Subject: Re: New draft on Extra class LSP
> >>>>
> >>>>
<snip>

> >>>Actually, I think the terminology choice "without extra-traffic"
> >>>is a bit confusing. It wasn't clear how the document distinguishes
> >>>between "extra traffic" and "low priority traffic that can be
> >>>pre-empted"?
> >>
> >>it distinguishes between protection and (pre-planned) re-
> >>routing, for the former it thus refers to protection with
> >>extra-traffic & the latter re-routing without extra-traffic
> >>(see also section 7.1 of the terminology doc.)
> >
> >
> > I'm a little unclear what you mean here. As far as I can tell,
> > the terminology document uses the term "pre-planned LSP
> > restoration" (Section 7.1 of terminology doc.)
> > for the case when you have pre-planned rerouting
> > *with extra-traffic.*
>
> pre-planned lsp restoration or pre-planned lsp re-routing
> refers to the same things (termino i-d):
>
> "7.1 Pre-planned LSP Restoration
>
>     Also referred to as pre-planned LSP re-routing."

I fully understand that pre-planned LSP restoration and
pre-planned LSP re-routing are the same thing. That wasn't my
question. I asked whether pre-planned LSP rerouting, _in its
very definition_, means you can use the reserved (but not cross-connected)
resources for "extra traffic"?

(I understand the phrase "not cross-connected" to simply mean that the
intervening cross-connects aren't configured to carry the traffic
of a specific working path, but (since link resources have been reserved
anyway)
they could be configured to carry other traffic (the "extra traffic").)

If yes, then I'm not sure what "pre-planned LSP rerouting without
extra traffic" means.
If no, then the definitions in the terminology document
need to be improved, as that isn't what one necessarily gets by
reading the definition in Section 7.1.

> > Also, the definition of "extra-traffic" given earlier on in
> > the terminology document, seems to imply that "pre-emptible
> > low priority traffic" is precisely what extra-traffic is, whereas
> > in your earlier response you seem to distinguish between
> > the two.
>
> come to the point please, "extra-traffic" is defined
> section 4.2 of the terminology document and the use
> of 1:1 lsp re-routing without extra-traffic (lsp) come
> simply from the fact that the recovery lsp is not cross-
> connected
>
> >>since the
> >>end-to-end association delivering path protection does not
> >>allow to carry any extra-traffic,
> >
> >
> > I agree that for the case of end-to-end path *protection*
> > it would be true that no extra-traffic is possible, by definition.
> > But then this would be because the resources in that case are
> > not only reserved, but also cross-connected. Thus, the issue
> > of extra-traffic does not even arise there.
>
> we say the same thing here.
>
> >>now the fact that these
> >>resources can be used for lower priority traffic boils us
> >>down to the setup of low priority lsp (that may be thus
> >>preempted) but this is not anymore a specific "p&r" issue
> >>except the fact the trigger for this preemption is internal
> >>to the network and not an external provisioning or config
> >>event (but anyway an additional sentence here would more
> >>than certainly not hurt)
> >
> >
> > Actually, for path *protection*, this is a moot point, since
> > no extra-traffic is possible there. Thus, the only case in which
> > extra-traffic comes into play is when one has pre-planned
> > restoration with extra-traffic.
>
> not true, 1:1 lsp protection allows for extra traffic
> and is definitelly different from 1:1 lsp re-routing
> in the latter case for the recovery lsp does not carry
> extra-traffic, this is why and very logically it has
> been referred to as 1:1 lsp re-routing without extra-
> traffic (lsp), while in the former the lsp associated
> to the recovery entity may carry extra_traffic
>
> > (That is, resources are set
> > aside for recovery, but are not cross-connected, thus allowing
> > for the reserved capacity to be used by other "extra-traffic"
> > LSPs (or low-priority pre-emptible LSPs).)
> > <<snip>>
> >
> >>>I endorse the need to focus seriously on the last point, since,
> >>>if during dropping "extra traffic" or "low priority
> >>
> >>pre-emptable traffic",
> >>
> >>>the intermediate nodes end up misconnecting traffic (even for a short
> >>>while), it would be a real violation of SLAs.
> >>
> >>well the issue i wanted to point out is that these lower priority
> >>lsp's can be established outside of the scope of the p&r context
> >>it refers to larger scope issue (*) - note that this misconnection
> >>(as currently specified) does not occur for lsp protection with
> >>extra-traffic (see section 7) or if you want the only reason for
> >>preemption is protection switching that occurs only on and end-to
> >>end basis
> >
> >
> > Actually, I'm not sure one can have "LSP _protection_ with
> > extra-traffic," (and Section 7 doesn't seem to have that category)
> > since in the case of protection, my understanding
> > is that no additional signaling should be needed, which would
> > imply that the backup resources are both reserved and cross-connected.
> >
> > What one could have is pre-planned LSP re-routing with extra-traffic,
> > which is what I started the discussion with.
>
> please re-read:
> - for 1:1 lsp protection: section 6 of the termino and section 7 of
>    the signaling i-d)
> - for 1:1 lsp re-routing: section 7 of the termino and section 8 of
>    the signaling i-d)
>
>
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
>

Delivery-date: Fri, 04 Jul 2003 14:22:22 +0000
Date: Fri, 04 Jul 2003 16:18:18 +0200
From: [email-masked]
To: "[email-masked]" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-kim-ccamp-gmpls-mgoxc-00.txt

hi, by reading this document the following came to mind
do you consider here (?) a specific lsp encoding type and
switching type in the generalized_label_request object
as proposed in (and as assumed per rfc 3471/73, once a
technology specific sender_tspec/flowspec is defined -
see also draft-ietf-ccamp-gmpls-sonet-sdh-08.txt for
a well-defined example) the following which just assumes
band switching without further integration (the basic
case, i'd say):

<http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-04.txt>

further integration should be imho also considered but
starting from a more generic perspective, and here i
would like to pin-point the following i-d which intends
to dress a global picture of the signaling and routing
issues to consider in such kind of so-called multi-region
environments - and as you'll see it is far from being
the end of the story -> it would be thus of great interest
to sit around the table and discuss what could be expected
as the first step):

<http://www.ietf.org/internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mrn-02.txt>

if this is achieved, then i don't see (if there is enough
support for it) any problem to get deeper into the gmpls
control plane specific issues raising from the combination
of the wavelength/waveband/fiber switching capabilities
within the same node (lo/hovc sonet/sdh and odu switching
is another example)

thanks,
- dimitri.

[email-masked] wrote:
 > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 >
 >
 > 	Title		: GMPLS Extensions to support Multi-Granularity Optical
 >                           Cross-Connect with Heterogeneous Optical Interfaces
 > 	Author(s)	: D. Kim et al.
 > 	Filename	: draft-kim-ccamp-gmpls-mgoxc-00.txt
 > 	Pages		: 14
 > 	Date		: 2003-6-26
 > 	
 > This document defines information needed when GMPLS signaling is used
 > on the multi-granularity of optical cross-connect (MG-OXC) over
 > Generalized Multiprotocol Label Switching (GMPLS) networks because
 > existing documents deal only with singular wavelength OXC. The basic
 > optical label handlings (including add, drop, swap, merge, and stack)
 > are required for using the MG-OXC in GMPLS networks. Also the
 > protocol related to signaling is extended for supporting the MG-OXC.
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-gmpls-mgoxc-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-gmpls-mgoxc-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-gmpls-mgoxc-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.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 04 Jul 2003 12:06:35 +0000
Date: Fri, 04 Jul 2003 14:04:04 +0200
From: [email-masked]
To: Kohei Shiomoto <[email-masked]>
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

hi kohei,

in between "1:1 lsp protection with extra-traffic lsp" (covered in
section 6 of the termino and section 7 of the signaling i-d) and
"1:1 lsp re-routing without extra-traffic lsp" (defined in section
7 of the termino and section 8 of the signaling i-d) where it is
assumed that these resources can be re-used by lower priority lsp
which is of course *not* the recovery lsp associated to the working
lsp, i do not see where additional markup is needed from a signaling
perspective (since these extra-traffic lsp have their specific
bit setting in the protection object), while the lower priority
lsp established using the preemptible recovery resources are also
signaled using existing rfc's and wg i-d's (but this is not within
in the scope of the signaling i-d i am referring to), and for
what relates to the signaling i-d i think that the distinction has
been clearly made for the extra-traffic lsps (that can or not carry
carry traffic).

now of course you can always tell me here the following: once the
recovery lsp is (control-plane) established in a shared-mesh recovery
scheme, it gives raise to a "new class" of resources from which the
resources have been pre-selected but the assumption made here (see
the analysis i-d) is that this pool is already within the priority
list already made available in gmpls-routing i-d's isc sub-tlv -
this is the baseline from which we started in atlanta (note: this
may evolve but i don't have for the time being any strong rationale
to make this evolving except that it would complexify the control
of an already complex recovery scheme - i mean here shared mesh
recovery).

what i would thus suggest, since by the time even the relatively
simple recovery schemes have already shown to be more complex (than
expected) once control plane driven, it is to clearly provide us,
the (potential) rationales to perform this separation and achieve
further expected optimization or see it from the other way around -
because this is probably the main issue - what are the protocol
aspects that are not affected by the current baseline, that would
be in case such kind of mechanism is introduced ? in any case you
would fall into a scope that we don't cover here since the proposed
approach does not assume any additional gmpls routing extensions
(see also conclusion of the analysis i-d, thus here i do not think
appropriate to make a come back now on a consensus made last year)
but if people can demonstrate that new paradigms and further
optimization based on gmpls-routing extensions would better meet
their future expected needs and thus fall into a new charter item,
really fine with me (i would be glad to help in this effort, in
case)

thanks,
- dimitri.

Kohei Shiomoto wrote:
> Hi, Dimitri,
> 
> In the extra LSP draft, we want to make clear distinction between lower
> priority LSP and extra LSP.
> 
> Priority mechanism is used to differentiate the service quality for
> working resource. The resource for working LSPs is contended by working
> LSPs of different priority classes. Service quality is dependent on
> traffic ratio of different priority classes; service quality of lower
> priority LSP degrades if higher priority LSP request comes frequently.
> Resource for protecting LSP in shared mesh restoration is preempted only
> when the working LSP fails. Service quality does not depend on traffic
> ratio of different priority class. We could define another service class
> which does not depend on the traffic ratio of different priority class
> by using resources for protecting LSP in shared mesh restoration.
> Priority mechanism is used for service differentiation based on relative
> traffic volume difference while extra LSP is preempted only when the
> working LSP fails. So we should make distinction between lower priority
> LSP and extra LSP.
> 
> Thanks.
> --
> Kohei
> 
> 
>>hi vishal,
>>
>>see in-line...
>>
>>Vishal Sharma wrote:
>>
>>
>>>Hi Dimitri,
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>Behalf Of [email-masked]
>>>>Sent: Thursday, July 03, 2003 2:45 AM
>>>>To: Kohei Shiomoto
>>>>Cc: Adrian Farrel; [email-masked]
>>>>Subject: Re: New draft on Extra class LSP
>>>>
>>>>
>>>>hi adrian, kohei,
>>>>
>>>>in the case of pre-planned re-routing without extra-traffic
>>>>the unallocated protecting resource can be used by other
>>>>(lower priority LSPs) at the condition that the resources
>>>>are preempted when the working LSP fails (hint: i wanted
>>>>to point out also that this should be obvious otherwise
>>>>there is no reason for having this "path protection only")
>>>
>>>
>>>
>>>Actually, I think the terminology choice "without extra-traffic"
>>>is a bit confusing. It wasn't clear how the document distinguishes
>>>between "extra traffic" and "low priority traffic that can be
>>>pre-empted"?
>>
>>
>>it distinguishes between protection and (pre-planned) re-
>>routing, for the former it thus refers to protection with
>>extra-traffic & the latter re-routing without extra-traffic
>>(see also section 7.1 of the terminology doc.) since the
>>end-to-end association delivering path protection does not
>>allow to carry any extra-traffic, now the fact that these
>>resources can be used for lower priority traffic boils us
>>down to the setup of low priority lsp (that may be thus
>>preempted) but this is not anymore a specific "p&r" issue
>>except the fact the trigger for this preemption is internal
>>to the network and not an external provisioning or config
>>event (but anyway an additional sentence here would more
>>than certainly not hurt)
>>
>>
>>>>and the below i-d points out specific aspects (that are
>>>>covered "partially" by other gmpls i-d's) see below:
>>>>- advertize the bandwidth: -> gmpls-routing (and bw acct)
>>>>- extra class LSP indication in signaling message -> priority
>>>>in (g)mpls signaling
>>>>- extra class LSP preemption signaling -> PathErr with SR
>>>>Flag and PathTear (to release the lower priority LSP)
>>>>but this can be qualified here as an "hard preemption"
>>>>mechanism
>>>>- preventing unintended connections -> it is a transient
>>>>behaviour that may occur at an intermediate node e.g.
>>>>if the previous point is not used, and cross-connection
>>>>is fully performed in the downstream direction
>>>>
>>>
>>>
>>>I endorse the need to focus seriously on the last point, since,
>>>if during dropping "extra traffic" or "low priority pre-emptable
>>>traffic",
>>>the intermediate nodes end up misconnecting traffic (even for a short
>>>while), it would be a real violation of SLAs. 
>>
>>
>>well the issue i wanted to point out is that these lower priority
>>lsp's can be established outside of the scope of the p&r context
>>it refers to larger scope issue (*) - note that this misconnection
>>(as currently specified) does not occur for lsp protection with
>>extra-traffic (see section 7) or if you want the only reason for
>>preemption is protection switching that occurs only on and end-to
>>end basis
>>
>>(*) i refer here to the mpls mailing list discussion
>>
>>thanks,
>>- dimitri.
>>
>>
>>>I would suspect it
>>>would make customer's with mission critical traffic (and their
>>>service providers, implementing such a scheme) very uncomfortable to
>>>know
>>>that this is even a remote possibility! :-)
>>>
>>>-Vishal
>>>
>>>
>>>
>>>
>>>
>>>>Kohei Shiomoto wrote:
>>>>
>>>>
>>>>>Hi, Adrian
>>>>>
>>>>>In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
>>>>>the shared mesh restoration is addressed. Extra traffic cannot be
>>>>>carried because the protecting LSPs are not instantiated in shared
>>>>>mesh
>>>>>restoration networks. But the resource for the protecting LSPs are
>>>>>reserved to back up the failure of primary LSPs. The reserved resource
>>>>>could be allocated for extra traffic to enhance the network
>>>>>utilization.
>>>>>
>>>>>The purpose of our draft is to initiate the discussion on how to
>>>>>handle
>>>>>extra class LSP using the reserved link resource for the
>>>>
>>>>
>>>>protecting LSPs
>>>>
>>>>
>>>>>while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
>>>>
>>>>
>>>>addresses
>>>>
>>>>
>>>>>the signaling of primary and protecting LSPs.
>>>>>
>>>>>Regarding extra class LSP, the following issues need to be addressed:
>>>>>(1) advertisement of available resource for extra class LSP, (2) extra
>>>>>class LSP indication in signaling message (3) extra class LSP
>>>>
>>>>
>>>>preemption
>>>>
>>>>
>>>>>signaling, and (4) preventing unintended connections. Our draft
>>>>
>>>>
>>>>provides
>>>>
>>>>
>>>>>the problem statement of these issues.
>>>>>
>>>>>Hope this clarify the difference.
>>>>>Thank you for your interest.
>>>>>---
>>>>>Kohei
>>>>>
>>>>>
>>>>>
>>>>>>Shiomoto_san,
>>>>>>
>>>>>>Could you help us prepare for Vienna by summarizing the difference
>>>>>>between
>>>>>>your draft and
>>>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>>>>>>reference to the carrying of "extra traffic" on the resources of a
>>>>>>protection path in a mesh network.
>>>>>>
>>>>>>Thanks,
>>>>>>Adrian
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "Kohei Shiomoto" <[email-masked]>
>>>>>>To: <[email-masked]>
>>>>>>Sent: Tuesday, July 01, 2003 3:18 AM
>>>>>>Subject: New draft on Extra class LSP
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Sorry for the incorrect subject in the previous mail. I
>>>>>>
>>>>>>
>>>>resend it with a
>>>>
>>>>
>>>>>>>new subject.
>>>>>>>
>>>>>>>Hi, all
>>>>>>>
>>>>>>>Please notice that a new internet-draft has been posted. The
>>>>>>>draft is
>>>>>>>targeted at the IETF57 ccamp meeting. The draft is prepared
>>>>>>
>>>>>>
>>>>to initiate
>>>>
>>>>
>>>>>>>the discussion at the ccamp-wg on the extra class LSP service, which
>>>>>>>makes use of reserved but unallocated bandwidth for the
>>>>>>
>>>>>>
>>>>protecting LSPs
>>>>
>>>>
>>>>>>>in the pre-planned LSP re-routing recovery method (including
>>>>>>
>>>>>>
>>>>shared mesh
>>>>
>>>>
>>>>>>>restoration). Comments and feedbacks are highly appreciated.
>>>>>>>Thanks.
>>>>>>>-- 
>>>>>>>Kohei Shiomoto
>>>>>>>NTT Network Innovation Laboratories
>>>>>>>Phone +81 422 59 4402, Fax +81 422 59 6387
>>>>>>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>>>>>>
>>>>>>
>>>>------------------------------------------------------------------
>>>>--------
>>>>
>>>>
>>>>>>----------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Title : Extra class LSP service using protecting
>>>>>>
>>>>>>
>>>>resources in
>>>>
>>>>
>>>>>>>GMPLS networks
>>>>>>>Author(s) : K. Shimano et al.
>>>>>>>Filename : draft-pil-ccamp-extra-lsp-00.txt
>>>>>>>
>>>>>>>This document provides the problem statement on a extra class LSP
>>>>>>>ser-
>>>>>>>vice and addresses the issues. The extra class LSP uses the resource
>>>>>>>reserved but not allocated for the protecting LSPs in the
>>>>>>>pre-planned
>>>>>>>LSP re-routing without extra-traffic (including shared mesh)
>>>>>>>recovery
>>>>>>>method. Network utilization is improved because the resource
>>>>>>>reserved
>>>>>>>for the protecting LSPs are used for the extra class LSPs. The extra
>>>>>>>class LSP is preempted less frequently than the conventional
>>>>>>>priority
>>>>>>>mechanism using setup and holding priorities because the resource
>>>>>>>reserved for the protecting LSPs is allocated only if the working
>>>>>>>LSP
>>>>>>>fails, which is usually expected to rarely occur. This document pro-
>>>>>>>poses the extra class LSP service using the resource reserved but
>>>>>>>not
>>>>>>>allocated for the protecting LSP at the provisioning phase.
>>>>>>
>>>>>>
>>>>This docu-
>>>>
>>>>
>>>>>>>ment addresses the issues on the extra class LSP: (1)
>>>>>>>advertisement of
>>>>>>>available resource, (2) extra class LSP indication in
>>>>>>
>>>>>>
>>>>signaling message
>>>>
>>>>
>>>>>>>(3) extra class LSP preemption signaling, and (4) preventing
>>>>>>
>>>>>>
>>>>unintended
>>>>
>>>>
>>>>>>>connections.
>>>>>>>
>>>>>>>A URL for this Internet-Draft is:
>>>>>>>http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>-- 
>>>>Papadimitriou Dimitri
>>>>E-mail : [email-masked]
>>>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>>>E-mail : [email-masked]
>>>>Public : http://psg.com/~dpapadimitriou/
>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>Phone : +32 3 240-8491
>>>>
>>>>
>>>
>>>
>>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 04 Jul 2003 10:26:12 +0000
Date: Fri, 04 Jul 2003 12:23:07 +0200
From: [email-masked]
To: [email-masked]
Cc: Kohei Shiomoto <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

hi vishal

see inline

[snip]
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>Behalf Of [email-masked]
>>>>Sent: Thursday, July 03, 2003 2:45 AM
>>>>To: Kohei Shiomoto
>>>>Cc: Adrian Farrel; [email-masked]
>>>>Subject: Re: New draft on Extra class LSP
>>>>
>>>>
>>>>hi adrian, kohei,
>>>>
>>>>in the case of pre-planned re-routing without extra-traffic
>>>>the unallocated protecting resource can be used by other
>>>>(lower priority LSPs) at the condition that the resources
>>>>are preempted when the working LSP fails (hint: i wanted
>>>>to point out also that this should be obvious otherwise
>>>>there is no reason for having this "path protection only")
>>>
>>>
>>>Actually, I think the terminology choice "without extra-traffic"
>>>is a bit confusing. It wasn't clear how the document distinguishes
>>>between "extra traffic" and "low priority traffic that can be
>>>pre-empted"?
>>
>>it distinguishes between protection and (pre-planned) re-
>>routing, for the former it thus refers to protection with
>>extra-traffic & the latter re-routing without extra-traffic
>>(see also section 7.1 of the terminology doc.) 
> 
> 
> I'm a little unclear what you mean here. As far as I can tell,
> the terminology document uses the term "pre-planned LSP
> restoration" (Section 7.1 of terminology doc.)
> for the case when you have pre-planned rerouting
> *with extra-traffic.* 

pre-planned lsp restoration or pre-planned lsp re-routing
refers to the same things (termino i-d):

"7.1 Pre-planned LSP Restoration

    Also referred to as pre-planned LSP re-routing."

> Also, the definition of "extra-traffic" given earlier on in
> the terminology document, seems to imply that "pre-emptible
> low priority traffic" is precisely what extra-traffic is, whereas
> in your earlier response you seem to distinguish between
> the two.

come to the point please, "extra-traffic" is defined
section 4.2 of the terminology document and the use
of 1:1 lsp re-routing without extra-traffic (lsp) come
simply from the fact that the recovery lsp is not cross-
connected

>>since the
>>end-to-end association delivering path protection does not
>>allow to carry any extra-traffic, 
> 
> 
> I agree that for the case of end-to-end path *protection*
> it would be true that no extra-traffic is possible, by definition.
> But then this would be because the resources in that case are
> not only reserved, but also cross-connected. Thus, the issue
> of extra-traffic does not even arise there.

we say the same thing here.

>>now the fact that these
>>resources can be used for lower priority traffic boils us
>>down to the setup of low priority lsp (that may be thus
>>preempted) but this is not anymore a specific "p&r" issue
>>except the fact the trigger for this preemption is internal
>>to the network and not an external provisioning or config
>>event (but anyway an additional sentence here would more
>>than certainly not hurt)
> 
> 
> Actually, for path *protection*, this is a moot point, since
> no extra-traffic is possible there. Thus, the only case in which
> extra-traffic comes into play is when one has pre-planned
> restoration with extra-traffic. 

not true, 1:1 lsp protection allows for extra traffic
and is definitelly different from 1:1 lsp re-routing
in the latter case for the recovery lsp does not carry
extra-traffic, this is why and very logically it has
been referred to as 1:1 lsp re-routing without extra-
traffic (lsp), while in the former the lsp associated
to the recovery entity may carry extra_traffic

> (That is, resources are set
> aside for recovery, but are not cross-connected, thus allowing
> for the reserved capacity to be used by other "extra-traffic"
> LSPs (or low-priority pre-emptible LSPs).)
> <<snip>>
> 
>>>I endorse the need to focus seriously on the last point, since,
>>>if during dropping "extra traffic" or "low priority 
>>
>>pre-emptable traffic",
>>
>>>the intermediate nodes end up misconnecting traffic (even for a short
>>>while), it would be a real violation of SLAs. 
>>
>>well the issue i wanted to point out is that these lower priority
>>lsp's can be established outside of the scope of the p&r context
>>it refers to larger scope issue (*) - note that this misconnection
>>(as currently specified) does not occur for lsp protection with
>>extra-traffic (see section 7) or if you want the only reason for
>>preemption is protection switching that occurs only on and end-to
>>end basis
> 
> 
> Actually, I'm not sure one can have "LSP _protection_ with 
> extra-traffic," (and Section 7 doesn't seem to have that category)
> since in the case of protection, my understanding
> is that no additional signaling should be needed, which would
> imply that the backup resources are both reserved and cross-connected. 
> 
> What one could have is pre-planned LSP re-routing with extra-traffic,
> which is what I started the discussion with.

please re-read:
- for 1:1 lsp protection: section 6 of the termino and section 7 of
   the signaling i-d)
- for 1:1 lsp re-routing: section 7 of the termino and section 8 of
   the signaling i-d)

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 04 Jul 2003 01:55:34 +0000
Date: Fri, 04 Jul 2003 10:50:41 +0900
From: Kohei Shiomoto <[email-masked]>
To: [email-masked]
CC: [email-masked], Adrian Farrel <[email-masked]>, [email-masked], Kohei Shiomoto <[email-masked]>
Subject: Re: New draft on Extra class LSP

Hi, Dimitri,

In the extra LSP draft, we want to make clear distinction between lower
priority LSP and extra LSP.

Priority mechanism is used to differentiate the service quality for
working resource. The resource for working LSPs is contended by working
LSPs of different priority classes. Service quality is dependent on
traffic ratio of different priority classes; service quality of lower
priority LSP degrades if higher priority LSP request comes frequently.
Resource for protecting LSP in shared mesh restoration is preempted only
when the working LSP fails. Service quality does not depend on traffic
ratio of different priority class. We could define another service class
which does not depend on the traffic ratio of different priority class
by using resources for protecting LSP in shared mesh restoration.
Priority mechanism is used for service differentiation based on relative
traffic volume difference while extra LSP is preempted only when the
working LSP fails. So we should make distinction between lower priority
LSP and extra LSP.

Thanks.
--
Kohei

> hi vishal,
>
> see in-line...
>
> Vishal Sharma wrote:
>
>> Hi Dimitri,
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]On
>>> Behalf Of [email-masked]
>>> Sent: Thursday, July 03, 2003 2:45 AM
>>> To: Kohei Shiomoto
>>> Cc: Adrian Farrel; [email-masked]
>>> Subject: Re: New draft on Extra class LSP
>>>
>>>
>>> hi adrian, kohei,
>>>
>>> in the case of pre-planned re-routing without extra-traffic
>>> the unallocated protecting resource can be used by other
>>> (lower priority LSPs) at the condition that the resources
>>> are preempted when the working LSP fails (hint: i wanted
>>> to point out also that this should be obvious otherwise
>>> there is no reason for having this "path protection only")
>>
>>
>>
>> Actually, I think the terminology choice "without extra-traffic"
>> is a bit confusing. It wasn't clear how the document distinguishes
>> between "extra traffic" and "low priority traffic that can be
>> pre-empted"?
>
>
> it distinguishes between protection and (pre-planned) re-
> routing, for the former it thus refers to protection with
> extra-traffic & the latter re-routing without extra-traffic
> (see also section 7.1 of the terminology doc.) since the
> end-to-end association delivering path protection does not
> allow to carry any extra-traffic, now the fact that these
> resources can be used for lower priority traffic boils us
> down to the setup of low priority lsp (that may be thus
> preempted) but this is not anymore a specific "p&r" issue
> except the fact the trigger for this preemption is internal
> to the network and not an external provisioning or config
> event (but anyway an additional sentence here would more
> than certainly not hurt)
>
>>> and the below i-d points out specific aspects (that are
>>> covered "partially" by other gmpls i-d's) see below:
>>> - advertize the bandwidth: -> gmpls-routing (and bw acct)
>>> - extra class LSP indication in signaling message -> priority
>>> in (g)mpls signaling
>>> - extra class LSP preemption signaling -> PathErr with SR
>>> Flag and PathTear (to release the lower priority LSP)
>>> but this can be qualified here as an "hard preemption"
>>> mechanism
>>> - preventing unintended connections -> it is a transient
>>> behaviour that may occur at an intermediate node e.g.
>>> if the previous point is not used, and cross-connection
>>> is fully performed in the downstream direction
>>>
>>
>>
>> I endorse the need to focus seriously on the last point, since,
>> if during dropping "extra traffic" or "low priority pre-emptable
>> traffic",
>> the intermediate nodes end up misconnecting traffic (even for a short
>> while), it would be a real violation of SLAs. 
>
>
> well the issue i wanted to point out is that these lower priority
> lsp's can be established outside of the scope of the p&r context
> it refers to larger scope issue (*) - note that this misconnection
> (as currently specified) does not occur for lsp protection with
> extra-traffic (see section 7) or if you want the only reason for
> preemption is protection switching that occurs only on and end-to
> end basis
>
> (*) i refer here to the mpls mailing list discussion
>
> thanks,
> - dimitri.
>
>> I would suspect it
>> would make customer's with mission critical traffic (and their
>> service providers, implementing such a scheme) very uncomfortable to
>> know
>> that this is even a remote possibility! :-)
>>
>> -Vishal
>>
>>
>>
>>
>>> Kohei Shiomoto wrote:
>>>
>>>> Hi, Adrian
>>>>
>>>> In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
>>>> the shared mesh restoration is addressed. Extra traffic cannot be
>>>> carried because the protecting LSPs are not instantiated in shared
>>>> mesh
>>>> restoration networks. But the resource for the protecting LSPs are
>>>> reserved to back up the failure of primary LSPs. The reserved resource
>>>> could be allocated for extra traffic to enhance the network
>>>> utilization.
>>>>
>>>> The purpose of our draft is to initiate the discussion on how to
>>>> handle
>>>> extra class LSP using the reserved link resource for the
>>>
>>>
>>> protecting LSPs
>>>
>>>> while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
>>>
>>>
>>> addresses
>>>
>>>> the signaling of primary and protecting LSPs.
>>>>
>>>> Regarding extra class LSP, the following issues need to be addressed:
>>>> (1) advertisement of available resource for extra class LSP, (2) extra
>>>> class LSP indication in signaling message (3) extra class LSP
>>>
>>>
>>> preemption
>>>
>>>> signaling, and (4) preventing unintended connections. Our draft
>>>
>>>
>>> provides
>>>
>>>> the problem statement of these issues.
>>>>
>>>> Hope this clarify the difference.
>>>> Thank you for your interest.
>>>> ---
>>>> Kohei
>>>>
>>>>
>>>>> Shiomoto_san,
>>>>>
>>>>> Could you help us prepare for Vienna by summarizing the difference
>>>>> between
>>>>> your draft and
>>>>> draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>>>>> reference to the carrying of "extra traffic" on the resources of a
>>>>> protection path in a mesh network.
>>>>>
>>>>> Thanks,
>>>>> Adrian
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Kohei Shiomoto" <[email-masked]>
>>>>> To: <[email-masked]>
>>>>> Sent: Tuesday, July 01, 2003 3:18 AM
>>>>> Subject: New draft on Extra class LSP
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Sorry for the incorrect subject in the previous mail. I
>>>>>
>>>>>
>>> resend it with a
>>>
>>>>>> new subject.
>>>>>>
>>>>>> Hi, all
>>>>>>
>>>>>> Please notice that a new internet-draft has been posted. The
>>>>>> draft is
>>>>>> targeted at the IETF57 ccamp meeting. The draft is prepared
>>>>>
>>>>>
>>> to initiate
>>>
>>>>>> the discussion at the ccamp-wg on the extra class LSP service, which
>>>>>> makes use of reserved but unallocated bandwidth for the
>>>>>
>>>>>
>>> protecting LSPs
>>>
>>>>>> in the pre-planned LSP re-routing recovery method (including
>>>>>
>>>>>
>>> shared mesh
>>>
>>>>>> restoration). Comments and feedbacks are highly appreciated.
>>>>>> Thanks.
>>>>>> -- 
>>>>>> Kohei Shiomoto
>>>>>> NTT Network Innovation Laboratories
>>>>>> Phone +81 422 59 4402, Fax +81 422 59 6387
>>>>>> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>>>>>
>>>>>
>>> ------------------------------------------------------------------
>>> --------
>>>
>>>>>>
>>>>> ----------------------
>>>>>
>>>>>
>>>>>
>>>>>> Title : Extra class LSP service using protecting
>>>>>
>>>>>
>>> resources in
>>>
>>>>>> GMPLS networks
>>>>>> Author(s) : K. Shimano et al.
>>>>>> Filename : draft-pil-ccamp-extra-lsp-00.txt
>>>>>>
>>>>>> This document provides the problem statement on a extra class LSP
>>>>>> ser-
>>>>>> vice and addresses the issues. The extra class LSP uses the resource
>>>>>> reserved but not allocated for the protecting LSPs in the
>>>>>> pre-planned
>>>>>> LSP re-routing without extra-traffic (including shared mesh)
>>>>>> recovery
>>>>>> method. Network utilization is improved because the resource
>>>>>> reserved
>>>>>> for the protecting LSPs are used for the extra class LSPs. The extra
>>>>>> class LSP is preempted less frequently than the conventional
>>>>>> priority
>>>>>> mechanism using setup and holding priorities because the resource
>>>>>> reserved for the protecting LSPs is allocated only if the working
>>>>>> LSP
>>>>>> fails, which is usually expected to rarely occur. This document pro-
>>>>>> poses the extra class LSP service using the resource reserved but
>>>>>> not
>>>>>> allocated for the protecting LSP at the provisioning phase.
>>>>>
>>>>>
>>> This docu-
>>>
>>>>>> ment addresses the issues on the extra class LSP: (1)
>>>>>> advertisement of
>>>>>> available resource, (2) extra class LSP indication in
>>>>>
>>>>>
>>> signaling message
>>>
>>>>>> (3) extra class LSP preemption signaling, and (4) preventing
>>>>>
>>>>>
>>> unintended
>>>
>>>>>> connections.
>>>>>>
>>>>>> A URL for this Internet-Draft is:
>>>>>> http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Papadimitriou Dimitri
>>> E-mail : [email-masked]
>>> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>> E-mail : [email-masked]
>>> Public : http://psg.com/~dpapadimitriou/
>>> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>> Phone : +32 3 240-8491
>>>
>>>
>>
>>
>>
>
>

-- 
$B1vK\8xJ?(B
$BF|K\EE?.EEOC3t<02q<R!!L$Mh$M$C$H8&5f=j(B
$BEEOC!!(B0422-59-4402$B!!%U%!%C%/%9!!(B0422-59-6387
$B")(B180-8585$B!!El5~ETIpB"Ln;TNPD.(B3-9-11

Kohei Shiomoto, Ph.D
Senior Research Engineer, Supervisor
NTT Network Innovation Laboratories
Phone +81 422 59 4402, Fax +81 422 59 6387
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan

Delivery-date: Fri, 04 Jul 2003 01:38:34 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Thu, 3 Jul 2003 18:35:34 -0700

Hi Dimitri,

Thanks for the quick response. 

Pl. see some more comments in-line.

-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, July 03, 2003 3:13 PM
> To: [email-masked]
> Cc: Kohei Shiomoto; Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
> 
> 
> hi vishal,
> 
> see in-line...
> 
> Vishal Sharma wrote:
> > Hi Dimitri,
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]On
> >>Behalf Of [email-masked]
> >>Sent: Thursday, July 03, 2003 2:45 AM
> >>To: Kohei Shiomoto
> >>Cc: Adrian Farrel; [email-masked]
> >>Subject: Re: New draft on Extra class LSP
> >>
> >>
> >>hi adrian, kohei,
> >>
> >>in the case of pre-planned re-routing without extra-traffic
> >>the unallocated protecting resource can be used by other
> >>(lower priority LSPs) at the condition that the resources
> >>are preempted when the working LSP fails (hint: i wanted
> >>to point out also that this should be obvious otherwise
> >>there is no reason for having this "path protection only")
> > 
> > 
> > Actually, I think the terminology choice "without extra-traffic"
> > is a bit confusing. It wasn't clear how the document distinguishes
> > between "extra traffic" and "low priority traffic that can be
> > pre-empted"?
> 
> it distinguishes between protection and (pre-planned) re-
> routing, for the former it thus refers to protection with
> extra-traffic & the latter re-routing without extra-traffic
> (see also section 7.1 of the terminology doc.) 

I'm a little unclear what you mean here. As far as I can tell,
the terminology document uses the term "pre-planned LSP
restoration" (Section 7.1 of terminology doc.)
for the case when you have pre-planned rerouting
*with extra-traffic.* 

Also, the definition of "extra-traffic" given earlier on in
the terminology document, seems to imply that "pre-emptible
low priority traffic" is precisely what extra-traffic is, whereas
in your earlier response you seem to distinguish between
the two.

> since the
> end-to-end association delivering path protection does not
> allow to carry any extra-traffic, 

I agree that for the case of end-to-end path *protection*
it would be true that no extra-traffic is possible, by definition.
But then this would be because the resources in that case are
not only reserved, but also cross-connected. Thus, the issue
of extra-traffic does not even arise there.

> now the fact that these
> resources can be used for lower priority traffic boils us
> down to the setup of low priority lsp (that may be thus
> preempted) but this is not anymore a specific "p&r" issue
> except the fact the trigger for this preemption is internal
> to the network and not an external provisioning or config
> event (but anyway an additional sentence here would more
> than certainly not hurt)

Actually, for path *protection*, this is a moot point, since
no extra-traffic is possible there. Thus, the only case in which
extra-traffic comes into play is when one has pre-planned
restoration with extra-traffic. (That is, resources are set
aside for recovery, but are not cross-connected, thus allowing
for the reserved capacity to be used by other "extra-traffic"
LSPs (or low-priority pre-emptible LSPs).)

<<snip>>
> > 
> > I endorse the need to focus seriously on the last point, since,
> > if during dropping "extra traffic" or "low priority 
> pre-emptable traffic",
> > the intermediate nodes end up misconnecting traffic (even for a short
> > while), it would be a real violation of SLAs. 
> 
> well the issue i wanted to point out is that these lower priority
> lsp's can be established outside of the scope of the p&r context
> it refers to larger scope issue (*) - note that this misconnection
> (as currently specified) does not occur for lsp protection with
> extra-traffic (see section 7) or if you want the only reason for
> preemption is protection switching that occurs only on and end-to
> end basis

Actually, I'm not sure one can have "LSP _protection_ with 
extra-traffic," (and Section 7 doesn't seem to have that category)
since in the case of protection, my understanding
is that no additional signaling should be needed, which would
imply that the backup resources are both reserved and cross-connected. 

What one could have is pre-planned LSP re-routing with extra-traffic,
which is what I started the discussion with.

Delivery-date: Thu, 03 Jul 2003 23:29:34 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Thu, 3 Jul 2003 16:26:54 -0700

Hi Adrian,

Thanks a lot for your careful reading of the draft, and for
your comments.

Please see explanations in-line, and comments welcome!

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, July 02, 2003 7:57 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Vishal Sharma (E-mail 2)
> Subject: Re: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
>
>
> Hi,
>
> Two brief questions about this draft...
>
> 1. In section 3 you say
>
>    [Optional]: If the receiving node has activated one or more recovery
>    paths, it sends a RecoveryCompleteNotify message to either the egress
>    nodes of the recovery LSPs or to the NMS.  It continues sending
>    RecoveryCompleteNotify messages periodically until it receives a
>    RecoveryCompleteNotifyAck message or a timer to retry sending
>    expires.
>
>    ...Isn't this a change to the way LMP operates? That is, before this
>    message, LMP is a neighbor-to-neighbor protocol.

I think the thought here was merely that it would be nice to have some way
of
informing the NMS that a recovery action in response to a fault has
been completed. And, for that reason, it's just an optional action.

The draft currently does it using LMP extensions, merely for convenience
(which as you rightly observe requires an extension to LMP). However,
the recovering entity-to-NMS communication could, in fact,
be implemented pretty much using any of several communication mechanisms
that
the system designer and/or service provider deems appropriate.

We thought this was a useful function, but we're open to hearing
others' opinions about it.

> 2. Fault repair
>
>   I don't see anything in your draft that discusses fault repair. How
>   does the reporting node revoke its fault report?

The reporting node will invoke "fault repair" using normal channels
(possibly just the routing protocol in use in the network). This is
because the "fault repaired" info. isn't really time critical. It's
only purpose is to make sure (as you observe below) that repaired
resources don't remain stranded indefinitely.

I think the existing P&R drafts don't make explicit mention of
fault repair either, probably for this very reason. (They also assume,
like we do, that the "fault repair" indication is a background activity
that happens via normal channels.)

>   This would appear to be a requirement otherwise repaired
>   resources will never be made available again. I think that when
>   you add this function and add the necessary controls to ensure
>   that each node has the right state (fault or no fault) you will have
>   invented a link state protocol.

Based on the explanation above, we don't really see the need to add
this functionality to a fault notification protocol of the type proposed in
draft-rabbat-fault-notification-protocol-03.txt.
So fault notification retains it lightweight character, as desired.

>   At this point I don't see what LMP gives you that an existing
>   link-state protocol doesn't already deliver. Certainly the
>   speed of reporting of faults to every node in the network
>   will be lost once you have to prevent "thrash" of fault and
>   fault clear notifications.

Given that the "no fault" indication isn't time critical, as discussed
above, one still derives the benefit of lightweight fault notification
using LMP.

Some of the drawbacks of adapting a link-state routing protocol to
achieve such notification were discussed in the thread a few ago,
in response to Roberto Albenese's email (which also pointed out
the difficulty of scaling a signaling-based notification scheme
when there are multiple LSP/lambdas on a link, and they don't
share the same ingress/egress pairs, thus reducing the effectiveness
of bundling Notifys.)
See thread here:
http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00682.html
http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00683.html
http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00684.html

Finally, the "thrashing" you refer to would be an issue even in
signaling-based notification. If you send a Notify message to a
repair point and then learn that the fault has been repaired,
what does a detecting entity do? I think it pretty much allows
the recovery action to proceed.

The assumption here is that there is a fault correlation phase
preceding the notification phase. If the fault correlation fuction
determines that a fault has occured that requires the initiation of
a recovery action, I would think the action wouldn't really be
turned off midway. Rather, the recovery action would proceed, and,
upon learning of the fault repair (via normal channels), policy
would have to decide how to use the repaired resources.

>  In any case, it is not clear to me that
>   every node in the network needs rapid notification of faults -
>   only those nodes that constitute repair points for the LSPs
>   that used the failed resource need to know quickly and they
>   hear about the problem through a directed Notify message
>   that must propagate faster than any hop-by-hop protocol
>   can.

Actually, that's an interesting point, probably worth discussing.

The flooding-based notification ensures that the fault notification
gets to the repair point in the minimum number of hops. (The signaling-based
notification allows the message to follow the "shortest path" to the
repair point, where the shortest path is based on metrics for plain IP
routing, which don't necessarily ensure that it gets there in the least
number of hops; it only ensures that it gets there following the "shortest
path" per the applicable metrics.)

The second observation is that in shared mesh recovery, not only repair
points but all intermediate nodes along the recovery path need to learn
of the fault (so that they may reconfigure their cross-connects to carry
the working traffic coming down the recovery path).

Using signaling-based notification, this requires an additional 2 or 3 phase
handshake between the LSP end-points, which lengthens recovery time.
Additonally, there is the issue of scaling signaling when a large number
of LSPs are affected by a given fault (e.g. a fiber cut).

However, using controlled flooding-based notification, as proposed
in draft-rabbat, it is shown (in the draft) that by an adequate choice
of recovery paths, it's possible to ensure that all nodes along the
recovery path learn of the fault (on the working path) by the time the
end-nodes learn about it. This has two benefits: multiple nodes along
the recovery path that learn of the fault may reconfigure themselves in
parallel (saving time), and no additional handshaking is needed once the
repair
point learns of the fault.

And, of course there is the potential advantage that flooding allows for
(in the worst case) no more than one message per link per fault, whereas
signaling
will require (in the worst case) a number of messages equal to the no. of
LSPs to
be sent by the detecting entity to the LSP repair points.

Delivery-date: Thu, 03 Jul 2003 22:30:58 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Vishal Sharma \(E-mail 2\)'" <[email-masked]>
Subject: RE: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Thu, 3 Jul 2003 15:26:21 -0700

Hi Adrian,

Thanks for reading the draft. Please see comments inline.

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, July 02, 2003 7:57 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Vishal Sharma (E-mail 2)
> Subject: Re: I-D =
ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
>=20
> Hi,
>=20
> Two brief questions about this draft...
>=20
> 1. In section 3 you say
>=20
>    [Optional]: If the receiving node has activated one or more =
recovery
>    paths, it sends a RecoveryCompleteNotify message to either the =
egress
>    nodes of the recovery LSPs or to the NMS.  It continues sending
>    RecoveryCompleteNotify messages periodically until it receives a
>    RecoveryCompleteNotifyAck message or a timer to retry sending
>    expires.
>=20
>    ...Isn't this a change to the way LMP operates? That is, before =
this
>    message, LMP is a neighbor-to-neighbor protocol.

That is true. We did use LMP in our prototype testbed for these optional
messages to make the NMS aware that the recovery is complete, but that =
was
just because our NMS talked LMP.  As our draft discusses, this message =
is
specified as [optional], but we thought it would be good to have some =
kind
of communication to tell the NMS that the recovery was completed, since =
it
is aware of the fault at some point.
We do not advocate the use of LMP for this message and did not specify =
its
format in the draft for that reason.  We'll clarify that is in not an =
LMP
message in our next draft submission. If people think this message is =
not
needed, we could drop it altogether.

> 2. Fault repair
>=20
>   I don't see anything in your draft that discusses fault repair. How
>   does the reporting node revoke its fault report?
>=20
>   This would appear to be a requirement otherwise repaired
>   resources will never be made available again. I think that when
>   you add this function and add the necessary controls to ensure
>   that each node has the right state (fault or no fault) you will have
>   invented a link state protocol.
>=20

If I understand your point correctly, you are concerned about sending =
the
state -let's call it: "Fault Repaired"- as part of our protocol. We do =
not
think the "Fault repaired" is a time-critical message and it could be
propagated through the regular channels.  Ultimately, a policy issue =
could
decide what to do about a "Fault Repaired" message. This could involve
reactivating previously working paths, or keeping traffic on the =
activated
recovery paths.  Therefore, we use LMP for Fault Notification *only*.

>   At this point I don't see what LMP gives you that an existing
>   link-state protocol doesn't already deliver. Certainly the
>   speed of reporting of faults to every node in the network
>   will be lost once you have to prevent "thrash" of fault and
>   fault clear notifications.

I think this problem exists in all situations, whether you use signaling =
or
flooding. In the case of "fault clear" notifications using signaling, =
you
could send the message to the egress that has already started the =
activation
of the recovery path. Then the egress has to do something about it. I =
think
the best way to deal with it is to complete the activation process and =
look
at policy to decide what to do about a "Fault repaired" message. =20

> In any case, it is not clear to me that
>   every node in the network needs rapid notification of faults -
>   only those nodes that constitute repair points for the LSPs
>   that used the failed resource need to know quickly and they
>   hear about the problem through a directed Notify message
>   that must propagate faster than any hop-by-hop protocol
>   can.

I'm not sure about that. Your directed Notify message has to initiate
signaling on the recovery path, which would have to go on the path and =
back,
whereas a probably shorter route will exist between the detecting node =
and
the nodes on the recovery paths, leading to faster recovery.
In addition, assuming that you will have one or few Notify messages is =
not
going to work in a large mesh network:
1. recovery paths have to be calculated using whatever
protection/restoration algorithm which tries to increase network =
efficiency
2. they likely will have different egress points since they will be
protecting LSPs with differing ingress(es)/egress(es).

The assumption about lots of recovery paths being the same for the same
fiber fault is restrictive.

Please let me know if I understood you correctly.

> Adrian

Thanks,
Richard.

Delivery-date: Thu, 03 Jul 2003 22:15:10 +0000
Date: Fri, 04 Jul 2003 00:12:51 +0200
From: [email-masked]
To: [email-masked]
Cc: Kohei Shiomoto <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

hi vishal,

see in-line...

Vishal Sharma wrote:
> Hi Dimitri,
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of [email-masked]
>>Sent: Thursday, July 03, 2003 2:45 AM
>>To: Kohei Shiomoto
>>Cc: Adrian Farrel; [email-masked]
>>Subject: Re: New draft on Extra class LSP
>>
>>
>>hi adrian, kohei,
>>
>>in the case of pre-planned re-routing without extra-traffic
>>the unallocated protecting resource can be used by other
>>(lower priority LSPs) at the condition that the resources
>>are preempted when the working LSP fails (hint: i wanted
>>to point out also that this should be obvious otherwise
>>there is no reason for having this "path protection only")
> 
> 
> Actually, I think the terminology choice "without extra-traffic"
> is a bit confusing. It wasn't clear how the document distinguishes
> between "extra traffic" and "low priority traffic that can be
> pre-empted"?

it distinguishes between protection and (pre-planned) re-
routing, for the former it thus refers to protection with
extra-traffic & the latter re-routing without extra-traffic
(see also section 7.1 of the terminology doc.) since the
end-to-end association delivering path protection does not
allow to carry any extra-traffic, now the fact that these
resources can be used for lower priority traffic boils us
down to the setup of low priority lsp (that may be thus
preempted) but this is not anymore a specific "p&r" issue
except the fact the trigger for this preemption is internal
to the network and not an external provisioning or config
event (but anyway an additional sentence here would more
than certainly not hurt)

>>and the below i-d points out specific aspects (that are
>>covered "partially" by other gmpls i-d's) see below:
>>- advertize the bandwidth: -> gmpls-routing (and bw acct)
>>- extra class LSP indication in signaling message -> priority
>>   in (g)mpls signaling
>>- extra class LSP preemption signaling -> PathErr with SR
>>   Flag and PathTear (to release the lower priority LSP)
>>   but this can be qualified here as an "hard preemption"
>>   mechanism
>>- preventing unintended connections -> it is a transient
>>   behaviour that may occur at an intermediate node e.g.
>>   if the previous point is not used, and cross-connection
>>   is fully performed in the downstream direction
>>
> 
> 
> I endorse the need to focus seriously on the last point, since,
> if during dropping "extra traffic" or "low priority pre-emptable traffic",
> the intermediate nodes end up misconnecting traffic (even for a short
> while), it would be a real violation of SLAs. 

well the issue i wanted to point out is that these lower priority
lsp's can be established outside of the scope of the p&r context
it refers to larger scope issue (*) - note that this misconnection
(as currently specified) does not occur for lsp protection with
extra-traffic (see section 7) or if you want the only reason for
preemption is protection switching that occurs only on and end-to
end basis

(*) i refer here to the mpls mailing list discussion

thanks,
- dimitri.

> I would suspect it
> would make customer's with mission critical traffic (and their
> service providers, implementing such a scheme) very uncomfortable to know
> that this is even a remote possibility! :-)
> 
> -Vishal
> 
> 
> 
> 
>>Kohei Shiomoto wrote:
>>
>>>Hi, Adrian
>>>
>>>In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
>>>the shared mesh restoration is addressed. Extra traffic cannot be
>>>carried because the protecting LSPs are not instantiated in shared mesh
>>>restoration networks. But the resource for the protecting LSPs are
>>>reserved to back up the failure of primary LSPs. The reserved resource
>>>could be allocated for extra traffic to enhance the network utilization.
>>>
>>>The purpose of our draft is to initiate the discussion on how to handle
>>>extra class LSP using the reserved link resource for the
>>
>>protecting LSPs
>>
>>>while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
>>
>>addresses
>>
>>>the signaling of primary and protecting LSPs.
>>>
>>>Regarding extra class LSP, the following issues need to be addressed:
>>>(1) advertisement of available resource for extra class LSP, (2) extra
>>>class LSP indication in signaling message (3) extra class LSP
>>
>>preemption
>>
>>>signaling, and (4) preventing unintended connections. Our draft
>>
>>provides
>>
>>>the problem statement of these issues.
>>>
>>>Hope this clarify the difference.
>>>Thank you for your interest.
>>>---
>>>Kohei
>>>
>>>
>>>>Shiomoto_san,
>>>>
>>>>Could you help us prepare for Vienna by summarizing the difference
>>>>between
>>>>your draft and
>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>>>>reference to the carrying of "extra traffic" on the resources of a
>>>>protection path in a mesh network.
>>>>
>>>>Thanks,
>>>>Adrian
>>>>
>>>>----- Original Message -----
>>>>From: "Kohei Shiomoto" <[email-masked]>
>>>>To: <[email-masked]>
>>>>Sent: Tuesday, July 01, 2003 3:18 AM
>>>>Subject: New draft on Extra class LSP
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Sorry for the incorrect subject in the previous mail. I
>>>>
>>resend it with a
>>
>>>>>new subject.
>>>>>
>>>>>Hi, all
>>>>>
>>>>>Please notice that a new internet-draft has been posted. The draft is
>>>>>targeted at the IETF57 ccamp meeting. The draft is prepared
>>>>
>>to initiate
>>
>>>>>the discussion at the ccamp-wg on the extra class LSP service, which
>>>>>makes use of reserved but unallocated bandwidth for the
>>>>
>>protecting LSPs
>>
>>>>>in the pre-planned LSP re-routing recovery method (including
>>>>
>>shared mesh
>>
>>>>>restoration).  Comments and feedbacks are highly appreciated.
>>>>>Thanks.
>>>>>--
>>>>>Kohei Shiomoto
>>>>>NTT Network Innovation Laboratories
>>>>>Phone +81 422 59 4402, Fax +81 422 59 6387
>>>>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>>>>
>>>>
>>------------------------------------------------------------------
>>--------
>>
>>>>>
>>>>----------------------
>>>>
>>>>
>>>>
>>>>>   Title        : Extra class LSP service using protecting
>>>>
>>resources in
>>
>>>>>                  GMPLS networks
>>>>>   Author(s)    : K. Shimano et al.
>>>>>   Filename    : draft-pil-ccamp-extra-lsp-00.txt
>>>>>
>>>>>This document provides the problem statement on a extra class LSP ser-
>>>>>vice and addresses the issues.  The extra class LSP uses the resource
>>>>>reserved but not allocated for the protecting LSPs in the pre-planned
>>>>>LSP re-routing without extra-traffic (including shared mesh) recovery
>>>>>method.  Network utilization is improved because the resource reserved
>>>>>for the protecting LSPs are used for the extra class LSPs.  The extra
>>>>>class LSP is preempted less frequently than the conventional priority
>>>>>mechanism using setup and holding priorities because the resource
>>>>>reserved for the protecting LSPs is allocated only if the working LSP
>>>>>fails, which is usually expected to rarely occur.  This document pro-
>>>>>poses the extra class LSP service using the resource reserved but not
>>>>>allocated for the protecting LSP at the provisioning phase.
>>>>
>>This docu-
>>
>>>>>ment addresses the issues on the extra class LSP: (1) advertisement of
>>>>>available resource, (2) extra class LSP indication in
>>>>
>>signaling message
>>
>>>>>(3) extra class LSP preemption signaling, and (4) preventing
>>>>
>>unintended
>>
>>>>>connections.
>>>>>
>>>>>A URL for this Internet-Draft is:
>>>>>http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>>>>
>>>>
>>>
>>>
>>>
>>
>>--
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : [email-masked]
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
>>
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 03 Jul 2003 21:22:06 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, "Kohei Shiomoto" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: RE: New draft on Extra class LSP
Date: Thu, 3 Jul 2003 14:18:17 -0700

Hi Dimitri,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Thursday, July 03, 2003 2:45 AM
> To: Kohei Shiomoto
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: New draft on Extra class LSP
>
>
> hi adrian, kohei,
>
> in the case of pre-planned re-routing without extra-traffic
> the unallocated protecting resource can be used by other
> (lower priority LSPs) at the condition that the resources
> are preempted when the working LSP fails (hint: i wanted
> to point out also that this should be obvious otherwise
> there is no reason for having this "path protection only")

Actually, I think the terminology choice "without extra-traffic"
is a bit confusing. It wasn't clear how the document distinguishes
between "extra traffic" and "low priority traffic that can be
pre-empted"?

> and the below i-d points out specific aspects (that are
> covered "partially" by other gmpls i-d's) see below:
> - advertize the bandwidth: -> gmpls-routing (and bw acct)
> - extra class LSP indication in signaling message -> priority
>    in (g)mpls signaling
> - extra class LSP preemption signaling -> PathErr with SR
>    Flag and PathTear (to release the lower priority LSP)
>    but this can be qualified here as an "hard preemption"
>    mechanism
> - preventing unintended connections -> it is a transient
>    behaviour that may occur at an intermediate node e.g.
>    if the previous point is not used, and cross-connection
>    is fully performed in the downstream direction
>

I endorse the need to focus seriously on the last point, since,
if during dropping "extra traffic" or "low priority pre-emptable traffic",
the intermediate nodes end up misconnecting traffic (even for a short
while), it would be a real violation of SLAs. I would suspect it
would make customer's with mission critical traffic (and their
service providers, implementing such a scheme) very uncomfortable to know
that this is even a remote possibility! :-)

-Vishal

>
> Kohei Shiomoto wrote:
> > Hi, Adrian
> >
> > In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt,
> > the shared mesh restoration is addressed. Extra traffic cannot be
> > carried because the protecting LSPs are not instantiated in shared mesh
> > restoration networks. But the resource for the protecting LSPs are
> > reserved to back up the failure of primary LSPs. The reserved resource
> > could be allocated for extra traffic to enhance the network utilization.
> >
> > The purpose of our draft is to initiate the discussion on how to handle
> > extra class LSP using the reserved link resource for the
> protecting LSPs
> > while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
> addresses
> > the signaling of primary and protecting LSPs.
> >
> > Regarding extra class LSP, the following issues need to be addressed:
> > (1) advertisement of available resource for extra class LSP, (2) extra
> > class LSP indication in signaling message (3) extra class LSP
> preemption
> > signaling, and (4) preventing unintended connections. Our draft
> provides
> > the problem statement of these issues.
> >
> > Hope this clarify the difference.
> > Thank you for your interest.
> > ---
> > Kohei
> >
> >> Shiomoto_san,
> >>
> >> Could you help us prepare for Vienna by summarizing the difference
> >> between
> >> your draft and
> >> draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
> >> reference to the carrying of "extra traffic" on the resources of a
> >> protection path in a mesh network.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> ----- Original Message -----
> >> From: "Kohei Shiomoto" <[email-masked]>
> >> To: <[email-masked]>
> >> Sent: Tuesday, July 01, 2003 3:18 AM
> >> Subject: New draft on Extra class LSP
> >>
> >>
> >>
> >>
> >>> Sorry for the incorrect subject in the previous mail. I
> resend it with a
> >>> new subject.
> >>>
> >>> Hi, all
> >>>
> >>> Please notice that a new internet-draft has been posted. The draft is
> >>> targeted at the IETF57 ccamp meeting. The draft is prepared
> to initiate
> >>> the discussion at the ccamp-wg on the extra class LSP service, which
> >>> makes use of reserved but unallocated bandwidth for the
> protecting LSPs
> >>> in the pre-planned LSP re-routing recovery method (including
> shared mesh
> >>> restoration).  Comments and feedbacks are highly appreciated.
> >>> Thanks.
> >>> --
> >>> Kohei Shiomoto
> >>> NTT Network Innovation Laboratories
> >>> Phone +81 422 59 4402, Fax +81 422 59 6387
> >>> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> >>>
> ------------------------------------------------------------------
> --------
> >>>
> >>>
> >>
> >> ----------------------
> >>
> >>
> >>>    Title        : Extra class LSP service using protecting
> resources in
> >>>                   GMPLS networks
> >>>    Author(s)    : K. Shimano et al.
> >>>    Filename    : draft-pil-ccamp-extra-lsp-00.txt
> >>>
> >>> This document provides the problem statement on a extra class LSP ser-
> >>> vice and addresses the issues.  The extra class LSP uses the resource
> >>> reserved but not allocated for the protecting LSPs in the pre-planned
> >>> LSP re-routing without extra-traffic (including shared mesh) recovery
> >>> method.  Network utilization is improved because the resource reserved
> >>> for the protecting LSPs are used for the extra class LSPs.  The extra
> >>> class LSP is preempted less frequently than the conventional priority
> >>> mechanism using setup and holding priorities because the resource
> >>> reserved for the protecting LSPs is allocated only if the working LSP
> >>> fails, which is usually expected to rarely occur.  This document pro-
> >>> poses the extra class LSP service using the resource reserved but not
> >>> allocated for the protecting LSP at the provisioning phase.
> This docu-
> >>> ment addresses the issues on the extra class LSP: (1) advertisement of
> >>> available resource, (2) extra class LSP indication in
> signaling message
> >>> (3) extra class LSP preemption signaling, and (4) preventing
> unintended
> >>> connections.
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
> >>>
> >>
> >
> >
> >
> >
>
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
>
>

Delivery-date: Thu, 03 Jul 2003 16:07:14 +0000
content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-aboulmagd-ccamp-transport-lmp-01.txt
Date: Thu, 3 Jul 2003 11:02:55 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>

We've posted an updated version of the draft to align with the recently =
consented ITU G8080 Amendment and G7714.1. This informational draft =
provides an overview of LMP in the context of ITU's work on ASON and =
discovery with the objective to promote a common understanding for =
progressing the work of IETF and ITU.

We welcome comments and feedback to progress.

For USAers, happy 4th reading,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Thursday, July 03, 2003 11:29 AM
Subject: I-D ACTION:draft-aboulmagd-ccamp-transport-lmp-01.txt

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

	Title		: A Transport Network View to LMP
	Author(s)	: O. Aboul-Magd et al.
	Filename	: draft-aboulmagd-ccamp-transport-lmp-01.txt
	Pages		: 12
	Date		: 2003-7-3
=09
The Link Management Protocol (LMP) has bee defined at the IETF to=20
facilitate the management of transport network for the sake of=20
supporting IP traffic over transport network. The LMP development=20
has been progressing in the context of GMPLS related work.=20
The LMP was developed with a packet centric view in mind. Since it=20
is intended for the control of transport network it is essential to=20
bridge the gap between the two views. It is the objective of this=20
draft to project LMP in a transport network context and to relate it=20
to the discovery work that has been going on at the ITU.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-transport-lmp-0=
1.txt

To remove yourself from the IETF Announcement list, send a message to=20
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-aboulmagd-ccamp-transport-lmp-01.txt".

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

Delivery-date: Thu, 03 Jul 2003 09:47:28 +0000
Date: Thu, 03 Jul 2003 11:44:35 +0200
From: [email-masked]
To: Kohei Shiomoto <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: New draft on Extra class LSP

hi adrian, kohei,

in the case of pre-planned re-routing without extra-traffic
the unallocated protecting resource can be used by other
(lower priority LSPs) at the condition that the resources
are preempted when the working LSP fails (hint: i wanted
to point out also that this should be obvious otherwise
there is no reason for having this "path protection only")

and the below i-d points out specific aspects (that are
covered "partially" by other gmpls i-d's) see below:
- advertize the bandwidth: -> gmpls-routing (and bw acct)
- extra class LSP indication in signaling message -> priority
   in (g)mpls signaling
- extra class LSP preemption signaling -> PathErr with SR
   Flag and PathTear (to release the lower priority LSP)
   but this can be qualified here as an "hard preemption"
   mechanism
- preventing unintended connections -> it is a transient
   behaviour that may occur at an intermediate node e.g.
   if the previous point is not used, and cross-connection
   is fully performed in the downstream direction

i see this i-d as one good reason to initiate discussion
on gmpls "soft preemption" mechanisms (and the conditions
in which the last point may occur) because the scope is
larger than p&r

thanks,
- dimitri.

Kohei Shiomoto wrote:
> Hi, Adrian
> 
> In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt, 
> the shared mesh restoration is addressed. Extra traffic cannot be 
> carried because the protecting LSPs are not instantiated in shared mesh 
> restoration networks. But the resource for the protecting LSPs are 
> reserved to back up the failure of primary LSPs. The reserved resource 
> could be allocated for extra traffic to enhance the network utilization.
> 
> The purpose of our draft is to initiate the discussion on how to handle 
> extra class LSP using the reserved link resource for the protecting LSPs 
> while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt addresses 
> the signaling of primary and protecting LSPs.
> 
> Regarding extra class LSP, the following issues need to be addressed: 
> (1) advertisement of available resource for extra class LSP, (2) extra 
> class LSP indication in signaling message (3) extra class LSP preemption 
> signaling, and (4) preventing unintended connections. Our draft provides 
> the problem statement of these issues.
> 
> Hope this clarify the difference.
> Thank you for your interest.
> ---
> Kohei
> 
>> Shiomoto_san,
>>
>> Could you help us prepare for Vienna by summarizing the difference 
>> between
>> your draft and
>> draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>> reference to the carrying of "extra traffic" on the resources of a
>> protection path in a mesh network.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Kohei Shiomoto" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Tuesday, July 01, 2003 3:18 AM
>> Subject: New draft on Extra class LSP
>>
>>
>>  
>>
>>> Sorry for the incorrect subject in the previous mail. I resend it with a
>>> new subject.
>>>
>>> Hi, all
>>>
>>> Please notice that a new internet-draft has been posted. The draft is
>>> targeted at the IETF57 ccamp meeting. The draft is prepared to initiate
>>> the discussion at the ccamp-wg on the extra class LSP service, which
>>> makes use of reserved but unallocated bandwidth for the protecting LSPs
>>> in the pre-planned LSP re-routing recovery method (including shared mesh
>>> restoration).  Comments and feedbacks are highly appreciated.
>>> Thanks.
>>> -- 
>>> Kohei Shiomoto
>>> NTT Network Innovation Laboratories
>>> Phone +81 422 59 4402, Fax +81 422 59 6387
>>> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>> -------------------------------------------------------------------------- 
>>>
>>>   
>>
>> ----------------------
>>  
>>
>>>    Title        : Extra class LSP service using protecting resources in
>>>                   GMPLS networks
>>>    Author(s)    : K. Shimano et al.
>>>    Filename    : draft-pil-ccamp-extra-lsp-00.txt
>>>
>>> This document provides the problem statement on a extra class LSP ser-
>>> vice and addresses the issues.  The extra class LSP uses the resource
>>> reserved but not allocated for the protecting LSPs in the pre-planned
>>> LSP re-routing without extra-traffic (including shared mesh) recovery
>>> method.  Network utilization is improved because the resource reserved
>>> for the protecting LSPs are used for the extra class LSPs.  The extra
>>> class LSP is preempted less frequently than the conventional priority
>>> mechanism using setup and holding priorities because the resource
>>> reserved for the protecting LSPs is allocated only if the working LSP
>>> fails, which is usually expected to rarely occur.  This document pro-
>>> poses the extra class LSP service using the resource reserved but not
>>> allocated for the protecting LSP at the provisioning phase.  This docu-
>>> ment addresses the issues on the extra class LSP: (1) advertisement of
>>> available resource, (2) extra class LSP indication in signaling message
>>> (3) extra class LSP preemption signaling, and (4) preventing unintended
>>> connections.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>>   
>>
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 03 Jul 2003 01:31:03 +0000
Date: Thu, 03 Jul 2003 10:25:54 +0900
From: Kohei Shiomoto <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: New draft on Extra class LSP

Hi, Adrian

In Section 9 of draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt, 
the shared mesh restoration is addressed. Extra traffic cannot be 
carried because the protecting LSPs are not instantiated in shared mesh 
restoration networks. But the resource for the protecting LSPs are 
reserved to back up the failure of primary LSPs. The reserved resource 
could be allocated for extra traffic to enhance the network utilization.

The purpose of our draft is to initiate the discussion on how to handle 
extra class LSP using the reserved link resource for the protecting LSPs 
while the draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt addresses 
the signaling of primary and protecting LSPs.

Regarding extra class LSP, the following issues need to be addressed: 
(1) advertisement of available resource for extra class LSP, (2) extra 
class LSP indication in signaling message (3) extra class LSP preemption 
signaling, and (4) preventing unintended connections. Our draft provides 
the problem statement of these issues.

Hope this clarify the difference.
Thank you for your interest.
---
Kohei

>Shiomoto_san,
>
>Could you help us prepare for Vienna by summarizing the difference between
>your draft and
>draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
>reference to the carrying of "extra traffic" on the resources of a
>protection path in a mesh network.
>
>Thanks,
>Adrian
>
>----- Original Message -----
>From: "Kohei Shiomoto" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 01, 2003 3:18 AM
>Subject: New draft on Extra class LSP
>
>
>  
>
>>Sorry for the incorrect subject in the previous mail. I resend it with a
>>new subject.
>>
>>Hi, all
>>
>>Please notice that a new internet-draft has been posted. The draft is
>>targeted at the IETF57 ccamp meeting. The draft is prepared to initiate
>>the discussion at the ccamp-wg on the extra class LSP service, which
>>makes use of reserved but unallocated bandwidth for the protecting LSPs
>>in the pre-planned LSP re-routing recovery method (including shared mesh
>>restoration).  Comments and feedbacks are highly appreciated.
>>Thanks.
>>--
>>Kohei Shiomoto
>>NTT Network Innovation Laboratories
>>Phone +81 422 59 4402, Fax +81 422 59 6387
>>3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>>--------------------------------------------------------------------------
>>    
>>
>----------------------
>  
>
>>    Title        : Extra class LSP service using protecting resources in
>>                   GMPLS networks
>>    Author(s)    : K. Shimano et al.
>>    Filename    : draft-pil-ccamp-extra-lsp-00.txt
>>
>>This document provides the problem statement on a extra class LSP ser-
>>vice and addresses the issues.  The extra class LSP uses the resource
>>reserved but not allocated for the protecting LSPs in the pre-planned
>>LSP re-routing without extra-traffic (including shared mesh) recovery
>>method.  Network utilization is improved because the resource reserved
>>for the protecting LSPs are used for the extra class LSPs.  The extra
>>class LSP is preempted less frequently than the conventional priority
>>mechanism using setup and holding priorities because the resource
>>reserved for the protecting LSPs is allocated only if the working LSP
>>fails, which is usually expected to rarely occur.  This document pro-
>>poses the extra class LSP service using the resource reserved but not
>>allocated for the protecting LSP at the provisioning phase.  This docu-
>>ment addresses the issues on the extra class LSP: (1) advertisement of
>>available resource, (2) extra class LSP indication in signaling message
>>(3) extra class LSP preemption signaling, and (4) preventing unintended
>>connections.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt
>>    
>>

Delivery-date: Wed, 02 Jul 2003 22:13:39 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-06.txt
Date: Wed, 02 Jul 2003 18:10:04 -0400

--NextPart

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

	Title		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-routing-06.txt
	Pages		: 26
	Date		: 2003-7-2
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 02 Jul 2003 15:04:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Vishal Sharma \(E-mail 2\)" <[email-masked]>
Subject: Re: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Wed, 2 Jul 2003 15:57:08 +0100

Hi,

Two brief questions about this draft...

1. In section 3 you say

   [Optional]: If the receiving node has activated one or more recovery 
   paths, it sends a RecoveryCompleteNotify message to either the egress 
   nodes of the recovery LSPs or to the NMS.  It continues sending 
   RecoveryCompleteNotify messages periodically until it receives a 
   RecoveryCompleteNotifyAck message or a timer to retry sending 
   expires. 

   ...Isn't this a change to the way LMP operates? That is, before this
   message, LMP is a neighbor-to-neighbor protocol.

2. Fault repair

  I don't see anything in your draft that discusses fault repair. How
  does the reporting node revoke its fault report?

  This would appear to be a requirement otherwise repaired 
  resources will never be made available again. I think that when 
  you add this function and add the necessary controls to ensure 
  that each node has the right state (fault or no fault) you will have
  invented a link state protocol.

  At this point I don't see what LMP gives you that an existing
  link-state protocol doesn't already deliver. Certainly the 
  speed of reporting of faults to every node in the network 
  will be lost once you have to prevent "thrash" of fault and 
  fault clear notifications. In any case, it is not clear to me that
  every node in the network needs rapid notification of faults -
  only those nodes that constitute repair points for the LSPs 
  that used the failed resource need to know quickly and they 
  hear about the problem through a directed Notify message
  that must propagate faster than any hop-by-hop protocol
  can.

Adrian

Delivery-date: Wed, 02 Jul 2003 13:23:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Subject: Re: New draft on Extra class LSP
Date: Wed, 2 Jul 2003 14:10:51 +0100

Shiomoto_san,

Could you help us prepare for Vienna by summarizing the difference between
your draft and
draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt especially with
reference to the carrying of "extra traffic" on the resources of a
protection path in a mesh network.

Thanks,
Adrian

----- Original Message -----
From: "Kohei Shiomoto" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 01, 2003 3:18 AM
Subject: New draft on Extra class LSP

>
> Sorry for the incorrect subject in the previous mail. I resend it with a
> new subject.
>
> Hi, all
>
> Please notice that a new internet-draft has been posted. The draft is
> targeted at the IETF57 ccamp meeting. The draft is prepared to initiate
> the discussion at the ccamp-wg on the extra class LSP service, which
> makes use of reserved but unallocated bandwidth for the protecting LSPs
> in the pre-planned LSP re-routing recovery method (including shared mesh
> restoration).  Comments and feedbacks are highly appreciated.
> Thanks.
> --
> Kohei Shiomoto
> NTT Network Innovation Laboratories
> Phone +81 422 59 4402, Fax +81 422 59 6387
> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> --------------------------------------------------------------------------
----------------------
>     Title        : Extra class LSP service using protecting resources in
>                    GMPLS networks
>     Author(s)    : K. Shimano et al.
>     Filename    : draft-pil-ccamp-extra-lsp-00.txt
>
> This document provides the problem statement on a extra class LSP ser-
> vice and addresses the issues.  The extra class LSP uses the resource
> reserved but not allocated for the protecting LSPs in the pre-planned
> LSP re-routing without extra-traffic (including shared mesh) recovery
> method.  Network utilization is improved because the resource reserved
> for the protecting LSPs are used for the extra class LSPs.  The extra
> class LSP is preempted less frequently than the conventional priority
> mechanism using setup and holding priorities because the resource
> reserved for the protecting LSPs is allocated only if the working LSP
> fails, which is usually expected to rarely occur.  This document pro-
> poses the extra class LSP service using the resource reserved but not
> allocated for the protecting LSP at the provisioning phase.  This docu-
> ment addresses the issues on the extra class LSP: (1) advertisement of
> available resource, (2) extra class LSP indication in signaling message
> (3) extra class LSP preemption signaling, and (4) preventing unintended
> connections.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pil-ccamp-extra-lsp-00.txt

Delivery-date: Wed, 02 Jul 2003 10:52:31 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-01.txt
Date: Wed, 02 Jul 2003 06:50:27 -0400

--NextPart

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

	Title		: Requirements for Generalized MPLS (GMPLS) Usage and 
                          Extensions for Automatically Switched Optical Network 
                          (ASON)
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-01.txt
	Pages		: 12
	Date		: 2003-7-1
	
The Generalized MPLS (GMPLS) suite of protocol has been defined to
control different switching technologies as well as different
applications. These include support for requesting TDM connections
including SONET/SDH and Optical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies the features to be covered by the
GMPLS signalling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON). This document
provides a problem statement and additional requirements on the
GMPLS signaling protocol to support the ASON functionality.

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

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

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

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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-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: Tue, 01 Jul 2003 22:42:13 +0000
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Subject: Question re: status of two drafts
Date: Mon, 30 Jun 2003 21:12:28 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

I've been out of the loop for several months. Could somebody update me as to
the status of the following two drafts:

draft-ietf-mpls-lsp-hierarchy

draft-ietf-mpls-bundle

Thanks

Michael Mandelberg

Delivery-date: Tue, 01 Jul 2003 11:24:07 +0000
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt
Date: Tue, 01 Jul 2003 07:21:54 -0400

--NextPart

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

	Title		: Extensions to LMP for Flooding-based Fault 
                          Notification
	Author(s)	: T. Soumiya, R. Rabbat
	Filename	: draft-soumiya-lmp-fault-notification-ext-01.txt
	Pages		: 13
	Date		: 2003-6-30
	
This draft describes extensions to the Link Management Protocol (LMP) 
for use in flooding-based fault notification in optical networks.  We 
focus on networks that use a common control plane (e.g, Generalized 
Multi-Protocol Label Switching or GMPLS).  These extensions implement 
the Fault Notification Protocol, a flooding-based approach to 
notifying faults to nodes in the network.  We motivate the use of LMP 
extensions for flooding, define message formats and explain the 
communication messages that occur using LMP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-soumiya-lmp-fault-notification-ext-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-soumiya-lmp-fault-notification-ext-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-soumiya-lmp-fault-notification-ext-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-soumiya-lmp-fault-notification-ext-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-soumiya-lmp-fault-notification-ext-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: Tue, 01 Jul 2003 02:22:44 +0000
Date: Tue, 01 Jul 2003 11:18:00 +0900
From: Kohei Shiomoto <[email-masked]>
To: [email-masked]
Subject: New draft on Extra class LSP

Sorry for the incorrect subject in the previous mail. I resend it with a 
new subject.

Hi, all

Please notice that a new internet-draft has been posted. The draft is 
targeted at the IETF57 ccamp meeting. The draft is prepared to initiate 
the discussion at the ccamp-wg on the extra class LSP service, which 
makes use of reserved but unallocated bandwidth for the protecting LSPs 
in the pre-planned LSP re-routing recovery method (including shared mesh 
restoration).  Comments and feedbacks are highly appreciated.
Thanks.
-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
Phone +81 422 59 4402, Fax +81 422 59 6387
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan

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

    Title        : Extra class LSP service using protecting resources in
                   GMPLS networks
    Author(s)    : K. Shimano et al.
    Filename    : draft-pil-ccamp-extra-lsp-00.txt
    Pages        : 8
    Date        : 2003-6-27
    
This document provides the problem statement on a extra class LSP ser-
vice and addresses the issues.  The extra class LSP uses the resource
reserved but not allocated for the protecting LSPs in the pre-planned
LSP re-routing without extra-traffic (including shared mesh) recovery
method.  Network utilization is improved because the resource reserved
for the protecting LSPs are used for the extra class LSPs.  The extra
class LSP is preempted less frequently than the conventional priority
mechanism using setup and holding priorities because the resource
reserved for the protecting LSPs is allocated only if the working LSP
fails, which is usually expected to rarely occur.  This document pro-
poses the extra class LSP service using the resource reserved but not
allocated for the protecting LSP at the provisioning phase.  This docu-
ment addresses the issues on the extra class LSP: (1) advertisement of
available resource, (2) extra class LSP indication in signaling message
(3) extra class LSP preemption signaling, and (4) preventing unintended
connections.

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

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

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

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

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

Delivery-date: Tue, 01 Jul 2003 01:42:21 +0000
Date: Tue, 01 Jul 2003 10:36:35 +0900
From: Kohei Shiomoto <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto  Proposed Standard

Hi, all

Please notice that a new internet-draft has been posted. The draft is 
targeted at the IETF57 ccamp meeting. The draft is prepared to initiate 
the discussion at the ccamp-wg on the extra class LSP service, which 
makes use of reserved but unallocated bandwidth for the protecting LSPs 
in the pre-planned LSP re-routing recovery method (including shared mesh 
restoration).  Comments and feedbacks are highly appreciated.
Thanks.
-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
Phone +81 422 59 4402, Fax +81 422 59 6387
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan

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

	Title		: Extra class LSP service using protecting resources in 
                          GMPLS networks
	Author(s)	: K. Shimano et al.
	Filename	: draft-pil-ccamp-extra-lsp-00.txt
	Pages		: 8
	Date		: 2003-6-27
	
This document provides the problem statement on a extra class LSP ser-
vice and addresses the issues.  The extra class LSP uses the resource
reserved but not allocated for the protecting LSPs in the pre-planned
LSP re-routing without extra-traffic (including shared mesh) recovery
method.  Network utilization is improved because the resource reserved
for the protecting LSPs are used for the extra class LSPs.  The extra
class LSP is preempted less frequently than the conventional priority
mechanism using setup and holding priorities because the resource
reserved for the protecting LSPs is allocated only if the working LSP
fails, which is usually expected to rarely occur.  This document pro-
poses the extra class LSP service using the resource reserved but not
allocated for the protecting LSP at the provisioning phase.  This docu-
ment addresses the issues on the extra class LSP: (1) advertisement of
available resource, (2) extra class LSP indication in signaling message
(3) extra class LSP preemption signaling, and (4) preventing unintended
connections.

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

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

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

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

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