Subject: Question about logical link in Link bundling
From: "Fong, Man Wing" <[email-masked]>
To: [email-masked], 'Kireeti Kompella' <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Apr 2001 14:30:38 -0500

Hi All,

>From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links
between two LSRs can be bundled as a single link to improve the routing
scalability. Apparently, it can be used to bundle multiple links from
multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
etc...) to be a single link. However, can it be used to bundle logical links
like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface?

Thanks.

Regards,
Man Wing

Delivery-date: Wed, 25 Apr 2001 16:35:37 -0700
From: "Don Fedyk" <[email-masked]>
To: manoj juneja <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp  -modify-03.txt"
Date: Wed, 25 Apr 2001 19:34:10 -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_01C0CDE0.3ACBFF70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Manoj

This thread has gone full circle. Just because the draft is=20
most useful for CR strictly routed LSPs does not mean it is=20
harmful to loose LSPs.=20
If it were up to me I would put a question any wide spread use of
loose LSPs. These LSPs are operational headaches. The more=20
you add the more provisioning you have to change should=20
your network change. One of the benefits of the modify draft=20
was to make CR strictly routed LSPs less of a an operational=20
headache and an even better option than loose LSPs.
But the question is the draft only applicable to Strict LSPs?
My answer is no in fact if you wanted to modify the explicit=20
part of a strictly LSP this feature would work and must work without
any race conditions (which was the original objection).=20

Any implementation of the modify will have a knob to turn on=20
or off the modify so if you don't want the feature don't use it.

Don

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 6:33 PM
> To: [email-masked]; [email-masked]
> Cc: Fedyk, Don [BL60:2868:EXCH]; [email-masked]; [email-masked]
> Subject: Re: Valid Race Condition related to draft
> "draft-ietf-mpls-crlsp -modify-03.txt"
>=20
>=20
> Hi Don/Loa/Prem,
>=20
>        Today we got the mail of making the draft=20
> "draft-ietf-mpls-crlsp=20
> -modify-03.txt" as a proposed standard. Should not you people=20
> feel that the=20
> restriction that modification of CR-LSP is only applicable to=20
> strictly=20
> routed hops should be addressed in the draft prior to making=20
> it as a RFC. I=20
> think this is a major restriction and should be addressed in=20
> the scope of=20
> the document.
>=20
> Regards,
> manoj.
>=20
>=20
>=20
>=20
> >From: "Loa Andersson" <[email-masked]>
> >To: "Sharma Prem" <[email-masked]>
> >CC: 'Don Fedyk' <[email-masked]>,  manoj juneja=20
> ><[email-masked]>, [email-masked]
> >Subject: Re: Valid Race Condition related to draft=20
> "draft-ietf-mpls-crlsp=20
> >-modify-03.txt"
> >Date: Mon, 23 Apr 2001 13:05:32 +0200
> >
> >All,
> >
> >some comments to this discussion.
> >
> >I agree with Perm, if the draft is only applicable to LSPs=20
> where every
> >node is explicitly routed, that needs to be explicitly state early =
in
> >the draft. Also know from some offsets communication that "the
> >explicit routed only" approach  is under some debate.
> >
> >Given that we can have LSPs where other constraints are important, I
> >would
> >be interested in combining dynamic routed CR-LSPs (routed on other
> >constraints than explicit nodes), with one explicitly routed node,
> >e.g. for performance measurements. I would also be interested to be
> >able to make those  measurements at different places, a reason for
> >changing (modifying) the LSP, drop one explicitly routed node and
> >replace with another.
> >
> >I'm not concerned over have the loosely routed part of an LSP =
staying
> >alive of the strictly routed part goes away :-), but given that I =
can
> >retry if the a node in the loosely routed part of the LSP NAK a
> >request,
> >but not if an explicitly routed node does it. Need to distinguish
> >between
> >cases. Of course this is not a problem if explicit routed only.
> >
> >It is not only CR-LDP that sets up CR-LSPs, it is much more common =
to
> >do so by RSVP-TE, hence my reflection on the need to something for
> >RSVP-TE.
> >
> >/Loa
> >
> >
> >
> >--
> >Loa Andersson
> >Chief Architect,
> >Utfors Research, Architecture and Future Lab (URAX)
> >Utfors AB
> >R=E5sundav=E4gen 12
> >Box 525, 169 29 Solna
> >Office          +46 8 5270 2000
> >Office direct   +46 8 5270 5038
> >Mobile          +46 70 848 5038
> >Email           [email-masked]
> >WWW             www.utfors.se
>=20
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>=20
>=20
>=20

------_=_NextPart_001_01C0CDE0.3ACBFF70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: Valid Race Condition related to draft &quot;draft-ietf-mpls-crlsp  -modify-03.txt&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Manoj</FONT>
</P>

<P><FONT SIZE=2>This thread has gone full circle. Just because the draft is </FONT>
<BR><FONT SIZE=2>most useful for CR strictly routed LSPs does not mean it is </FONT>
<BR><FONT SIZE=2>harmful to loose LSPs. </FONT>
<BR><FONT SIZE=2>If it were up to me I would put a question any wide spread use of</FONT>
<BR><FONT SIZE=2>loose LSPs. These LSPs are operational headaches. The more </FONT>
<BR><FONT SIZE=2>you add the more provisioning you have to change should </FONT>
<BR><FONT SIZE=2>your network change. One of the benefits of the modify draft </FONT>
<BR><FONT SIZE=2>was to make CR strictly routed LSPs less of a an operational </FONT>
<BR><FONT SIZE=2>headache and an even better option than loose LSPs.</FONT>
<BR><FONT SIZE=2>But the question is the draft only applicable to Strict LSPs?</FONT>
<BR><FONT SIZE=2>My answer is no in fact if you wanted to modify the explicit </FONT>
<BR><FONT SIZE=2>part of a strictly LSP this feature would work and must work without</FONT>
<BR><FONT SIZE=2>any race conditions (which was the original objection). </FONT>
</P>

<P><FONT SIZE=2>Any implementation of the modify will have a knob to turn on </FONT>
<BR><FONT SIZE=2>or off the modify so if you don't want the feature don't use it.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: manoj juneja [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, April 25, 2001 6:33 PM</FONT>
<BR><FONT SIZE=2>&gt; To: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Fedyk, Don [BL60:2868:EXCH]; [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Valid Race Condition related to draft</FONT>
<BR><FONT SIZE=2>&gt; &quot;draft-ietf-mpls-crlsp -modify-03.txt&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Don/Loa/Prem,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Today we got the mail of making the draft </FONT>
<BR><FONT SIZE=2>&gt; &quot;draft-ietf-mpls-crlsp </FONT>
<BR><FONT SIZE=2>&gt; -modify-03.txt&quot; as a proposed standard. Should not you people </FONT>
<BR><FONT SIZE=2>&gt; feel that the </FONT>
<BR><FONT SIZE=2>&gt; restriction that modification of CR-LSP is only applicable to </FONT>
<BR><FONT SIZE=2>&gt; strictly </FONT>
<BR><FONT SIZE=2>&gt; routed hops should be addressed in the draft prior to making </FONT>
<BR><FONT SIZE=2>&gt; it as a RFC. I </FONT>
<BR><FONT SIZE=2>&gt; think this is a major restriction and should be addressed in </FONT>
<BR><FONT SIZE=2>&gt; the scope of </FONT>
<BR><FONT SIZE=2>&gt; the document.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; manoj.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;From: &quot;Loa Andersson&quot; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;To: &quot;Sharma Prem&quot; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;CC: 'Don Fedyk' &lt;[email-masked]&gt;,&nbsp; manoj juneja </FONT>
<BR><FONT SIZE=2>&gt; &gt;&lt;[email-masked]&gt;, [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; &gt;Subject: Re: Valid Race Condition related to draft </FONT>
<BR><FONT SIZE=2>&gt; &quot;draft-ietf-mpls-crlsp </FONT>
<BR><FONT SIZE=2>&gt; &gt;-modify-03.txt&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Date: Mon, 23 Apr 2001 13:05:32 +0200</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;All,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;some comments to this discussion.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;I agree with Perm, if the draft is only applicable to LSPs </FONT>
<BR><FONT SIZE=2>&gt; where every</FONT>
<BR><FONT SIZE=2>&gt; &gt;node is explicitly routed, that needs to be explicitly state early in</FONT>
<BR><FONT SIZE=2>&gt; &gt;the draft. Also know from some offsets communication that &quot;the</FONT>
<BR><FONT SIZE=2>&gt; &gt;explicit routed only&quot; approach&nbsp; is under some debate.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Given that we can have LSPs where other constraints are important, I</FONT>
<BR><FONT SIZE=2>&gt; &gt;would</FONT>
<BR><FONT SIZE=2>&gt; &gt;be interested in combining dynamic routed CR-LSPs (routed on other</FONT>
<BR><FONT SIZE=2>&gt; &gt;constraints than explicit nodes), with one explicitly routed node,</FONT>
<BR><FONT SIZE=2>&gt; &gt;e.g. for performance measurements. I would also be interested to be</FONT>
<BR><FONT SIZE=2>&gt; &gt;able to make those&nbsp; measurements at different places, a reason for</FONT>
<BR><FONT SIZE=2>&gt; &gt;changing (modifying) the LSP, drop one explicitly routed node and</FONT>
<BR><FONT SIZE=2>&gt; &gt;replace with another.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;I'm not concerned over have the loosely routed part of an LSP staying</FONT>
<BR><FONT SIZE=2>&gt; &gt;alive of the strictly routed part goes away :-), but given that I can</FONT>
<BR><FONT SIZE=2>&gt; &gt;retry if the a node in the loosely routed part of the LSP NAK a</FONT>
<BR><FONT SIZE=2>&gt; &gt;request,</FONT>
<BR><FONT SIZE=2>&gt; &gt;but not if an explicitly routed node does it. Need to distinguish</FONT>
<BR><FONT SIZE=2>&gt; &gt;between</FONT>
<BR><FONT SIZE=2>&gt; &gt;cases. Of course this is not a problem if explicit routed only.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;It is not only CR-LDP that sets up CR-LSPs, it is much more common to</FONT>
<BR><FONT SIZE=2>&gt; &gt;do so by RSVP-TE, hence my reflection on the need to something for</FONT>
<BR><FONT SIZE=2>&gt; &gt;RSVP-TE.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;/Loa</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;--</FONT>
<BR><FONT SIZE=2>&gt; &gt;Loa Andersson</FONT>
<BR><FONT SIZE=2>&gt; &gt;Chief Architect,</FONT>
<BR><FONT SIZE=2>&gt; &gt;Utfors Research, Architecture and Future Lab (URAX)</FONT>
<BR><FONT SIZE=2>&gt; &gt;Utfors AB</FONT>
<BR><FONT SIZE=2>&gt; &gt;Råsundavägen 12</FONT>
<BR><FONT SIZE=2>&gt; &gt;Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=2>&gt; &gt;Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 2000</FONT>
<BR><FONT SIZE=2>&gt; &gt;Office direct&nbsp;&nbsp; +46 8 5270 5038</FONT>
<BR><FONT SIZE=2>&gt; &gt;Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 70 848 5038</FONT>
<BR><FONT SIZE=2>&gt; &gt;Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; &gt;WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; www.utfors.se</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _________________________________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Get your FREE download of MSN Explorer at <A HREF="http://explorer.msn.com" TARGET="_blank">http://explorer.msn.com</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CDE0.3ACBFF70--

Delivery-date: Wed, 25 Apr 2001 15:35:13 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt"
Date: Wed, 25 Apr 2001 15:33:07 -0700

Hi Don/Loa/Prem,

       Today we got the mail of making the draft "draft-ietf-mpls-crlsp 
-modify-03.txt" as a proposed standard. Should not you people feel that the 
restriction that modification of CR-LSP is only applicable to strictly 
routed hops should be addressed in the draft prior to making it as a RFC. I 
think this is a major restriction and should be addressed in the scope of 
the document.

Regards,
manoj.

>From: "Loa Andersson" <[email-masked]>
>To: "Sharma Prem" <[email-masked]>
>CC: 'Don Fedyk' <[email-masked]>,  manoj juneja 
><[email-masked]>, [email-masked]
>Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp 
>-modify-03.txt"
>Date: Mon, 23 Apr 2001 13:05:32 +0200
>
>All,
>
>some comments to this discussion.
>
>I agree with Perm, if the draft is only applicable to LSPs where every
>node is explicitly routed, that needs to be explicitly state early in
>the draft. Also know from some offsets communication that "the
>explicit routed only" approach  is under some debate.
>
>Given that we can have LSPs where other constraints are important, I
>would
>be interested in combining dynamic routed CR-LSPs (routed on other
>constraints than explicit nodes), with one explicitly routed node,
>e.g. for performance measurements. I would also be interested to be
>able to make those  measurements at different places, a reason for
>changing (modifying) the LSP, drop one explicitly routed node and
>replace with another.
>
>I'm not concerned over have the loosely routed part of an LSP staying
>alive of the strictly routed part goes away :-), but given that I can
>retry if the a node in the loosely routed part of the LSP NAK a
>request,
>but not if an explicitly routed node does it. Need to distinguish
>between
>cases. Of course this is not a problem if explicit routed only.
>
>It is not only CR-LDP that sets up CR-LSPs, it is much more common to
>do so by RSVP-TE, hence my reflection on the need to something for
>RSVP-TE.
>
>/Loa
>
>
>
>--
>Loa Andersson
>Chief Architect,
>Utfors Research, Architecture and Future Lab (URAX)
>Utfors AB
>Råsundavägen 12
>Box 525, 169 29 Solna
>Office          +46 8 5270 2000
>Office direct   +46 8 5270 5038
>Mobile          +46 70 848 5038
>Email           [email-masked]
>WWW             www.utfors.se

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 25 Apr 2001 15:29:32 -0700
Date: Wed, 25 Apr 2001 14:59:03 -0700
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Route Pinning Doubt

Manoj,

One application of route pinning I know of being used is following:

* Establishment of TE-LSPs with dynamic path options (ERO calculated on
the headends with cspf)
* Recording the routes from RROs (route pinning)
* Setting explicit TE-LSPs with the recorded EROs.

I don't know of any use of signalled "route pinning" as you are
describing below.

R.

> manoj juneja wrote:
> 
> Hi All,
>         Is anybody using Route Pinning in the MPLS network ? If yes, what
> are the benefits of using route pinning ?
> Is route pinning applicable once the CR-LSP gets established ?
> 
> Following is my understanding regarding Route pinning :
> 
> Please correct me if I am wrong.
> 
> Once the LSP gets established and then afterwards if better nexthop
> becomes available and route pinning is requested along the path, u don't
> change the CR-LSP path (only the loosely routed portion of LSP).
> 
> Is the nexthop change procedure same for both LSP and CR-LSP ?
> 
> Is there any option in LDP that once a LSP gets established and subsequent
> better next-hop changes should be rejected (like route pinning in LDP
> inaddition to CR-LDP)?
> 
> Thanks,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 25 Apr 2001 11:20:35 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Route Pinning Doubt
Date: Wed, 25 Apr 2001 11:15:37 -0700

Hi All,
        Is anybody using Route Pinning in the MPLS network ? If yes, what 
are the benefits of using route pinning ?
Is route pinning applicable once the CR-LSP gets established ?

Following is my understanding regarding Route pinning :

Please correct me if I am wrong.

Once the LSP gets established and then afterwards if better nexthop
becomes available and route pinning is requested along the path, u don't 
change the CR-LSP path (only the loosely routed portion of LSP).

Is the nexthop change procedure same for both LSP and CR-LSP ?

Is there any option in LDP that once a LSP gets established and subsequent 
better next-hop changes should be rejected (like route pinning in LDP 
inaddition to CR-LDP)?

Thanks,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 24 Apr 2001 18:10:19 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Fwd: Re: new rev of GMPLS signaling I-Ds
Date: Tue, 24 Apr 2001 18:08:08 -0700

Hi Lou,
           I have gone through the 
draft-ietf-mpls-generalized-signaling-03.txt and 
draft-ietf-mpls-generalized-cr-ldp-02.txt drafts. I have certain 
clarifications on these drafts. Following are my doubts :

1. In draft "draft-ietf-mpls-generalized-signaling-03.txt", u
mentioned that there will be a separate draft GMPLS-SONET for describing the 
technology specific details. U have removed just the TDM related details in 
that draft.
The WDM specific label formats are still in the draft. Should not the 
waveband and lamda specific details and their label formats need to be in 
seprate draft like GMPLS-WDM. I mean to say why not put waveband label 
format in some other draft like GMPLS-WDM.

2.  It is mentioned in the draft that label set may be either restricted to 
a single hop or the whole LSP path. Can u please clarify that this decision 
should be based on what criteria or it is just a local node decision.

3. It is mentioned that LSP characteristics may be used by transit nodes
e.g. to support PHP (section 3.1). Can u please explain how ? Is
this case only possible in PSC ?

4. In section 3.1.1, it is written that lambda encoding type refers
to switching of wavelengths. Does it also include the waveband ? Why there 
is not a separate LSP encoding type as waveband ? How does a transit node 
can identify that a waveband label is requested instead of a lambda label ?

5.  Are people more stressing on SDH/SONET in GMPLS area ?

6. In section 3.3.1, it is mentioned that waveband Id is selected by
the sender and reused in all subsequent related messages. Can u please
clarify that what are all those subsequent messages ?

7. In section 3.5, four different cases are explained where the
label set concept may be useful. Can u please calrify the 4th case further ?

8. Is waveband Id locally signifcant i.e. between the two adjacent
nodes or is it globally unique for whole LSP path ?

9. Can the generalized label TLV be present in Label
Release/Withdraw messages ?

10. Is there any new draft coming on O-UNI ?

11. Is anybody defining the clear interworking on O-UNI and GMPLS ?

12. In section 5, it is mentioned that acceptable label set may be
present in notification message to indicate what all labels are acceptable ?
Can u please clarify what actions a node have to take once it receives the 
notification message with acceptable label set ?

Please help me in understanding these drafts.

Thanks,
manoj.

>>From: Lou Berger <[email-masked]>
>>To: [email-masked],[email-masked]
>>Subject: new rev of GMPLS signaling I-Ds
>>Date: Tue, 17 Apr 2001 17:12:17 -0400
>>
>>All,
>>         It looks like the I-D folks are out (and not publishing) for a 
>>few
>>days.  For those interested updated versions of the generalized signaling
>>docs, they are available at:
>>
>>http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt
>>http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt
>>http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt
>>
>>Per the last IETF, these drafts don't include SONET/SDH specifics.  A new
>>draft covering the specifics will be published in a few days.
>>
>>Lou (and co-authors)
>>
>>>Subject: Autoreply from Internet Draft Submission Manager
>>>From: [email-masked] (Internet Draft Submission Manager)
>>>
>>>Hello,
>>>
>>>This message is being sent to acknowledge receipt of your submission
>>>or message to [email-masked]
>>>
>>>The I-D administrator will be out of the office until Monday,
>>>April 23rd. All submissions will be processed.
>>>
>>>Thank you. We appreciate your understanding and patience.
>>
>>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 23 Apr 2001 09:04:21 -0700
Date: Mon, 23 Apr 2001 09:04:05 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: "Metz, Eduard" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-gan-fast-reroute-00.txt

"Metz, Eduard" wrote:
>
> The FAST-REROUTE object includes several parameters for the detour LSP, such
> as bandwidth, and include/exclude colors. Are these completely independent
> of those for the primary LSP? Or are these supposed to have a relation?
>

They could be independent. For example, the operators may decide to
allocate less bandwidth to the backup LSP's. On the other hand, the
FAST-REROUTE parameters could be the same the one used in the primary
LSP's. We want to provide alternative options here.
 
> The DETOUR object includes Downstream Node ID, identifying the neighboring
> node to route around. This seems to work for all hops, except the
> penultimate. Here the detour only can protect the link, also shown in the
> picture in section 2. Should there be an exception for this case, or does
> the penultimate hop apply different logic when setting up the detour?
> 

The downstream ID is one of the nodes at downstream from the router,
which could be multiple hops and links away. Of course you can also use
it to protect one link. The logic used at a penultimate hop is the same
as all others.

Thanks!

- Ping

> cheers,
>         Eduard

Delivery-date: Mon, 23 Apr 2001 09:04:21 -0700
Date: Mon, 23 Apr 2001 09:05:11 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: Nhat Thanh Hoang <[email-masked]>
CC: "'Metz, Eduard'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-gan-fast-reroute-00.txt

Nhat Thanh Hoang wrote:
> 
> See the comments in line
> Hi all,
> 
> some questions on draft-gan-fast-reroute:
> 
> The FAST-REROUTE object includes several parameters for the detour LSP, such
> as bandwidth, and include/exclude colors. Are these completely independent
> of those for the primary LSP? Or are these supposed to have a relation?
> 
> - In the defaut mode, the detour LSPs inherit the constraints from the
> primary LSPs, but the network administrator can change the relation. If I'm
> not wrong.
> 

Exactly. Better than what I said. ;-) Thanks!

- Ping

> Cheers,
> 
> Nhat Thanh
> 
> Telia Research AB

Delivery-date: Mon, 23 Apr 2001 04:25:00 -0700
From: "Metz, Eduard" <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-gan-fast-reroute-00.txt
Date: Mon, 23 Apr 2001 13:20:26 +0200

Hi all,

some questions on draft-gan-fast-reroute:

The FAST-REROUTE object includes several parameters for the detour LSP, such
as bandwidth, and include/exclude colors. Are these completely independent
of those for the primary LSP? Or are these supposed to have a relation?

The DETOUR object includes Downstream Node ID, identifying the neighboring
node to route around. This seems to work for all hops, except the
penultimate. Here the detour only can protect the link, also shown in the
picture in section 2. Should there be an exception for this case, or does
the penultimate hop apply different logic when setting up the detour?

cheers,
	Eduard

Delivery-date: Wed, 18 Apr 2001 18:03:00 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: new rev of GMPLS signaling I-Ds
Date: Wed, 18 Apr 2001 18:00:28 -0700

Hi Lou,
           I have gone through the 
draft-ietf-mpls-generalized-signaling-03.txt and 
draft-ietf-mpls-generalized-cr-ldp-02.txt drafts. I have certain 
clarifications on these drafts. Following are my doubts :

1. In draft "draft-ietf-mpls-generalized-signaling-03.txt", u mentioned that 
there will be a separate draft GMPLS-SONET for describing the technology 
specific details. U have removed just the TDM related details in that draft. 
The WDM specific label formats are still in the draft. Should not the 
waveband and lamda specific details and their label formats need to be in 
seprate draft like GMPLS-WDM. I mean to say why not put waveband label 
format in some other draft like GMPLS-WDM.

2.  It is mentioned in the draft that label set may be either restricted to 
a single hop or the whole LSP path. Can u please clarify that this decision 
should be based on what criteria or it is just a local node decision.

3. It is mentioned that LSP characteristics may be used by transit nodes 
e.g. to support PHP (section 3.1). Can u please explain how ? Is this case 
only possible in PSC ?

4. In section 3.1.1, it is written that lambda encoding type refers to 
switching of wavelengths. Does it also include the waveband ? Why there is 
not a separate LSP encoding type as waveband ? How does a transit node can 
identify that a waveband label is requested instead of a lambda label ?

5.  Are people more stressing on SDH/SONET in GMPLS area ?

6. In section 3.3.1, it is mentioned that waveband Id is selected by the 
sender and reused in all subsequent related messages. Can u please clarify 
that what are all those subsequent messages ?

7. In section 3.5, four different cases are explained where the label set 
concept may be useful. Can u please calrify the 4th case further ?

8. Is waveband Id locally signifcant i.e. between the two adjacent nodes or 
is it globally unique for whole LSP path ?

9. Can the generalized label TLV be present in Label Release/Withdraw 
messages ?

10. Is there any new draft coming on O-UNI ?

11. Is anybody defining the clear interworking on O-UNI and GMPLS ?

12. In section 5, it is mentioned that acceptable label set may be present 
in notification message to indicate what all labels are acceptable ? Can u 
please clarify what actions a node have to take once it receives the 
notification message with acceptable label set ?

Please help me in understanding these drafts.

Thanks,
manoj.

>From: Lou Berger <[email-masked]>
>To: [email-masked],[email-masked]
>Subject: new rev of GMPLS signaling I-Ds
>Date: Tue, 17 Apr 2001 17:12:17 -0400
>
>All,
>         It looks like the I-D folks are out (and not publishing) for a few
>days.  For those interested updated versions of the generalized signaling
>docs, they are available at:
>
>http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt
>http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt
>http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt
>
>Per the last IETF, these drafts don't include SONET/SDH specifics.  A new
>draft covering the specifics will be published in a few days.
>
>Lou (and co-authors)
>
>>Subject: Autoreply from Internet Draft Submission Manager
>>From: [email-masked] (Internet Draft Submission Manager)
>>
>>Hello,
>>
>>This message is being sent to acknowledge receipt of your submission
>>or message to [email-masked]
>>
>>The I-D administrator will be out of the office until Monday,
>>April 23rd. All submissions will be processed.
>>
>>Thank you. We appreciate your understanding and patience.
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 17 Apr 2001 14:15:28 -0700
Date: Tue, 17 Apr 2001 17:12:17 -0400
To: [email-masked],[email-masked]
From: Lou Berger <[email-masked]>
Subject: new rev of GMPLS signaling I-Ds

All,
         It looks like the I-D folks are out (and not publishing) for a few 
days.  For those interested updated versions of the generalized signaling 
docs, they are available at:

http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt

Per the last IETF, these drafts don't include SONET/SDH specifics.  A new 
draft covering the specifics will be published in a few days.

Lou (and co-authors)

>Subject: Autoreply from Internet Draft Submission Manager
>From: [email-masked] (Internet Draft Submission Manager)
>
>Hello,
>
>This message is being sent to acknowledge receipt of your submission
>or message to [email-masked]
>
>The I-D administrator will be out of the office until Monday,
>April 23rd. All submissions will be processed.
>
>Thank you. We appreciate your understanding and patience.

Delivery-date: Mon, 16 Apr 2001 14:20:26 -0700
Date: Mon, 16 Apr 2001 17:17:15 -0400
From: Vijay Gill <[email-masked]>
To: <[email-masked]>
Subject: CCAMP minutes Acknowledgements

We'd like to thank Gile Heron, (3) Jim Boyle and Ed Kern for the minutes.
They did an incredible job at taking down some very detailed notes.

-vijay and kireeti

Delivery-date: Mon, 16 Apr 2001 08:55:16 -0700
Date: Mon, 16 Apr 2001 11:52:50 -0400
From: Vijay Gill <[email-masked]>
To: <[email-masked]>
Subject: CCAMP minutes

Folks, CCAMP minutes.

Notes for CCAMP:

Started off with a few comments: Kireeti mentioned that CCAMP needs
design teams for requirements . Also more SP input would be
welcomed. There would also be CCAMP interaction with TEWG.

Sub-IP area intro (Scott)

Need to consolidate sub-IP stuff into one area (currently temporary -
aimed at 1-2 years and hopefully less.)

CCAMP is one WG - also a bunch of others.  Commonality is that none of
these fit well into existing areas.  "Dark underbelly of IP, not
bright light above."

Will keep ADs as tech advisers to WG.  Fairly hands off. Mentioned
that there are 300 or so IDs that need to be filtered in this area.
Need help from a lot of people to filter through this to figure out
what the IETF in general and this area esp. needs to deal with.

Will be re-evaluated post IETF in London (IETF 51).

Using 2 octets for b/w values (Qingming Ma)
[Presentation]

Thing to note: Formula is a * 2 ^ b - handles values up to
8,000,000,000 TB/s.  (Really means (a*2)^b of course).

Saves about 50% of size of TLVs.  Also reduces h/w requirements (no float.)

Recommendation - replace 4-byte FP in current drafts OR define new B/W
sub-TLVs that use 2 octets.

Was put to the Room. The general commentary appeared to be that this
was not worth pursuing. [Notes are a bit vague here, commentary
welcome]

Tunneltrace (Ron Bonica)
[presentation]
Comments:

Curtis - Need to support ICMP work done earlier, and accept that in
         reality we're going to have to transition at some point.
         Lack of ACL used to be considered a "feature" in the NSFNet
         days (allowed customers to tell clueless operators what they
         were doing wrong.) So it should be a requirement that at
         least at the macro level this is still true.

Kireeti - AS level should suffice?

Curtis - want ICMP to be informational now, and historic later.

Scott Bradner - IESG has discussed this a lot.  Asked a design team to
                come up with generic problem statement and come up
                with generic solution.  Right time to talk about it is
                once that report has been discussed.

Crankback Routing Extensions (Atsushi Iwata)
[presentation]
Status:

initial March 2000 (00.txt)     CR-LDP extension for crankback
second  Jul 2000   (01.txt)     additional descriptions for CR-LDP (accepte=
d
                                as MPLS-WG draft)
third   Dec 2000   (this draft) RSVP-TE in, and improves descriptions.

Propose that whole draft is accepted as a CCAMP WG doc
(draft-ietf-ccamp-crankback-00.txt) for crankback routing for MPLS
signalling.

Comments:

Rob Coltun - applicability?  Can see it being used for abstraction
             (e.g.  ABR).  For single area why not crankback and retry
             without this draft?

Atsushi - crankback should be general to both single and multi-area
          cases.  Should not preclude single area.  Feedback mechanism
          could be used instead, but we definitely need crankback for
          multi-area.

Rob - want requirements for multi-area/hierarchy sussed before this is
      accepted.

Curtis - would only have strict route in local area, and loose route
         beyond that.  If hierarchical tunnels should be able to
         recover.

Kireeti - but you could have picked the wrong ABR.

Curtis - if you don't use admin colours you're OK - can't pick wrong
         ABR.

Unknown - several multi area methods have beenh proposed.  All ask for
          crankback.

Kireeti - will wait until all requirements come out and then come back to
          this draft.

Closed-loop automatic link provisioning (Lily Cheng)

[notes get vague here ]

CCAMP requirements (Dave Walker)
[presentation]

First draft of a requirements document.  Aim is to put CCAMP work into
some kind of context.  Goes beyond requirements into
framework/architecture etc.

comments:

Curtis - this is nothing to do with CCAMP charter.  Very like COPS
         which has been rejected for this.

Dave - but we have to have a framework.

Curtis - this isn't it.

Vijay - I tend to agree, but we need to take this to the list.

G-MPLS Architecture (Eric Mannie)
[presentation]
27 co-authors!

Reverse engineering of 10 existing drafts to get arch.  8 of these are
WG items, some moving to WG last call.  Form a coherent/consistent set
of specs.  Challenge is to explain them all in one doc.  Co-authors
are authors of those drafts.

Status: published, Got comments.  Added new section on n/w management.
Log of comments/resolutions. Will be adapted to revised building
blocks.  01 soon after this IETF.

How to help:
Send comments in email.

Comments on building blocks directly to the authors of those. Please
point out discrepancies between draft and building blocks.

Proposal:
Accept as CCAMP WG item
target info RFC
publish new version
Send draft to ITU-T and OIF

Comments:

Scott - If sent, it needs to note that this is only temporary and the
        author's opinion, not that of WG (until it is). Especially
        with ITU-T, we have to be careful, as they can't reference
        IETF drafts.

Curtis - this is what he expected.  Not perfect but very good and
         should be WG doc.

Eve - excellent reverse eng of work done.  Had hoped that CCAMP
      formation and expression of requirements would enable us to do
      more with architecture than reverse architect proposed solution.
      Think we should also look at carrier requirements and look for
      discrepancies with architecture.  G-ASTN is actually not
      intended to be different approach.  Both doing ASTN - need some
      form of ?.  G-ASTN relies on architecture input from carriers.
      Need open email discussion.

Curtis - requirements of carriers not being addressed?

Eve - happy to discuss on mailing list in absence of time.

Kireeti - might be premature to have requirements after drafts.  Do
          these in the right order - code freeze, code review,
          requirements

Intra-Domain GMPLS architecture (Yangguang Xu)
[presentation]

Accept this as WG document.

Comments:

Eric Mannie - what is missing in "our" G-MPLS architecture?

Kireeti - no time for this.  Eric's doc is a concrete proposal, shows
          how it all fits together.  Personal opinion is that this
          draft is more of a framework.  Should decide if we want a
          framework ID, do we want arch ID.  Do these fit
          requirements?

Xu - can we work together?  No problem with working with other
     authors.

Curtis - in past practice was to have 2 WGs if there were different
         approaches.  If they are different, should we have 2 WGs?  If
         not, then one is framework and one is architecture.

Lou Berger - Any parts that fit architecture picture should be
             incorporated into that.

Xu - what about reverse direction.

Vijay - Work out on mailing list.  Thanks for your time...

G-MPLS signaling specs - Lou Berger
[presentation]

A few changes - aimed at making it easier for the future.  One
substantial technical change on SONET/SDH, will discuss that later.
World doesn't stop as finish doc, need to accommodate new techs as
they come, so one change to make it easier as it happens. One other
change - moved protection flags into own object.  Make it easier to
change there rather than change in label request.  One bug also to do
with v6.  Fixed.

Authors believe they are done. No more changes to make.

Big change was there was technology specific stuf in the label
request.  Problem would be how to assimilate future technologies -
would need to change label request.  Moved that into the tspec/traffic
parms since were really describing connection in technology specific
ways.  Tspec was great for packets but not for SONET/SDH.  Now fixed
that.  So expectation is that when new technologies arrive
(e.g. G.709) will have new doc outlining new changes required to
support that standard.  So end up with identical label request for all
technologies.

Tspec/traffic parms has technology specific stuff.  First case is
SONET/SDH.  Some minor changes here based on feedback from SONET
folks.  Think is correct.  Please give feedback if disagree!

Next steps - get this out in the next couple of weeks.

Proposal is to go for joint CCAMP/MPLS WG last call.  Docs are
believed now fully baked!  Not ready for rest of IETF until we have
consensus in CCAMP and MPLS.  Authors believe they are ready.

? - Explanation question.  Seems like new technologies will require
    changes.  G.709 is actually ready so why not put in now?

Dimitri - we will consider G.709 within the global parameters that we
          have.

Kireeti - what if put in now and ready in 3 months.  What if someone
          then says "what about something else" - we'll wait for ever.
          Issue what we have now and incorporate new stuff later.

Lou - agree. We have a good framework.  G.709 can be easily defined
      within this structure.  If we find in doing the G.709 document,
      that the structure here doesn't allow definition, then that will
      be an important issue.

Eric - G.709 is stable.  G.709 is just a TSPEC so we can do it in
       parallel.  Adding stuff that is approved/standardized like
       G.709 is not a big deal.  Companies are already announcing
       chipsets for G.709.

Lou - we should let base fns move forward, and as soon as we have
      specifics of G.709 (even if only 2 pages) it can be issued as a
      separate doc.  We have structure for next technology - which may
      well be G.709.

? - not question of whether this is broken.  Have a proposal that says
    what has to be added so why not do it now?

Kireeti/Lou - lets do this in their 709 presentation.

Curtis - plenty of precedence for writing something with good
         extension mechanism and adding stuff later.

Kireeti/Vijay - checked we have consensus for last call.  Consensus of
                meeting will be noted to mailing list.

 [There were probably about 30 folks out of 250 to put up their hands.
 25 for, 5 against]

GMPLS Signaling Extensions for G.709 (Gert Grammel)
[presentation]

Proposal is IP-based control-plane for G709 capable networks.  Why?
G709 will be interesting 10 gig, 40 gig etc.  Why was G709 born?  G975
is standard for submarine ULH.  SDH frame + FEC.  Need FEC to handle
photonic transmission, and to optimize span power budget.  Increased
distance between regenerators =3D cost saving.

Turns out we need FEC for ULH and for VSR (allows cheaper fibers)

Sonet/SDH, and IP, GE, 10GE, ATM.  Sync and Async.

New frame defined.  G709 =3D "digital wrapper".

GCC =3D Gen com chan
G709 payload
FEC.
Supports inbound + out of band signaling.
Future layer stack has any over G709/lambda.  Need GMPLS to handle G709.

Proposal is extend G-MPLS for G709.  Provide new TSPEC.  Generalized
label.  IF/IB signalling transport via GCC (comparable to SONET DCC)

G-MPLS is the right control plane for G709!

Request WG accepts this draft as WG doc in CCAMP

(draft-fontana-gmpls-control-g709-00.txt)

Comments:

Randy - My understanding of CCAMP is that "C" is "Common".  Developing
        a unified control plane.  Is this "The" Unified Control Plane?

Kireeti - GMPLS is a unified control plane, but technology specific
          pieces fit on top of GMPLS, this is an example.  e.g. SONET,
          G709.  We don't have a G709 or SONET WG, so can't do it
          there.

? - Observations.  Good overview of G709.  Didn't discuss all reasons
    for G709. Other comment - this doc defines signal types,
    e.g. Transparencies and OSS.  Why define some of these.  G709
    defines a bunch of stuff.  None of this was covered.

    [There was much scratching of heads.]

Eric Mannie - totally incomprehensible response (lack of Microphone.)

Curtis - All the more reason why not to put G.709 into the main GMPLS
         signaling. - Let's wait for these to converge.

? - thinks draft-mannie is more complete.  Aligning will take "2
    minutes".

? - Better to have real generic format and have tech as appendix.

Kireeti - been there before.  Lets not go back there!

Lightpath Route (LRO) Extensions to RSVP-TE for OCh Connection Setup
(Murali Krishnaswamy)
[Presentation]

Scope of GMPLS Signalling (Yangang Xu)
[Presentation]

Extensions to GMPLS signalling (Zhi Lin)
[Presentation]

Proposal is to work together to merge/extend encoding/signal/G-PIDs,
to align technology specific labels, and to resolve issues brought up
in email list.

Kireeti - You should look at the most up to date drafts, they include
          a lot of what you mention. Need to look at current signaling
          spec (where stuff moved to TSPEC) to see what the gap is
          now.

Leen Mak - Good to have a list of circuit types.  As a lot of packet
           folks thing there are just a few pipe types.

Kireeti - yes

Curtis - If there is any disagreement in encoding for SONET or for
         waveband switching then they should move SONET into separate
         doc (like G.709).  Since you've added an extension mechanism,
         maybe it's best to define SONET in that manner, just like
         G.709.

Eric Mannie - incomprehensible reply.

Kireeti - agree with Curtis.  If there is disagreement on mail list we
          should move out to separate document.

Lou Berger - these changes plus anything else we missed is good input
             to GMPLS draft to check nothing is missing.  Wouldn't be
             surprised if in last call we find a bunch of other stuff
             we missed.

Kireeti - we should move G.709 to different doc.  2 groups working on
          G.709 should come together and THEN we can talk about making
          it a WG doc.

Restoration Mechanisms and Signaling in Optical Networks / Packet Optical
Escalation Strategy
Dimitri (and many others)

Note from Rob Coltun that these are informational presentations at
this time.  Survivability is key issue for Intelligent Optical
Networks.  IP based control plane must cover protection and
restoration mechanisms for non-packet based networks.

[ presentation ]

Two approaches, the bottom up, and the top down.  Bottom up.  The all
optical network triggers the edge/packet device.  Cascading triggers
since many services go over single fiber, which is a common
multi-layering strategy.  Their Hybrid strategy involves a coupling of
the layers.

Solution Objectives.  Notification aggregates multiple failures for
scalability.  Restoration time independent of the # LSPs. Minimize
downtime and resource utilization.

Microphone passedover to Jino Hahn (sp?) for review of what has been
done in actuality with regards to this.

OSC Controller in an OXC which communicates to different layers.
Example of restoration approach, see presentation.

Conclusion: need to use common mechanisms as a foundation.

Dimitri - conclusion is we need to have technology independent
          mechanisms and "custom" mechanisms which are technology
          defined.

Proposal is to split mechanisms from signaling protocol extensions.
Would like to co-operate with others.

Inference of Shared Link Risk Groups (Dimitri)
[presentation]

Quick comments on draft-many-inference-*
SRLGs allow failure disjointness and  physical/logical hierarchies.

Important issue is definition of physical and logical hierarchies.

Physical is fibres etc.

Logical can be geography.  Region/Zone/Element.

Propose a hierarchical SRLG encoding.  To take geographical topology
into account have region, zone ID.

Proposal: we want to open discussion on this.

Kireeti - can't progress until we have requirements (as Rob said.)

? - does that apply to SRLGs.
Kireeti - lets take this to the list.

Signaling for Fast Restoration ( Bala Rajagopalan)
[presentation]

What's this about?

Functional description of signaling for certain protection modes.

Makes distinction between restoration and reprovisioning.

Defines "lightweight" signaling protocol.

Why do we need restoration signaling? ?

Mechanisms needed?  Pre-establishment of protect path state.  Failure
notification. ?

Introduces functional descriptions for restoration/re-provisioning.
Example on why signalling is needed.

Pre-establishment of protection path state, failure notifications,
activation.

perspective: SONET control channel.  K1/K2 takes 375 uS, linear span
restorations 60 ms, line switch 100 ms..

Why a dedicated signaling protocol?

1. Performance.  Needs to be lightweight, minimal, etc. etc.
2. Customization is appropriate where it makes sense (e.g. LMP.)
3. May not have a signaling protocol for provisioning.

How to proceed?

Hopes that if we have no other job we'll read the drafts.

Question for Rob.  This group doing lots of restoration work.  Gated
on requirements. When are we going to get them from TE?

Kireeti - appreciate the fact that Bala only took 4:18 seconds,
          acknowledges the dependence on TE.

          Q: is TE signed up for this, there is a big dependency

(3) Jim Boyle - we understand the dependency

(3) Jim Boyle - we have done lots of work on this in TE.  If it takes
a while to get requirements it isn't catastrophic.

Bala - people don't seem to appreciate difference between MPLS and
       this.

Jim - you need to consider that if people keep disagreeing with you
      then they may be right!

Generalized MPLS Recovery (Jonathan Lang)
[presentation]

Common understanding of terminology.  Difference between protection
and restoration (former is fast but may need dedicated resource.
Latter is slower but can use shared resource.)  Path/span levels.
Primary/secondary LSPs.  Secondary have resources requested and
reserved but not allocated so other LSPs of same pri can use the
resources with caveat that if the secondary was needed by primary then
they'd be bumped off.

Need mechanisms to advertise b/w for secondary LSPs.  How do we do
bandwidth accounting in each node to ensure resources used
properly. Referenced all of this in generalized recovery draft.  But
this isn't published yet?

Curtis - did you look at draft-kini and is it aligned.

Jon - yes, and it has additional stuff.  Part of what "we" need to
      work on is whether we need those requirements.  Or is this
      something done at LSP establishment?

Curtis - essence is ability to share backup b/w.  Can you do this?

Jon - yes that is the essence.

? - Other bodies have been doing work over the years.  Why invent new
    terminology?  Willing to contribute docs with terminology in to
    list.

Jon - we just need to agree common terminology.  Seen many docs with
      different terminology.

? - if don't agree will have a mess.

Vijay - relying on "preemptable" services, or services that should be
        there (via preemption) can get interesting.

Status of LMP (Jonathan Lang)
[presentation]

Clarify text/terminology.
Decouple control channel/link bunndle dependence.
Address in-band control configuration.

Changes in draft enumerated in presentation.
Other changes based on comments received etc.
Modifed test messages
enhanced LinkSummary message
Added Channel Activate messages
Added LMP length field
Modified FSMs
added MD5 authentication option.

Next Step.
Remote CCId from TE link-related messages (completes the decoupling.)
Address more comments on the list.

Kireeti - thanks to Bala and Jonathan for getting us ahead of
          time/back on time.

LMP for WDM - Andre Fredette draft-freddette-lmp-wm-01.txt
[presentation]

Will describe LMP-WDM doc.  Also compare to NTIP (competing proposal).

Diffs from -00 document:

1. decoupled lmp and lmp-wdm sessions.  Up to the
   cross-connects/router to correlate this and to manage relationship
   between sessions.

2. Focused on opaque DWDM transport systems.  More thought required
   before we handle all-optical stuff.  But do have a framework here
   once IPO group send requirements.

3. Whole list of things we could advertise.  Narrowed this down to get
   packet formats.

4. Group ID added for message suppresion - see draft!

5. Added a bunch of stuff that was proposed and are throught to be
   reasonable.

Requirements (LMP vs NTIP)
Need an open protocol between tx systems and OXCs (and perhaps attached
devices - e.g. Routers) to exchange info about links.

Protocol characteristics:
reliable
fast
simple as possible
motherhood and apple pie

Require following functionality (ordered from most to least agreement):

1. Adjacency Discovery and control channel maintenance.

2. Connectivity discovery (avoids manual provisioning) control over
   link transparency.

3. Fault management - detect defects and advertise up.  NTIP proposes
   trace notification to monitor trace messages.

4. Link Property Advertisement.  Some disagreement here on what you
   need.

5. Performance Information Advertisement.  Link Health.

Table comparing LMP-WDM/NTIP

Big difference - LMP-WDM uses IP with LMP ACKs for transport.  NTIP
uses TCP.  Age old argument - advantages/disadvantages of each.  Both
protocols attempt to accomplish the same basic objectives.

Could come to agreement on information to advertise.

LMP-WDM will incorporate good ideas from NTIP.

Big advantage with LMP-WDM is that it extends LMP.  Main requirements
met by LMP.  Nothing extra that is not needed in LMP.  Results in
single protocol for basic link management.

Recommend:

Use of LMP for link management of all devices in GMPLS network.

Merge new items into LMP-WDM (trace monitoring/defect types)

Accept LMP-WDM as WG doc.

? - What is NTIP?

Andre - next presentation is NTIP.

? - Why not just use LMP.  Isn't this just an annex?

Andre - same as with GMPLS signalling.  I don't care where it goes.

(3) Jim Boyle. - all devices in GMPLS network?

Andre - yes.  Wherever you have need for this info have LMP?

? - like the table.  Key is fault management.  Key attribute is fault
    monitoring.  This is in NTIP.

? - IPO WG has WG item on all constraints for optical routing.  Need
    to co-ordinate on how to pass link-layer stuff around.

Andre - yes we need to know these things. LMP can be vehicle for
        advertising this.

? - Something about link layer abstraction.

Kireeti - Need to know what we want to measure and communicate between
          systems.

Network Transport Interface Protocol (NTIP) for Photonic Cross
Connects PXC (Osama Aboul-Magd)
[presentation]

Overview:
NTIP runs between PXC and Transport NE. (TNE).

Doesn't have knowledge of health of the line system.

Small set of messages - so simple to implement

Uses TCP for reliability - sufficient for this app and avoids
reinventing the wheel.

Fast reporting of defect events - essential to ensure fast restoration
and recovery of lightpaths.

Asymmetric Protocol (unlike LMP) PXC master.  TNE slave.  Minimises
need for persistent information at TNE.

Most requests are initiated by PXC - confirms master/slave nature of
protocol.  Defines a series of failure types.

Big difference is simplicity relative to LMP.  TNEs are pretty light
on processing capacity and aren't designed for complex management - so
put functionality in management system.

LSP is complex because of OXC-OXC interactions.  LSP is 6 states, 18
events. Plus 9 states, 16 events for TE FSM, plus... ?  states, 12
events.

NTIP is 4 states, 14 events.

TCP is sufficient for this kind of application - so chose that.
Recovery is good enough for OXC-TNE.  Remember that this is one hop -
so failure is rare event.

Fault localization of LMP is not needed for this PXC-TNE case.  Big
table comparing NTIP and LMP-WDM.

Advantages of simplicity etc.  Also has priority handling of defect
reporting messages.  See this as important.  Also ability to recover
from control channel failure (not specified in LMP-WDM.)

Same proposal as Andre (but other way round) - accept NTIP as WG doc.
Don't want 2 protocols.  Also need to co-ordinate with T1X1/ITU.

Andre - big thing you made about events and states.  But they are all
        in TCP.  Have you counted those?

Osama - they are in O/S.

Andre - speed of TCP?  What if things get stuck in TCP transmit queue.

Osama - this is very controlled environment.  Not really congestion.

Andre - this is exact reason not to use TCP.

Andre - claim of simplicity is at expense of identifying un-needed
        complexity in LMP.  Also because document hasn't been written
        yet.

?a - Didn't want to reinvent the wheel.  But that is exactly the case
     if you look at LMP's functionality.

?a - LMP-WDM.  All agreed that it satisfies a requirement.  That's why
     it was proposed.  In terms of FSMs/messages you should compare
     with LMP-00 as that is the state this is in.  Looked at messages
     (e.g. config) - some of this hasn't even been defined yet in the
     doc.  So if you proceed with NTIP your number of messages/states
     will grow as it matures so not a fair comparison.  ?a - in terms
     of co-ordinating with other organisations.  LMP is being used in
     other standards bodies.

Osama - wasn't discussed in Maui.

? - suggest you read the documentation.

?b - Issue with LMP is OXC-OXC is more complex than this.  Don't know
     if will ever implement LMP on DWDM systems.

Kireeti - Would you do NTIP on WDM devices.

?b - No. Don't really care about TCP etc.  Bunch of issues, trying to
     talk to Jonathan etc. ahead of time.  Asked for info on NTIP and
     didn't get in back.

?c - echoing point of importance of simplicity.  Need to identify
     required functions. If only want one part of the functionality do
     I have to have whole protocol.

Kireeti - this is CCAMP so lets stay common.

Bilel - It's more important to have interoperability between WDM and
        line system.

?d - NTIP and LMP-WDM have similar requirements.  NTIP is fault
     management.  Carriers require protocol from line system to PXC,
     not PXC to PXC (as is more common case.)  Key is fault
     management.  TNE can't handle complexity, so have pragmatic need
     for protocol like NTIP.

George Swallow - Previous comment is a very short-sighted call.

George Swallow - I've got to do LMP anyhow.  The choice for me isn't
                 46 vs.  14 states.  It is 46 vs. 60 states.
                 Simplicity is to keep all in one protocol.  Eve -
                 This has happened several times before.  Start with
                 specific things.  As we get experience we discover
                 generality.  As we go to next technology domain we
                 discover what we did for specific technology wasn't
                 generic and have to go back.  Different definitions
                 of fault management.  For me it is ID + locate fault
                 so craft can be used to fix it. What is terminated
                 and not terminated becomes important to consider.
                 We're calling it WDM, but is actually much wider than
                 that.  Need to make sure that what we do for
                 discovery + defect detection that we know what we're
                 targeting.

Andre - lots of details still to work out.  Nothing to do with
        transport system.  IMO the assertions of simplicity are
        assertions without basis.

Lou - 2 very separate topics / issues.  1. =3D what.  2 =3D how.
      Functionality need to walk through what is there in each one and
      what is needed =96 come up with a "union".  On transport
      issues.  Use of TCP - while trivial to make socket call.
      Implications are not trivial.  Yes embedded systems have TCP
      stacks.  But how good are they?  How do you deal with partial
      completion of messages etc. etc.  Had to do a whole bunch of
      extensions to handle that in LDP.

Ross - also wants to stress skepticism regarding simplicity.
       Protocols never go away.  Just end up with more and more over
       time.  Any protocol starts simple and gathers cruft. Way to get
       simplicity is to use existing protocol that does most of what
       we want. Throw away bits of LMP you don't need.  For most
       vendors already have TCP and LMP.

Rob Coltun - this is the last time we have 2 proposals.  In future if
             2 teams can't be reasonable and come up with one then
             neither will be accepted.

Draft-dubuc-lmp-mib-01.txt (Dubuc)
[presentation]

Addresses provisioning, fault management and performance monitoring.

Recommendation: WG document?
Kireeti: any objections?
none noted.
Recommend that CCAMP accept this as a WG doc.

? - AtoM MIB group is doing similar work.  Where should we do the
    work?

George - generally keep MIBs and protocols together so MIBs are
         specified correctly.

Kireeti - any objection to keeping this here.  No objection noted.

Summary - Kireeti

Sorry, no armwrestling.
Two-octet bandwidth values.
Tunnel trace.
Crankback - wait on hierarchy reqts.
Closed-Loop provisioning - right home? WG? IETF?
CCAMP Requirements - discuss on the list.
      - do we want them, and from whom?
Architecture - Eric will integrate the two.

Scott - while it is useful to have WG input on what should be WG item.
In the end it is in charter is up to WG chairs, if not then leave to
IESG.

CCAMP requirements - need to discuss on list.

Architecture docs.  Eric will integrate stuff that was thought to be
missing from his document.

?1 - we agreed to have requirements doc and architecture doc.

Kireeti - will discuss on list.

?2 - same point.

Kireeti - 2 proposals.  If want to be architecture must integrate with
          existing one.  But now want to split into two.  So integrate
          architecture.

?2 - up to mailing list.  Refering specifically to GMPLS.  Somewhat in
     CCAMP.  Proposal is to take GMPLS docs - what is framework, what
     is architecture, are they adequate, to mailing list.

?3 - makes sense to have 2 docs.  Need to take to mailing list to
     figure out what has what.  George - easier to figure out whether
     you have consensus at meetings than on mailing list.  Few people
     on list can make it sound like no consensus.  Thinks Eric's doc
     is good.

George - stuff in Yangyang's document should go into arch doc.  Rest
         of his doc might be basis of a framework.

Eve - we had agreed to look at both docs and merge in arch stuff.  And
      that there would be a separate doc.  Look at what is left and
      figure out if is framework or requirements (or both.)

Kireeti - should we move the specs to last call.
Kireeti - do we have consensus? - looks like we do.
Kireeti - Base signalling to WG last call, about 30 to 2.
Kireeti - LRO needed, go to list.

Kireeti - G.709 is not cooked.  For those who think it is done bear in
          mind that although SONET was very well cooked it took a
          while to figure out how to integrate it.  Can authors of two
          G.709 proposals come up with one doc?  Will be WG doc.

Wait on requirements for restoration/recovery.

Wants one spec for LMP-WDM / NTIP.  Get together one more time.
Either we have one, or zero.  Can't have two (or three!)

Eve - G.709 is stable/approved.  Wans to see reflection of discussion
      point that SDH/SONET and G.709 might be treated in similar
      manner. Not mentioned in summary.  For LMP-WDM / NTIP need clear
      summary of what requirement we are meeting.  Don't want two
      protocols.  Look at what is needed/required.

Andre - Don't think authors have tried twice to reconcile this.  LMP
        authors want to use LMP to avoid new protocol.  NTIP authors
        for some reason don't want to use LMP as is LMP.  Authors at
        impasse.

Vijay - every new protocol in the network costs us time, costs us
        training.  Don't want to complicate network any more than it
        is.  With WG hat, what does the room think?

Osama - comments before going to room.  NTIP solves an urgent problem.

Kireeti - then you should have defined it 2 years ago.

Curtis - requirements were pretty well spelled out in LMP-WDM spec.
         So can't make statement that need to come up with them.

Jonathan - significant overlap between LMP and LMP-WDM.  Don't want to
           redo this in new protocol.

Eve - G.709 wasn't considered in the requirements.

Eve - Reminds me of the "great information model" debate.  PDH had
      model.  SONET/SDH came along.  Generic info model people has
      based things on PDH and didn't want to change things.  But
      actually there was stuff which wasn't generic.  Pay now or pay
      later!

Dimitri - Please can the G.709 people join our efforts?  Integrate
          these extensions from the Lucent doc so we get a doc which
          doesn't affect GMPLS and can be suggested as an item for the
          next meeting.  Approach should take into account the need to
          go further.  Step forward not back.  Kireeti - take LMP-WDM
          discussion to the mailing list.

? - sense of room?

Kireeti - need to step back and check we have requirements.  Let's get
          those and then fold it in.  What are we measuring in CCAMP?
          What do we need from OXCs to DWDMs.

Curtis - feel from room on G.709 and is it fully baked?  Feel from
         room on LMP-WDM vs NTIP.

Eve - before we get sense on G.709.  How many people have actually
      read it?

Scott - don't want to get sense on LMP-WDM/NTIP.  Got sense on G.709.
        Very few thought it was cooked.  Only a few know what it is
        more than a character string. There is not enough mass to vote
        now

--end of minutes

Delivery-date: Fri, 13 Apr 2001 09:17:06 -0700
From: [email-masked]
Date: Fri, 13 Apr 2001 11:14:04 -0500
Subject: Clarifications on draft-kompella-ospf-gmpls-extensions-01
TO: [email-masked], [email-masked]

--openmail-part-20365843-00000001
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
	;Creation-Date="Fri, 13 Apr 2001 11:14:04 -0500"
Content-Transfer-Encoding: 8bit

All,

In draft-kompella-ospf-gmpls-extensions-01, the incoming & outgoing
interface identifiers are 32-bits. Does this refer to the 32-bit
"interface-ID" define in:

Draft-ietf-mpls-rsvp-unnum-01
 Draft-ietf-mpls-crldp-unnum-01

I.e., do we assume that incoming & outgoing interfaces that are
advertised by IGPs are unnumbered or they can carry IP addresses.

Thanks. 

------------------------------------------------------------------------
-----------
Wesam Alanqar         Member of Technical Staff
Technology Research Group (TR)
Technology Planning & Integration Dept. (TP&I)
Sprint
9300 Metcalf Avenue, KS 66212 
Phone: 913-534-5623 Work, Fax: 913-534-3485
------------------------------------------------------------------------
-----------

--openmail-part-20365843-00000001
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf"
	;Creation-Date="Fri, 13 Apr 2001 11:14:04 -0500"
Content-Transfer-Encoding: base64

--openmail-part-20365843-00000001--

Delivery-date: Fri, 13 Apr 2001 00:17:19 -0700
Date: Fri, 13 Apr 2001 00:11:42 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: "Metz, Eduard" <[email-masked]>
CC: [email-masked], [email-masked], Der-Hwa Gan <[email-masked]>, Arthi Ayyangar <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: Re: draft-gan-fast-reroute-00.txt

"Metz, Eduard" wrote:
> 
> haven't read the draft in detail yet, but adding support for SRLG to avoid
> detours to be routed over links that share the same risk seems very
> useful.Sometimes even a plain requirement to deploy fast re-route in a
> usefull way. As an example consider the situation described in section 2,
> when link 1-2 and link 1-3 run in the same cable both the main LSP and the
> potential detour are affected by a single cable-cut. Leaving you with
> regular re-route.
> 

Thanks for the input. Will get back to you asap.

> Some other questions:
> - What will happen if the detour from Node1 to Node3 (picture section 2)
> passes Node4? Will the detour terminate at Node4, or will the traffic will
> pass link 3-4 two times?

I think that it is OK to have detour paths traversing through the same
nodes that the main LSP goes through. This type of loops does not
present problems in packet forwarding... except perhaps inefficient use
of network resources. But we need to be careful with the loop detection
mechanism described in the RSVP-TE draft.

> - Similar to the above, but now for the case where the detour passes the
> Egress?
> 

No sure this can happen after CSPF computation.

Thanks!

- Ping

Delivery-date: Thu, 12 Apr 2001 23:56:01 -0700
From: "Metz, Eduard" <[email-masked]>
To: 'Ping Pan' <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: draft-gan-fast-reroute-00.txt
Date: Fri, 13 Apr 2001 08:48:22 +0200

Hi,

haven't read the draft in detail yet, but adding support for SRLG to avoid
detours to be routed over links that share the same risk seems very
useful.Sometimes even a plain requirement to deploy fast re-route in a
usefull way. As an example consider the situation described in section 2,
when link 1-2 and link 1-3 run in the same cable both the main LSP and the
potential detour are affected by a single cable-cut. Leaving you with
regular re-route.

Some other questions:
- What will happen if the detour from Node1 to Node3 (picture section 2)
passes Node4? Will the detour terminate at Node4, or will the traffic will
pass link 3-4 two times?
- Similar to the above, but now for the case where the detour passes the
Egress?

Thanks.

cheers,
	Eduard

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: 13 April 2001 01:41
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: draft-gan-fast-reroute-00.txt
> 
> 
> Curtis Villamizar wrote:
> > 
> > > > It should be fine to provide a object that names a 
> specific node as a
> > > > special case of the detour object, and may be (is) needed to
> > > > accommodate existing code.  It might be useful to have 
> a form of the
> > > > detour object that covered the link disjoint special 
> case.  There
> > > > should also be a form of the detour object that allows the more
> > > > general list of SRLG.
> > > >
> > > > SRLG should also be considered in the "Detour Path Computation
> > > > Algorithm" section.
> > >
> > > Sure. Thanks!
> > 
> > So you'll add one or two Objects to cover SRLG, and 
> possible the link
> > disjoint special case.
> > 
> 
> Let me check with other folks here. We have shipped the restoration
> feature for a while, and providers have deployed it. So we have to be
> careful. Please understand.
> 
> Thanks again!
> 
> - Ping
> 

Delivery-date: Thu, 12 Apr 2001 16:42:25 -0700
Date: Thu, 12 Apr 2001 16:41:03 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-gan-fast-reroute-00.txt

Curtis Villamizar wrote:
> 
> > > It should be fine to provide a object that names a specific node as a
> > > special case of the detour object, and may be (is) needed to
> > > accommodate existing code.  It might be useful to have a form of the
> > > detour object that covered the link disjoint special case.  There
> > > should also be a form of the detour object that allows the more
> > > general list of SRLG.
> > >
> > > SRLG should also be considered in the "Detour Path Computation
> > > Algorithm" section.
> >
> > Sure. Thanks!
> 
> So you'll add one or two Objects to cover SRLG, and possible the link
> disjoint special case.
> 

Let me check with other folks here. We have shipped the restoration
feature for a while, and providers have deployed it. So we have to be
careful. Please understand.

Thanks again!

- Ping

Envelope-to: [email-masked]
Delivery-date: Thu, 12 Apr 2001 14:51:22 -0700
Date: Thu, 12 Apr 2001 14:49:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Presentations

Will everyone who presented at the CCAMP sessions please their slides
(in PDF or PowerPoint, or best of all, a URL) to Vijay and me?  If you
have already sent it, please resend, that will ensure that we don't
miss it.  Thanks.

Please don't send the entire presentation to the list.  We will send
a list of the URLs that we get to the list.

Kireeti.

Delivery-date: Thu, 12 Apr 2001 14:10:26 -0700
Date: Thu, 12 Apr 2001 14:07:05 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-gan-fast-reroute-00.txt

Curtis Villamizar wrote:
> 
> Please consider merging this capability with the bandwdith sharing
> capability described in draft-kini-*.  This would allow the bandwidth
> on backup paths to be shared where possible.  See additional comments
> on this below.
> 

Sure. I have read the INFOCOM papers before. Let me take a look at them
again. Just curious, has anyone implemented the proposed routing
(OSPF/ISIS) extensions?

> > 3.2 DETOUR Object
> >
> >              0             1              2             3
> >         +-------------+-------------+-------------+-------------+
> >         |       Length (bytes)      |  Class-Num  |   C-Type    |
> >         +-------------+-------------+-------------+-------------+
> >         |                   Source ID                           |
> >         +-------------+-------------+-------------+-------------+
> >         |                   Downstream Node ID                  |
> >         +-------------+-------------+-------------+-------------+
> >
> This seems to assume node disjoint paths.  A more general approach
> would be to provide a list of SRLG that the detour need to avoid.
>
> A special case is one where an SRLG contains all links terminated at a
> given node, which covers the node disjoint case above.
> 

My editing goof: the downstream node ID is the first downstream router
to avoid. It is used in the CSPF computation, which is to provide the
shortest detour path between the current router to a downstream merging
router. We will consider your comment of having a list for protecting
nodes.

> It should be fine to provide a object that names a specific node as a
> special case of the detour object, and may be (is) needed to
> accommodate existing code.  It might be useful to have a form of the
> detour object that covered the link disjoint special case.  There
> should also be a form of the detour object that allows the more
> general list of SRLG.
> 
> SRLG should also be considered in the "Detour Path Computation
> Algorithm" section.
> 

Sure. Thanks!

> 
> > 6 Intellectual Property Considerations
> >
> >    Juniper Networks, Inc. is seeking patent protection on technology
> >    described in this Internet-Draft. If technology in this Internet-
> >    Draft is adopted as a standard, Juniper Networks agrees to license,
> >    on reasonable and non-discriminatory terms, any patent rights it
> >    obtains covering such technology to the extent necessary to comply
> >    with the standard.
> 
> Could you please point out exactly what you think is new and unique
> about this proposal?

It's up to the lawyers to decide. ;-) Look, it seems everyone has used
the similar paragraph for their restoration mechanism. We really have no
choice. BTW, what's the status of that restoration patent application
from Bell Labs which your drafts are based on? ;-)

Take care and thanks!

- Ping

Delivery-date: Thu, 12 Apr 2001 09:39:47 -0700
Date: Thu, 12 Apr 2001 09:37:29 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: mpls-list <[email-masked]>, ccamp-list <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-gan-fast-reroute-00.txt]

This is a multi-part message in MIME format.
--------------5BB6FEDF1DBCD70B748BA81F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

This is the LSP restoration mechanism that Juniper have developed and
deployed. One of the main advantage is that the backup tunnels can be
initiated at head-end routers, thus there is no manual configuration at
intermediate routers. We have proposed two RSVP objects that are
backward compatible. Also since the detour paths are individually
established, there is no need to force labels to be globally assigned at
neighboring routers.

Please provide comments.

Thanks!

--
Ping Pan
--------------5BB6FEDF1DBCD70B748BA81F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

To: IETF-Announce: ;;:;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-gan-fast-reroute-00.txt
Date: Thu, 12 Apr 2001 07:05:43 -0400
Sender: [email-masked]

--NextPart

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

	Title		: A Method for MPLS LSP Fast-Reroute Using RSVP Detours
	Author(s)	: D. Gan, P. Pan, A. Ayyangar, K. Kompella
	Filename	: draft-gan-fast-reroute-00.txt
	Pages		: 12
	Date		: 11-Apr-01
	
In this document, we introduce a method to establish backup LSP
tunnels in large-scale networks. Two additional RSVP objects are
proposed. These objects together make possible for routers using RSVP
to create detours that can route around downstream links and nodes.
As a result, an LSP can quickly and automatically repair itself,
while redirecting the user traffic to the pre-computed and pre-
established detour routes in event of network link and node failures.
Packet loss is therefore minimized.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gan-fast-reroute-00.txt

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-gan-fast-reroute-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-gan-fast-reroute-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.

--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-gan-fast-reroute-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-gan-fast-reroute-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

--------------5BB6FEDF1DBCD70B748BA81F--

Delivery-date: Tue, 10 Apr 2001 04:01:15 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: restoration time requirement   (was Re: Last Call on RSVP Labe l Allocation for Backup Tunnels)
Date: Tue, 10 Apr 2001 11:51:50 +0100

Curtis,

I not sure I understand what point your trying to make - other that make
implicit critcism of the body of engineers who put together SONET/SDH
technology.

Generally speaking, the specs and parameters that go to make up SONET/SDH
are there for good technical and economic reasons and, while some of these
may now be historical, it would seem to me more helpful to work from an
assumption that a set of good engineers were solving a real problem. I can
try and give you my understanding and memory of the problems that resulted
in some of the SONET/SDH features you "AFAIK" comment on. I'm sure Heiles,
Maarten, and others will comment where their memory differs.

50ms restoration
This figure has a very long history. My memory is that this started as time
the SONET/SDH payload should wait before assuming a failure in the payload.
The figure was chosen somewhat randomly as that were many implementation
specific factors which would affect the time including detection of LOS,
detection of LOF, any protection mechanism (MSP or internal equipment card
protection) and we made a conscious decision not to specify any details of
these - they are open to different vendor implementation for good economic
reasons. It general use now, it includes any failure detection time, any
protection signalling time, any protection switching time, and any time for
signals to reacquire and stablise. In practise some implementations with
simple 1+1 MSP protection over short distances will switch in a few
millisecs while implementations of more complex shared ring MSP protection
on geographically large rings struggle to meet the 50ms. This is simply the
transmission time required to pass the MSP signalling around the ring. As a
broad summary, SONET/SDH is generally designed to go as fast as possible -
unless you are goning to invent a new speed for the speed of light, you are
unlikely to usefully go faster than SONET/SDH protection schemes.

I draw three conclusions from this
- lambda optical systems can and should just use the current SONET/SDH specs
as this is now the "bottom of the network" - some small modifications are
probably needed to reflect the analogue nature of DWDM
- SONET/SDH systems deployed over lambda optical systems should understand
they are no longer at the bottom of the network and do something about the
potential interactions, eg don't use SONET/SDH MSP or use a holdoff timer -
all out equipment is specced to have a programmable delay of 0-100ms and the
spec was written 10 years ago.
- packet based layers must be designed to cope with either SONET/SDH or
lambda optical protection switching underneath.

Scramblers
This is a good example of IETFers not asking the experts in the field.
No-one bothered to ask anyone who knew about SONET/SDH before writing the
PoS spec and just got it wrong. The x43 + 1 scrambler was specced for
non-byte interleaved SONET/SDH payloads in around 1990. There was/is nothing
wrong with SONET/SDH only some IETFers not knowing what they don't know.

Bi-directional fibre working
It has been know for a long time that bi-directional fibre working can cause
a problem with detecting fibre breaks - a transmit signal reflects off the
break and is received and a perfectly framed signal. This is why the J0 byte
was recoded (it was orginally called C1) so that each transmitter can send a
different signal label and detect if it receives it own signal label. My
guess is the anacdote you refer to was a problem in setting the J0 signal
label.

Hope this answer some of the "issues" people raise with SONET/SDH. I'm
convinced good engineers can work together but it takes a level of mutual
respect.

Andy

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: 09 April 2001 18:46
> To: Heiles Juergen
> Cc: [email-masked]'; Lazer, Monica A, NNAD; 
> [email-masked]';
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: restoration time requirement (was Re: Last Call on RSVP
> Label Allocation for Backup Tunnels)
> 
> 
> 
> In message 
> <AFC76835727DD211A7C20008C71EAF1E01146047@MCHH230E>, Heiles Juergen 
> writes:
> > Curtis
> > 
> > 	>Then again, this is second hand, so I could be 
> completely wrong. This 
> > is not a measurement I've made myself and the SONET 
> equipment is not somethin
> > g I'm familiar with .... 
> > 
> > you are completely wrong and I suggest you better make 
> measurments and get fa
> > miliar with SONET before making such statements.. SONET/SDH 
> equipment will no
> > t shut down/drop connections. Today SONET connections are 
> permanent connectio
> > ns setup via the management system. An automatic drop of a 
> conneciton as it i
> > s the case for switched connections will not occur. What 
> you will see is the 
> > insertion of AIS (alarm indication signal) after the 
> detection of an defect. 
> > But as soon as the defect is gone the AIS is removed and 
> the connection is ru
> > nning again. AIS is nothing harmful as due to the defect 
> the connection is in
> > terupted in any case. Furthermore the AIS avoids downstream 
> alarms (alarm sto
> > rms).
> 
> There was a similar problem encounterred when sending a packet over a
> POS link with the old short scrambling pattern in the body of the
> packet.  My understanding was that there was a small chance that
> alignment with the scrambler could take a SONET link out of service,
> then take the protect out of service and manual intervention was
> required to bring them back into service.  That is second hand too but
> someone from an ISP stood up at an IETF meeting and claimed to have
> tried it with spectacular (though not desireable) results and the
> statement wasn't challenged (and I know the person and he is a
> reliable source).  This statement was made in response to the
> assertion that there was no need to change the scrambler pattern
> length.
> 
> It was definitely not Siemen SONET gear (but you knew that) and AFAIK
> it is not called for in the SONET specs but I've been told that some
> other gear does exhibit this behaviour.  US carriers in particular
> have lots of it which creates a requirement for MPLS restoration that
> must be met for some but not all networks and applications.
> 
> My understanding is that this behavior is observed in a particular
> implementation, the same one that had the problem with DoS attack
> based on the short scrambler pattern.  This SONET gear could not be
> configured to bring the segment back into service without intervention
> which was key to making the DoS attack effective.  Note: The DoS
> problem was solved by lengthenning the POS scrambler pattern to be
> much longer than the MTU, requiring no change to the SONET gear.
> 
> In pointing out that this is second hand I am noting that it is
> possible that the problematic implementation might have been upgraded
> since these two problems have been encountered and could allow a
> configuration option to change this behaviour.  AFAIK this is not the
> case but I'd be pleased to hear that it has been corrected.  We can
> continue this discussion offline if you like.
> 
> > What could be of concern are the following points. I talk 
> about a server laye
> > r for a SONET/SDH network  (e.g. an Optical Network) 
> providing protection/res
> > toration:
> > 
> > Stacked protection/restoration:
> > If you use protection/restoration at an optical network 
> layer (server) and a 
> > SONET/SDH network layer (client) the server layer switching 
> times should be f
> > aster than the client layer reaction times, so that the 
> server layer does the
> >  protection/restoration and the client layer doesn't react.
> 
> I'm aware of this and I mentioned it below.  See paragraph beginning
> with OTOH below.
> 
> > Automatic power reduction/automatic laser shutdown APR/ALS
> > APR is used for safety reasons in order to avoid harmful 
> emission of laser li
> > ght in case of a fiber cut. One implementation switches off 
> the transmit lase
> > r in case of loss of signal at the receiver. A restart 
> action which is trigge
> > red automatically in intervals of several seconds is 
> required in order to tes
> > t if the link is repaired. Normally the APR function can be 
> switched off if n
> > ot needed. The APR function needs some careful 
> consideration in case of prote
> > ction/restoration and automatic connection setup in all 
> optical networks.
> 
> Thanks for the info.  I hadn't heard this.
> 
> > Regards
> > 
> > Juergen
> 
> Regards,
> 
> Curtis
> 
> 
> > > -----Original Message-----
> > > From:	Curtis Villamizar [SMTP:[email-masked]]
> > > Sent:	Monday, April 09, 2001 4:37 AM
> > > To:	Lazer, Monica A, NNAD
> > > Cc:	[email-masked]'; [email-masked]; 
> [email-masked]; [email-masked]
> > .org
> > > Subject:	restoration time requirement (was Re: Last Call 
> on RSVP Label A
> > llocation for Backup Tunnels)
> > > 
> > > 
> > > In message 
> <[email-masked]>
> > , "L
> > > azer, Monica A, NNAD" writes:
> > > > Voice switches will drop the connections after 2.5 
> seconds. A large numbe
> > r
> > > > of dropped calls will cause FCC reportable events, 
> which is something tha
> > t
> > > > US carriers need to avoid. So restoration within this 
> time frame is neede
> > d
> > > > for support of trunks carrying voice traffic.
> > > > 
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > > 
> > > > 908 234 8462
> > > > [email-masked]
> > > 
> > > 
> > > Monica,
> > > 
> > > We're off topic, so I changed the subject.
> > > 
> > > Thanks for providing the 2.5 second figure.
> > > 
> > > I've heard carrier transport people grumble about SONET equipment
> > > they'd be please to get rid of that will shut down even 
> when used as
> > > linear SONET with no protect path and as a result would require
> > > <100msec restoration.  Since there is enough of this 
> SONET gear, the
> > > carriers can't really get rid of it although it will probably
> > > disappear over time and so they will make fast restoration a
> > > requirement of people they buy from.  To be safe, the request for
> > > <50msec has been made.
> > > 
> > > If you are not blessed with such equipment or you are able to work
> > > around it when doing VoIP, then you are among the fortunate.
> > > 
> > > Then again, this is second hand, so I could be completely 
> wrong.  This
> > > is not a measurement I've made myself and the SONET 
> equipment is not
> > > something I'm familiar with such that I could say with 
> confidence that
> > > it could not be configured to hold on longer or to not 
> shut down at> 
> > > all if there was no protect.
> > >  
> > > OTOH there are those who (claim to) want to configure 
> SONET on some
> > > links but not on others and don't want a fast 
> restoration.  They want
> > > to be assured that restoration will occur only after it is safe to
> > > assume that SONET restoration is not available.
> > > 
> > > Curtis
> > 
> 

Delivery-date: Tue, 10 Apr 2001 00:44:05 -0700
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Date: Tue, 10 Apr 2001 09:38:43 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: sambasiva mantha <[email-masked]>
Original-CC: [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Subject: Re: restoration time requirement (was Re: Last Call on RSVP  LabelAllocation for Backup Tunnels)

This is a multi-part message in MIME format.
--------------CEE6CC99127E9C87B3DFC78E
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Sambu,

Ever tried to detect an "all-zeroes pattern"? It's never present after a
receiver circuit. If you cut/remove a fiber the receiver circuit enters
maximum amplification and produces noice. The clock & data recovery
circuit behind it interpretes this noise as a random pattern of "0"s and
"1"s. Depending on the clock recovery technique, the recovered clock
frequency might be as low as a few hundred kHz (SAW filter based clock
recovery). Therefore alternative means are typically deployed to detect
loss of signal; e.g. power level monitoring, loss of lock monitoring,
loss of clock monitoring, ... =

Power level monitoring may have a negative side effect; i.e. it may
declare a LOS condition while there is still a valid input signal. As
the STM-N signal is framed, and framing is required in every SDH
equipment interface, loss of frame (LOF) can be used as deterministic
defect indicator for protection switching and alarm suppression (AIS
insertion). LOS isn't adding any real advantage; its most important
contribution is to the fault localisation (LOS: cable break or
transmitter fail). As such, there is no real requirement for microsecond
LOS defect detection in SDH.

--------- G.783 (10/2000) ------
6.2.1.1	Loss Of Signal defect (dLOS)

STM-N optical interfaces: This parameter should take on the value
"incoming signal absent" when the incoming power level at the receiver
has dropped to a level which corresponds to a high error condition. The
purpose of monitoring this parameter is to indicate either:
i)	transmitter failure;
ii)	optical path break.
NOTE - This is a functional specification referring only to the quality
of the incoming signal. It does not necessarily imply either the
measurement of optical power or BER. The timing requirements for
detection of the LOS defect in the province of regional standards. One
example is the following: An LOS defect occurs upon detection of no
transitions on the incoming signal (before descrambling) for time T,
where 2.3 <=3D T <=3D 100 us. The LOS defect is terminated after a time
period equal to the greater of 125 ms or 2.5 T' containing no
transition-free intervals of length T', where 2.3 <=3D T' <=3D 100 us.
----------------------------------

Regards,

Maarten

sambasiva mantha wrote:
> =

> The following is the requirement for LOS on SONET as in GR-253-CORE, Is=
sue 3.
> =

>     R6-54 [416v2] A SONET NE shall monitor all incoming SONET signals
>     (before descrambling) for an =93all-zeros patterns,=94 where an all=
-zeros
>     pattern corresponds to no light pulses for OC-N optical interfaces
>     and no voltage transitions for STS-1 and STS-3 electrical interface=
s.
>     An LOS defect shall be detected when an all-zeros pattern on the
>     incoming SONET signal lasts 100 =B5s or longer. If an all-zeros pat=
tern
>     lasts 2.3 =B5s or less, an LOS defect shall not be detected.
> =

> The treatment of all-zeros patterns lasting between 2.3 =B5s and 100 =B5=
s for the
> purpose of LOS defect detection is not specified and is therefore left =
to the choice
> of the equipment designer. For testing conformance to the LOS detection=

> requirement, it is sufficient to apply an all-zeros pattern lasting at =
most 2.3 =B5s, and
> to apply an all-zeros pattern lasting at least 100 =B5s.
> =

> Sambu
> =

> Maarten Vissers wrote:
> =

> > Paul,
> >
> > "I am out there"... STM-LOS defect detection time in SDH isn't
> > specified. May take as long as e.g. 50 ms to detect the LOS defect. T=
his
> > isn't important as you already indicate; LOF will do the job to trigg=
er
> > protection switching. STM-LOF defect detection time is 3.625 ms (5
> > frames for OOF plus 24 frames for LOF).
> >
> > For the case of cable break, STM-LOF will not be reported, while STM-=
LOS
> > will be detected before the 2.5+/-0.5 seconds defect-to-failure
> > integration timer expires.
> >
> > Regards,
> >
> > Maarten
> >
> > Paul Bonenfant wrote:
> > >
> > > Jeurgen,
> > >
> > > Can't resist (apologies to all for the long message)...
> > >
> > > You wrote:
> > > >
> > > > Stacked protection/restoration:
> > > > If you use protection/restoration at an optical network layer
> > > > (server) and a SONET/SDH network layer (client) the server layer
> > > > switching times should be faster than the client layer reaction
> > > > times, so that the server layer does the protection/restoration
> > > > and the client layer doesn't react.
> > > >
> > >
> > > But as you no doubt well know, by far all the installed legacy
> > > SONET/SDH kit (that the unfortunate carriers are yearning to get
> > > rid of, and which will disappear over time...sorry, I digress...)
> > > detects:
> > > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET,
> > >   thanks to Bellcore/Telcordia GR-253, unless it's been revised),
> > > or
> > > - 375 microseconds (LOF for SDH -- Maarten please correct me if
> > >   I'm wrong, I know you're out there).
> > >
> > > So for the server (optical) layer switching time to be faster
> > > than the client (SONET/SDH) layer reaction time, the optical
> > > layer would have to restore well within, say, 1 millisecond.
> > >
> > > And, in this context, "switching time" may include (depending
> > > upon the particular flavour of optical layer protection/restoration=

> > > implemented): detection-time + signaling-time (for 1+1 bidirectiona=
l
> > > or shared protection, or restoration) + bridging&switching-time.
> > > To do all that in less than 1 msec is a tall order for any layer.
> > >
> > > Maybe I'm beating a long dead horse here, but this now aging
> > > issue of "optical layer restoration occurring faster than the
> > > SONET/SDH reaction time" keeps cropping up...for a shameless plug
> > > thinly veiled as bit of history, see:
> > > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivabilit=
y:
> > >   SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96,
> > >   Denver, CO, 1996.
> > > (If interested, reply off-list to find out how to get a copy. I kno=
w,
> > > referenced material should be posted as either an IETF draft or T1X=
1
> > > contribution to make it more readily available, sorry.)
> > >
> > > Juergen, I agree that this is an issue of concern (albeit not new).=

> > > Potential solutions to the SONET/SDH-Optical protection layer inter=
-
> > > working problem include:
> > > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps ev=
en
> > >   other layers to react to the failure...not an attractive approach=

> > >   unless chaos is an option)
> > > - Implement appropriate holdoff time(s) in one or more of the layer=
s
> > >   (again not attractive as it delays restoration if the failure
> > >   actually occurs at that layer...also, the holdoff times get
> > >   progressively longer in the higher layers)
> > > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080,
> > >   "Protected Domain Boundary Delineation," June 1997:
> > >   ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf
> > >   -- an elegant solution, but never gained any traction thanks to
> > >      the mess associated with inter-layer signaling)
> > > - Avoid direct overlay of survivability schemes with similar
> > >   restoration time-scales (tends to be what is done in practice)
> > > - Coordinate protection layer interworking via a common control pla=
ne
> > >   across all the network layers (e.g., GMPLS?), as discussed briefl=
y
> > >   (for example) in Sec 3.2.3 of:
> > >   http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.=
txt
> > > (again for the reference-minded the above discussion can be found i=
n
> > > "Optical Layer Protection and Restoration," OFC'2001 Short Course
> > > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and
> > > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999).
> > >
> > >
> > > As for the appropriate restoration time requirement...for what it's=

> > > worth, 50 msec, insofar as it remains an historical artifact, also
> > > continues to be the "psychological" bar that optical netwoking
> > > protection & restoration schemes have to meet, if for no other
> > > reason than the following, prevailing view -- "the new & improved
> > > (optical networking) technology should provide at least as good,
> > > if not better, performance than what preceded it (SONET/SDH)."
> > >
> > > Psychological bars notwithstanding, what then is the appropriate
> > > restoration time requirement?  I for one would be interested in
> > > hearing from (even more) carriers regarding which latency-sensitive=

> > > applications actually drive the 50msec-range protection/restoration=

> > > requirements (my guess: it's not (only) voice).
> > >
> > > Regards,
> > >
> > > Paul
> > >
> > > Heiles Juergen wrote:
> > > >
> > > > Curtis
> > > >
> > > >         >Then again, this is second hand, so I could be completel=
y wrong. This is not a measurement I've made myself and the SONET equipme=
nt is not something I'm familiar with ....
> > > >
> > > > you are completely wrong and I suggest you better make measurment=
s and get familiar with SONET before making such statements.. SONET/SDH e=
quipment will not shut down/drop connections. Today SONET connections are=
 permanent connections setup via the management system. An automatic drop=
 of a conneciton as it is the case for switched connections will not occu=
r. What you will see is the insertion of AIS (alarm indication signal) af=
ter the detection of an defect. But as soon as the defect is gone the AIS=
 is removed and the connection is running again. AIS is nothing harmful a=
s due to the defect the connection is interupted in any case. Furthermore=
 the AIS avoids downstream alarms (alarm storms).
> > > >
> > > > What could be of concern are the following points. I talk about a=
 server layer for a SONET/SDH network  (e.g. an Optical Network) providin=
g protection/restoration:
> > > >
> > > > Stacked protection/restoration:
> > > > If you use protection/restoration at an optical network layer (se=
rver) and a SONET/SDH network layer (client) the server layer switching t=
imes should be faster than the client layer reaction times, so that the s=
erver layer does the protection/restoration and the client layer doesn't =
react.
> > > >
> > > > Automatic power reduction/automatic laser shutdown APR/ALS
> > > > APR is used for safety reasons in order to avoid harmful emission=
 of laser light in case of a fiber cut. One implementation switches off t=
he transmit laser in case of loss of signal at the receiver. A restart ac=
tion which is triggered automatically in intervals of several seconds is =
required in order to test if the link is repaired. Normally the APR funct=
ion can be switched off if not needed. The APR function needs some carefu=
l consideration in case of protection/restoration and automatic connectio=
n setup in all optical networks.
> > > >
> > > > Regards
> > > >
> > > > Juergen
> > > >
> > > > > -----Original Message-----
> > > > > From: Curtis Villamizar [SMTP:[email-masked]]
> > > > > Sent: Monday, April 09, 2001 4:37 AM
> > > > > To:   Lazer, Monica A, NNAD
> > > > > Cc:   [email-masked]'; [email-masked]; [email-masked]; =
[email-masked]
> > > > > Subject:      restoration time requirement (was Re: Last Call o=
n RSVP Label Allocation for Backup Tunnels)
> > > > >
> > > > >
> > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04=
=2Ebm.att.com>, "L
> > > > > azer, Monica A, NNAD" writes:
> > > > > > Voice switches will drop the connections after 2.5 seconds. A=
 large number
> > > > > > of dropped calls will cause FCC reportable events, which is s=
omething that
> > > > > > US carriers need to avoid. So restoration within this time fr=
ame is needed
> > > > > > for support of trunks carrying voice traffic.
> > > > > >
> > > > > > Monica A. Lazer
> > > > > > Advanced Transport Technology and Architecture Planning
> > > > > >
> > > > > > 908 234 8462
> > > > > > [email-masked]
> > > > >
> > > > >
> > > > > Monica,
> > > > >
> > > > > We're off topic, so I changed the subject.
> > > > >
> > > > > Thanks for providing the 2.5 second figure.
> > > > >
> > > > > I've heard carrier transport people grumble about SONET equipme=
nt
> > > > > they'd be please to get rid of that will shut down even when us=
ed as
> > > > > linear SONET with no protect path and as a result would require=

> > > > > <100msec restoration.  Since there is enough of this SONET gear=
, the
> > > > > carriers can't really get rid of it although it will probably
> > > > > disappear over time and so they will make fast restoration a
> > > > > requirement of people they buy from.  To be safe, the request f=
or
> > > > > <50msec has been made.
> > > > >
> > > > > If you are not blessed with such equipment or you are able to w=
ork
> > > > > around it when doing VoIP, then you are among the fortunate.
> > > > >
> > > > > Then again, this is second hand, so I could be completely wrong=
=2E  This
> > > > > is not a measurement I've made myself and the SONET equipment i=
s not
> > > > > something I'm familiar with such that I could say with confiden=
ce that
> > > > > it could not be configured to hold on longer or to not shut dow=
n at>
> > > > > all if there was no protect.
> > > > >
> > > > > OTOH there are those who (claim to) want to configure SONET on =
some
> > > > > links but not on others and don't want a fast restoration.  The=
y want
> > > > > to be assured that restoration will occur only after it is safe=
 to
> > > > > assume that SONET restoration is not available.
> > > > >
> > > > > Curtis
--------------CEE6CC99127E9C87B3DFC78E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------CEE6CC99127E9C87B3DFC78E--

Delivery-date: Tue, 10 Apr 2001 00:42:29 -0700
From: Heiles Juergen <[email-masked]>
To: "'Paul Bonenfant'" <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Subject: RE: restoration time requirement (was Re: Last Call on RSVP  Labe lAllocation for Backup Tunnels)
Date: Tue, 10 Apr 2001 09:36:21 +0200

Curtis, Paul,

my original comment was based on the assumption that Curtis was talking about dropping a SDH/SONET connection as in the PSTN. If a connection is dropped in the PSTN you have to redial in order to establish the connection again. This is not the case for SONET/SDH networks with provisioned connections.
I agree that the defect detction times are an issue for stacked proection/restoration. That is why I used the term "reaction time" and not "switching time".

Regards

Juergen

> -----Original Message-----
> From:	Paul Bonenfant [SMTP:[email-masked]]
> Sent:	Monday, April 09, 2001 4:00 PM
> To:	Heiles Juergen
> Cc:	[email-masked]'; Lazer, Monica A, NNAD; [email-masked]'; [email-masked]; [email-masked]; [email-masked]; t1x1.5
> Subject:	Re: restoration time requirement (was Re: Last Call on RSVP  LabelAllocation for Backup Tunnels)
> 
> Jeurgen,
> 
> Can't resist (apologies to all for the long message)...
> 
> You wrote:
> >
> > Stacked protection/restoration:
> > If you use protection/restoration at an optical network layer 
> > (server) and a SONET/SDH network layer (client) the server layer 
> > switching times should be faster than the client layer reaction 
> > times, so that the server layer does the protection/restoration 
> > and the client layer doesn't react.
> > 
> 
> But as you no doubt well know, by far all the installed legacy 
> SONET/SDH kit (that the unfortunate carriers are yearning to get 
> rid of, and which will disappear over time...sorry, I digress...) 
> detects:
> - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, 
>   thanks to Bellcore/Telcordia GR-253, unless it's been revised), 
> or 
> - 375 microseconds (LOF for SDH -- Maarten please correct me if 
>   I'm wrong, I know you're out there).
> 
> So for the server (optical) layer switching time to be faster 
> than the client (SONET/SDH) layer reaction time, the optical 
> layer would have to restore well within, say, 1 millisecond.
> 
> And, in this context, "switching time" may include (depending 
> upon the particular flavour of optical layer protection/restoration
> implemented): detection-time + signaling-time (for 1+1 bidirectional
> or shared protection, or restoration) + bridging&switching-time.
> To do all that in less than 1 msec is a tall order for any layer.
>   
> Maybe I'm beating a long dead horse here, but this now aging
> issue of "optical layer restoration occurring faster than the
> SONET/SDH reaction time" keeps cropping up...for a shameless plug
> thinly veiled as bit of history, see:
> - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: 
>   SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, 
>   Denver, CO, 1996.
> (If interested, reply off-list to find out how to get a copy. I know,
> referenced material should be posted as either an IETF draft or T1X1 
> contribution to make it more readily available, sorry.)
> 
> Juergen, I agree that this is an issue of concern (albeit not new).
> Potential solutions to the SONET/SDH-Optical protection layer inter-
> working problem include:
> - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even
>   other layers to react to the failure...not an attractive approach 
>   unless chaos is an option)
> - Implement appropriate holdoff time(s) in one or more of the layers 
>   (again not attractive as it delays restoration if the failure 
>   actually occurs at that layer...also, the holdoff times get 
>   progressively longer in the higher layers)
> - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, 
>   "Protected Domain Boundary Delineation," June 1997:
>   ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf
>   -- an elegant solution, but never gained any traction thanks to 
>      the mess associated with inter-layer signaling) 
> - Avoid direct overlay of survivability schemes with similar 
>   restoration time-scales (tends to be what is done in practice)> 
> - Coordinate protection layer interworking via a common control plane 
>   across all the network layers (e.g., GMPLS?), as discussed briefly 
>   (for example) in Sec 3.2.3 of:
>   http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt
> (again for the reference-minded the above discussion can be found in 
> "Optical Layer Protection and Restoration," OFC'2001 Short Course 
> SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and 
> Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). 
>   
> 
> As for the appropriate restoration time requirement...for what it's
> worth, 50 msec, insofar as it remains an historical artifact, also
> continues to be the "psychological" bar that optical netwoking 
> protection & restoration schemes have to meet, if for no other 
> reason than the following, prevailing view -- "the new & improved 
> (optical networking) technology should provide at least as good, 
> if not better, performance than what preceded it (SONET/SDH)."   
> 
> Psychological bars notwithstanding, what then is the appropriate 
> restoration time requirement?  I for one would be interested in 
> hearing from (even more) carriers regarding which latency-sensitive 
> applications actually drive the 50msec-range protection/restoration 
> requirements (my guess: it's not (only) voice).
> 
> Regards,
> 
> Paul   
> 
> Heiles Juergen wrote:
> > 
> > Curtis
> > 
> >         >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with ....
> > 
> > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms).
> > 
> > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network  (e.g. an Optical Network) providing protection/restoration:
> > 
> > Stacked protection/restoration:
> > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react.
> > 
> > Automatic power reduction/automatic laser shutdown APR/ALS
> > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks.
> > 
> > Regards
> > 
> > Juergen
> > 
> > > -----Original Message-----
> > > From: Curtis Villamizar [SMTP:[email-masked]]
> > > Sent: Monday, April 09, 2001 4:37 AM
> > > To:   Lazer, Monica A, NNAD
> > > Cc:   [email-masked]'; [email-masked]; [email-masked]; [email-masked]
> > > Subject:      restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
> > >
> > >
> > > In message <[email-masked]>, "L> 
> > > azer, Monica A, NNAD" w> rites:
> > > > Voice switches will drop the connections after 2.5 seconds. A large number
> > > > of dropped calls will cause FCC reportable events, which is something that
> > > > US carriers need to avoid. So restoration within this time frame is needed
> > > > for support of trunks carrying voice traffic.
> > > >
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > [email-masked]
> > >
> > >
> > > Monica,
> > >
> > > We're off topic, so I changed the subject.
> > >
> > > Thanks for providing the 2.5 second figure.
> > >
> > > I've heard carrier transport people grumble about SONET equipment
> > > they'd be please to get rid of that will shut down even when used as
> > > linear SONET with no protect path and as a result would require
> > > <100msec restoration.  Since there is enough of this SONET gear, the
> > > carriers can't really get rid of it although it will probably
> > > disappear over time and so they will make fast restoration a
> > > requirement of people they buy from.  To be safe, the request for
> > > <50msec has been made.
> > >
> > > If you are not blessed with such equipment or you are able to work
> > > around it when doing VoIP, then you are among the fortunate.
> > >
> > > Then again, this is second hand, so I could be completely wrong.  This
> > > is not a measurement I've made myself and the SONET equipment is not
> > > something I'm familiar with such that I could say with confidence that
> > > it could not be configured to hold on longer or to not shut down at>
> > > all if there was no protect.
> > >
> > > OTOH there are those who (claim to) want to configure SONET on some
> > > links but not on others and don't want a fast restoration.  They want
> > > to be assured that restoration will occur only after it is safe to
> > > assume that SONET restoration is not available.
> > >
> > > Curtis

Delivery-date: Mon, 09 Apr 2001 08:36:03 -0700
Date: Mon, 09 Apr 2001 10:33:01 -0500
From: sambasiva mantha <[email-masked]>
Organization: Alcatel
To: Maarten Vissers <[email-masked]>
CC: Paul Bonenfant <[email-masked]>, "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Subject: Re: restoration time requirement (was Re: Last Call on RSVP  LabelAllocation for Backup Tunnels)

The following is the requirement for LOS on SONET as in GR-253-CORE, Issue 3.

    R6-54 [416v2] A SONET NE shall monitor all incoming SONET signals
    (before descrambling) for an “all-zeros patterns,” where an all-zeros
    pattern corresponds to no light pulses for OC-N optical interfaces
    and no voltage transitions for STS-1 and STS-3 electrical interfaces.
    An LOS defect shall be detected when an all-zeros pattern on the
    incoming SONET signal lasts 100 µs or longer. If an all-zeros pattern
    lasts 2.3 µs or less, an LOS defect shall not be detected.

The treatment of all-zeros patterns lasting between 2.3 µs and 100 µs for the
purpose of LOS defect detection is not specified and is therefore left to the choice
of the equipment designer. For testing conformance to the LOS detection
requirement, it is sufficient to apply an all-zeros pattern lasting at most 2.3 µs, and
to apply an all-zeros pattern lasting at least 100 µs.

Sambu

Maarten Vissers wrote:

> Paul,
>
> "I am out there"... STM-LOS defect detection time in SDH isn't
> specified. May take as long as e.g. 50 ms to detect the LOS defect. This
> isn't important as you already indicate; LOF will do the job to trigger
> protection switching. STM-LOF defect detection time is 3.625 ms (5
> frames for OOF plus 24 frames for LOF).
>
> For the case of cable break, STM-LOF will not be reported, while STM-LOS
> will be detected before the 2.5+/-0.5 seconds defect-to-failure
> integration timer expires.
>
> Regards,
>
> Maarten
>
> Paul Bonenfant wrote:
> >
> > Jeurgen,
> >
> > Can't resist (apologies to all for the long message)...
> >
> > You wrote:
> > >
> > > Stacked protection/restoration:
> > > If you use protection/restoration at an optical network layer
> > > (server) and a SONET/SDH network layer (client) the server layer
> > > switching times should be faster than the client layer reaction
> > > times, so that the server layer does the protection/restoration
> > > and the client layer doesn't react.
> > >
> >
> > But as you no doubt well know, by far all the installed legacy
> > SONET/SDH kit (that the unfortunate carriers are yearning to get
> > rid of, and which will disappear over time...sorry, I digress...)
> > detects:
> > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET,
> >   thanks to Bellcore/Telcordia GR-253, unless it's been revised),
> > or
> > - 375 microseconds (LOF for SDH -- Maarten please correct me if
> >   I'm wrong, I know you're out there).
> >
> > So for the server (optical) layer switching time to be faster
> > than the client (SONET/SDH) layer reaction time, the optical
> > layer would have to restore well within, say, 1 millisecond.
> >
> > And, in this context, "switching time" may include (depending
> > upon the particular flavour of optical layer protection/restoration
> > implemented): detection-time + signaling-time (for 1+1 bidirectional
> > or shared protection, or restoration) + bridging&switching-time.
> > To do all that in less than 1 msec is a tall order for any layer.
> >
> > Maybe I'm beating a long dead horse here, but this now aging
> > issue of "optical layer restoration occurring faster than the
> > SONET/SDH reaction time" keeps cropping up...for a shameless plug
> > thinly veiled as bit of history, see:
> > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability:
> >   SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96,
> >   Denver, CO, 1996.
> > (If interested, reply off-list to find out how to get a copy. I know,
> > referenced material should be posted as either an IETF draft or T1X1
> > contribution to make it more readily available, sorry.)
> >
> > Juergen, I agree that this is an issue of concern (albeit not new).
> > Potential solutions to the SONET/SDH-Optical protection layer inter-
> > working problem include:
> > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even
> >   other layers to react to the failure...not an attractive approach
> >   unless chaos is an option)
> > - Implement appropriate holdoff time(s) in one or more of the layers
> >   (again not attractive as it delays restoration if the failure
> >   actually occurs at that layer...also, the holdoff times get
> >   progressively longer in the higher layers)
> > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080,
> >   "Protected Domain Boundary Delineation," June 1997:
> >   ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf
> >   -- an elegant solution, but never gained any traction thanks to
> >      the mess associated with inter-layer signaling)
> > - Avoid direct overlay of survivability schemes with similar
> >   restoration time-scales (tends to be what is done in practice)
> > - Coordinate protection layer interworking via a common control plane
> >   across all the network layers (e.g., GMPLS?), as discussed briefly
> >   (for example) in Sec 3.2.3 of:
> >   http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt
> > (again for the reference-minded the above discussion can be found in
> > "Optical Layer Protection and Restoration," OFC'2001 Short Course
> > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and
> > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999).
> >
> >
> > As for the appropriate restoration time requirement...for what it's
> > worth, 50 msec, insofar as it remains an historical artifact, also
> > continues to be the "psychological" bar that optical netwoking
> > protection & restoration schemes have to meet, if for no other
> > reason than the following, prevailing view -- "the new & improved
> > (optical networking) technology should provide at least as good,
> > if not better, performance than what preceded it (SONET/SDH)."
> >
> > Psychological bars notwithstanding, what then is the appropriate
> > restoration time requirement?  I for one would be interested in
> > hearing from (even more) carriers regarding which latency-sensitive
> > applications actually drive the 50msec-range protection/restoration
> > requirements (my guess: it's not (only) voice).
> >
> > Regards,
> >
> > Paul
> >
> > Heiles Juergen wrote:
> > >
> > > Curtis
> > >
> > >         >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with ....
> > >
> > > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms).
> > >
> > > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network  (e.g. an Optical Network) providing protection/restoration:
> > >
> > > Stacked protection/restoration:
> > > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react.
> > >
> > > Automatic power reduction/automatic laser shutdown APR/ALS
> > > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [SMTP:[email-masked]]
> > > > Sent: Monday, April 09, 2001 4:37 AM
> > > > To:   Lazer, Monica A, NNAD
> > > > Cc:   [email-masked]'; [email-masked]; [email-masked]; [email-masked]
> > > > Subject:      restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
> > > >
> > > >
> > > > In message <[email-masked]>, "L
> > > > azer, Monica A, NNAD" writes:
> > > > > Voice switches will drop the connections after 2.5 seconds. A large number
> > > > > of dropped calls will cause FCC reportable events, which is something that
> > > > > US carriers need to avoid. So restoration within this time frame is needed
> > > > > for support of trunks carrying voice traffic.
> > > > >
> > > > > Monica A. Lazer
> > > > > Advanced Transport Technology and Architecture Planning
> > > > >
> > > > > 908 234 8462
> > > > > [email-masked]
> > > >
> > > >
> > > > Monica,
> > > >
> > > > We're off topic, so I changed the subject.
> > > >
> > > > Thanks for providing the 2.5 second figure.
> > > >
> > > > I've heard carrier transport people grumble about SONET equipment
> > > > they'd be please to get rid of that will shut down even when used as
> > > > linear SONET with no protect path and as a result would require
> > > > <100msec restoration.  Since there is enough of this SONET gear, the
> > > > carriers can't really get rid of it although it will probably
> > > > disappear over time and so they will make fast restoration a
> > > > requirement of people they buy from.  To be safe, the request for
> > > > <50msec has been made.
> > > >
> > > > If you are not blessed with such equipment or you are able to work
> > > > around it when doing VoIP, then you are among the fortunate.
> > > >
> > > > Then again, this is second hand, so I could be completely wrong.  This
> > > > is not a measurement I've made myself and the SONET equipment is not
> > > > something I'm familiar with such that I could say with confidence that
> > > > it could not be configured to hold on longer or to not shut down at>
> > > > all if there was no protect.
> > > >
> > > > OTOH there are those who (claim to) want to configure SONET on some
> > > > links but not on others and don't want a fast restoration.  They want
> > > > to be assured that restoration will occur only after it is safe to
> > > > assume that SONET restoration is not available.
> > > >
> > > > Curtis

Delivery-date: Mon, 09 Apr 2001 07:32:22 -0700
Cc: "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Date: Mon, 09 Apr 2001 16:30:32 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Paul Bonenfant <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Subject: Re: restoration time requirement (was Re: Last Call on RSVP  LabelAllocation for Backup Tunnels)

This is a multi-part message in MIME format.
--------------45CF9ABE6176ECF7B8CA71D5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

"I am out there"... STM-LOS defect detection time in SDH isn't
specified. May take as long as e.g. 50 ms to detect the LOS defect. This
isn't important as you already indicate; LOF will do the job to trigger
protection switching. STM-LOF defect detection time is 3.625 ms (5
frames for OOF plus 24 frames for LOF). 

For the case of cable break, STM-LOF will not be reported, while STM-LOS
will be detected before the 2.5+/-0.5 seconds defect-to-failure
integration timer expires.

Regards,

Maarten

Paul Bonenfant wrote:
> 
> Jeurgen,
> 
> Can't resist (apologies to all for the long message)...
> 
> You wrote:
> >
> > Stacked protection/restoration:
> > If you use protection/restoration at an optical network layer
> > (server) and a SONET/SDH network layer (client) the server layer
> > switching times should be faster than the client layer reaction
> > times, so that the server layer does the protection/restoration
> > and the client layer doesn't react.
> >
> 
> But as you no doubt well know, by far all the installed legacy
> SONET/SDH kit (that the unfortunate carriers are yearning to get
> rid of, and which will disappear over time...sorry, I digress...)
> detects:
> - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET,
>   thanks to Bellcore/Telcordia GR-253, unless it's been revised),
> or
> - 375 microseconds (LOF for SDH -- Maarten please correct me if
>   I'm wrong, I know you're out there).
> 
> So for the server (optical) layer switching time to be faster
> than the client (SONET/SDH) layer reaction time, the optical
> layer would have to restore well within, say, 1 millisecond.
> 
> And, in this context, "switching time" may include (depending
> upon the particular flavour of optical layer protection/restoration
> implemented): detection-time + signaling-time (for 1+1 bidirectional
> or shared protection, or restoration) + bridging&switching-time.
> To do all that in less than 1 msec is a tall order for any layer.
> 
> Maybe I'm beating a long dead horse here, but this now aging
> issue of "optical layer restoration occurring faster than the
> SONET/SDH reaction time" keeps cropping up...for a shameless plug
> thinly veiled as bit of history, see:
> - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability:
>   SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96,
>   Denver, CO, 1996.
> (If interested, reply off-list to find out how to get a copy. I know,
> referenced material should be posted as either an IETF draft or T1X1
> contribution to make it more readily available, sorry.)
> 
> Juergen, I agree that this is an issue of concern (albeit not new).
> Potential solutions to the SONET/SDH-Optical protection layer inter-
> working problem include:
> - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even
>   other layers to react to the failure...not an attractive approach
>   unless chaos is an option)
> - Implement appropriate holdoff time(s) in one or more of the layers
>   (again not attractive as it delays restoration if the failure
>   actually occurs at that layer...also, the holdoff times get
>   progressively longer in the higher layers)
> - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080,
>   "Protected Domain Boundary Delineation," June 1997:
>   ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf
>   -- an elegant solution, but never gained any traction thanks to
>      the mess associated with inter-layer signaling)
> - Avoid direct overlay of survivability schemes with similar
>   restoration time-scales (tends to be what is done in practice)
> - Coordinate protection layer interworking via a common control plane
>   across all the network layers (e.g., GMPLS?), as discussed briefly
>   (for example) in Sec 3.2.3 of:
>   http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt
> (again for the reference-minded the above discussion can be found in
> "Optical Layer Protection and Restoration," OFC'2001 Short Course
> SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and
> Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999).
> 
> 
> As for the appropriate restoration time requirement...for what it's
> worth, 50 msec, insofar as it remains an historical artifact, also
> continues to be the "psychological" bar that optical netwoking
> protection & restoration schemes have to meet, if for no other
> reason than the following, prevailing view -- "the new & improved
> (optical networking) technology should provide at least as good,
> if not better, performance than what preceded it (SONET/SDH)."
> 
> Psychological bars notwithstanding, what then is the appropriate
> restoration time requirement?  I for one would be interested in
> hearing from (even more) carriers regarding which latency-sensitive
> applications actually drive the 50msec-range protection/restoration
> requirements (my guess: it's not (only) voice).
> 
> Regards,
> 
> Paul
> 
> Heiles Juergen wrote:
> >
> > Curtis
> >
> >         >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with ....
> >
> > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms).
> >
> > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network  (e.g. an Optical Network) providing protection/restoration:
> >
> > Stacked protection/restoration:
> > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react.
> >
> > Automatic power reduction/automatic laser shutdown APR/ALS
> > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks.
> >
> > Regards
> >
> > Juergen
> >
> > > -----Original Message-----
> > > From: Curtis Villamizar [SMTP:[email-masked]]
> > > Sent: Monday, April 09, 2001 4:37 AM
> > > To:   Lazer, Monica A, NNAD
> > > Cc:   [email-masked]'; [email-masked]; [email-masked]; [email-masked]
> > > Subject:      restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
> > >
> > >
> > > In message <[email-masked]>, "L
> > > azer, Monica A, NNAD" writes:
> > > > Voice switches will drop the connections after 2.5 seconds. A large number
> > > > of dropped calls will cause FCC reportable events, which is something that
> > > > US carriers need to avoid. So restoration within this time frame is needed
> > > > for support of trunks carrying voice traffic.
> > > >
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > [email-masked]
> > >
> > >
> > > Monica,
> > >
> > > We're off topic, so I changed the subject.
> > >
> > > Thanks for providing the 2.5 second figure.
> > >
> > > I've heard carrier transport people grumble about SONET equipment
> > > they'd be please to get rid of that will shut down even when used as
> > > linear SONET with no protect path and as a result would require
> > > <100msec restoration.  Since there is enough of this SONET gear, the
> > > carriers can't really get rid of it although it will probably
> > > disappear over time and so they will make fast restoration a
> > > requirement of people they buy from.  To be safe, the request for
> > > <50msec has been made.
> > >
> > > If you are not blessed with such equipment or you are able to work
> > > around it when doing VoIP, then you are among the fortunate.
> > >
> > > Then again, this is second hand, so I could be completely wrong.  This
> > > is not a measurement I've made myself and the SONET equipment is not
> > > something I'm familiar with such that I could say with confidence that
> > > it could not be configured to hold on longer or to not shut down at>
> > > all if there was no protect.
> > >
> > > OTOH there are those who (claim to) want to configure SONET on some
> > > links but not on others and don't want a fast restoration.  They want
> > > to be assured that restoration will occur only after it is safe to
> > > assume that SONET restoration is not available.
> > >
> > > Curtis
--------------45CF9ABE6176ECF7B8CA71D5
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------45CF9ABE6176ECF7B8CA71D5--

Delivery-date: Mon, 09 Apr 2001 07:00:30 -0700
Date: Mon, 09 Apr 2001 09:59:44 -0400
From: Paul Bonenfant <[email-masked]>
To: Heiles Juergen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>
Subject: Re: restoration time requirement (was Re: Last Call on RSVP  LabelAllocation for Backup Tunnels)

Jeurgen,

Can't resist (apologies to all for the long message)...

You wrote:
>
> Stacked protection/restoration:
> If you use protection/restoration at an optical network layer 
> (server) and a SONET/SDH network layer (client) the server layer 
> switching times should be faster than the client layer reaction 
> times, so that the server layer does the protection/restoration 
> and the client layer doesn't react.
> 

But as you no doubt well know, by far all the installed legacy 
SONET/SDH kit (that the unfortunate carriers are yearning to get 
rid of, and which will disappear over time...sorry, I digress...) 
detects:
- LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, 
  thanks to Bellcore/Telcordia GR-253, unless it's been revised), 
or 
- 375 microseconds (LOF for SDH -- Maarten please correct me if 
  I'm wrong, I know you're out there).

So for the server (optical) layer switching time to be faster 
than the client (SONET/SDH) layer reaction time, the optical 
layer would have to restore well within, say, 1 millisecond.

And, in this context, "switching time" may include (depending 
upon the particular flavour of optical layer protection/restoration
implemented): detection-time + signaling-time (for 1+1 bidirectional
or shared protection, or restoration) + bridging&switching-time.
To do all that in less than 1 msec is a tall order for any layer.
  
Maybe I'm beating a long dead horse here, but this now aging
issue of "optical layer restoration occurring faster than the
SONET/SDH reaction time" keeps cropping up...for a shameless plug
thinly veiled as bit of history, see:
- J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: 
  SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, 
  Denver, CO, 1996.
(If interested, reply off-list to find out how to get a copy. I know,
referenced material should be posted as either an IETF draft or T1X1 
contribution to make it more readily available, sorry.)

Juergen, I agree that this is an issue of concern (albeit not new).
Potential solutions to the SONET/SDH-Optical protection layer inter-
working problem include:
- Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even
  other layers to react to the failure...not an attractive approach 
  unless chaos is an option)
- Implement appropriate holdoff time(s) in one or more of the layers 
  (again not attractive as it delays restoration if the failure 
  actually occurs at that layer...also, the holdoff times get 
  progressively longer in the higher layers)
- Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, 
  "Protected Domain Boundary Delineation," June 1997:
  ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf
  -- an elegant solution, but never gained any traction thanks to 
     the mess associated with inter-layer signaling) 
- Avoid direct overlay of survivability schemes with similar 
  restoration time-scales (tends to be what is done in practice)
- Coordinate protection layer interworking via a common control plane 
  across all the network layers (e.g., GMPLS?), as discussed briefly 
  (for example) in Sec 3.2.3 of:
  http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt
(again for the reference-minded the above discussion can be found in 
"Optical Layer Protection and Restoration," OFC'2001 Short Course 
SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and 
Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). 

As for the appropriate restoration time requirement...for what it's
worth, 50 msec, insofar as it remains an historical artifact, also
continues to be the "psychological" bar that optical netwoking 
protection & restoration schemes have to meet, if for no other 
reason than the following, prevailing view -- "the new & improved 
(optical networking) technology should provide at least as good, 
if not better, performance than what preceded it (SONET/SDH)."   

Psychological bars notwithstanding, what then is the appropriate 
restoration time requirement?  I for one would be interested in 
hearing from (even more) carriers regarding which latency-sensitive 
applications actually drive the 50msec-range protection/restoration 
requirements (my guess: it's not (only) voice).

Regards,

Paul   

Heiles Juergen wrote:
> 
> Curtis
> 
>         >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with ....
> 
> you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms).
> 
> What could be of concern are the following points. I talk about a server layer for a SONET/SDH network  (e.g. an Optical Network) providing protection/restoration:
> 
> Stacked protection/restoration:
> If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react.
> 
> Automatic power reduction/automatic laser shutdown APR/ALS
> APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Curtis Villamizar [SMTP:[email-masked]]
> > Sent: Monday, April 09, 2001 4:37 AM
> > To:   Lazer, Monica A, NNAD
> > Cc:   [email-masked]'; [email-masked]; [email-masked]; [email-masked]
> > Subject:      restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
> >
> >
> > In message <[email-masked]>, "L
> > azer, Monica A, NNAD" writes:
> > > Voice switches will drop the connections after 2.5 seconds. A large number
> > > of dropped calls will cause FCC reportable events, which is something that
> > > US carriers need to avoid. So restoration within this time frame is needed
> > > for support of trunks carrying voice traffic.
> > >
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > [email-masked]
> >
> >
> > Monica,
> >
> > We're off topic, so I changed the subject.
> >
> > Thanks for providing the 2.5 second figure.
> >
> > I've heard carrier transport people grumble about SONET equipment
> > they'd be please to get rid of that will shut down even when used as
> > linear SONET with no protect path and as a result would require
> > <100msec restoration.  Since there is enough of this SONET gear, the
> > carriers can't really get rid of it although it will probably
> > disappear over time and so they will make fast restoration a
> > requirement of people they buy from.  To be safe, the request for
> > <50msec has been made.
> >
> > If you are not blessed with such equipment or you are able to work
> > around it when doing VoIP, then you are among the fortunate.
> >
> > Then again, this is second hand, so I could be completely wrong.  This
> > is not a measurement I've made myself and the SONET equipment is not
> > something I'm familiar with such that I could say with confidence that
> > it could not be configured to hold on longer or to not shut down at>
> > all if there was no protect.
> >
> > OTOH there are those who (claim to) want to configure SONET on some
> > links but not on others and don't want a fast restoration.  They want
> > to be assured that restoration will occur only after it is safe to
> > assume that SONET restoration is not available.
> >
> > Curtis

Delivery-date: Mon, 09 Apr 2001 00:56:58 -0700
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
Date: Mon, 9 Apr 2001 09:52:20 +0200 

Curtis

	>Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... 

you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms).

What could be of concern are the following points. I talk about a server layer for a SONET/SDH network  (e.g. an Optical Network) providing protection/restoration:

Stacked protection/restoration:
If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react.

Automatic power reduction/automatic laser shutdown APR/ALS
APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks.

Regards

Juergen

> -----Original Message-----
> From:	Curtis Villamizar [SMTP:[email-masked]]
> Sent:	Monday, April 09, 2001 4:37 AM
> To:	Lazer, Monica A, NNAD
> Cc:	[email-masked]'; [email-masked]; [email-masked]; [email-masked]
> Subject:	restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels)
> 
> 
> In message <[email-masked]>, "L
> azer, Monica A, NNAD" writes:
> > Voice switches will drop the connections after 2.5 seconds. A large number
> > of dropped calls will cause FCC reportable events, which is something that
> > US carriers need to avoid. So restoration within this time frame is needed
> > for support of trunks carrying voice traffic.
> > 
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> > 
> > 908 234 8462
> > [email-masked]
> 
> 
> Monica,
> 
> We're off topic, so I changed the subject.
> 
> Thanks for providing the 2.5 second figure.
> 
> I've heard carrier transport people grumble about SONET equipment
> they'd be please to get rid of that will shut down even when used as
> linear SONET with no protect path and as a result would require
> <100msec restoration.  Since there is enough of this SONET gear, the
> carriers can't really get rid of it although it will probably
> disappear over time and so they will make fast restoration a
> requirement of people they buy from.  To be safe, the request for
> <50msec has been made.
> 
> If you are not blessed with such equipment or you are able to work
> around it when doing VoIP, then you are among the fortunate.
> 
> Then again, this is second hand, so I could be completely wrong.  This
> is not a measurement I've made myself and the SONET equipment is not
> something I'm familiar with such that I could say with confidence that
> it could not be configured to hold on longer or to not shut down at> 
> all if there was no protect.
>  
> OTOH there are those who (claim to) want to configure SONET on some
> links but not on others and don't want a fast restoration.  They want
> to be assured that restoration will occur only after it is safe to
> assume that SONET restoration is not available.
> 
> Curtis

Delivery-date: Fri, 06 Apr 2001 08:53:01 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
Date: Fri, 6 Apr 2001 16:19:34 +0100 

Can I check please Monica/Rolando.....I assume the issue is *not* voice per
se (ie not a function of the application) but perhaps something to do with
*some* signalling protocol?  In which case the ideal would be to make the
signalling protocol more robust....but I suspect this will not be possible.

neil

> -----Original Message-----
> From: Zappacosta Rolando Jorge [mailto:[email-masked]]
> Sent: 06 April 2001 13:58
> To: 'Lazer, Monica A, NNAD'; [email-masked]'; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
> 
> 
> I agree, this is the same everywhere. I've been looking at 
> these mails with
> interest because this may be an issue in the NGNs backbones.
> Take also into account that the disruption may be not enough 
> to drop calls
> but to cause a voice quality degradation incompatible with 
> the desired one,
> so the less the down time, the happier the service providers will be.
> 
> 
> > -----Mensaje original-----
> > De:	Lazer, Monica A, NNAD [SMTP:[email-masked]]
> > Enviado el:	Viernes 6 de Abril de 2001 09:02
> > Para:	[email-masked]'; [email-masked]
> > CC:	[email-masked]; [email-masked]
> > Asunto:	RE: Last Call on RSVP Label Allocation for 
> Backup Tunnels
> > 
> > Voice switches will drop the connections after 2.5 seconds. 
> A large number
> > of dropped calls will cause FCC reportable events, which is 
> something that
> > US carriers need to avoid. So restoration within this time 
> frame is needed
> > for support of trunks carrying voice traffic.
> > 
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
<snipped to end>

Delivery-date: Fri, 06 Apr 2001 08:17:57 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], "Mak, L (Leen)" <[email-masked]>
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
Date: Fri, 6 Apr 2001 17:15:48 +0200 

There are (used to be?) voice switches in the PSTN which
start dropping calls within 100 ms after loosing a trunk. 
This was at least one of the reasons for the 50 ms figure 
found in SDH specs. If the trunk is carried on an STM16, 
you could loose >32k calls because of a cable cut. Some 
operators do not like that.

Leen Mak

> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 14:02
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
> 
> 
> Voice switches will drop the connections after 2.5 seconds. A 
> large number
> of dropped calls will cause FCC reportable events, which is 
> something that
> US carriers need to avoid. So restoration within this time 
> frame is needed
> for support of trunks carrying voice traffic.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 5:19 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
> 
> Robert Raszuk [mailto:[email-masked]] wrote 01 April 2001 09:02
> > Giles,
> >
> > > > For the user-plane, the failure modes which must be
> > considered/defined are:
> > > > -       simple below MPLS fabric server layer 
> connectivity breaks;
> > > > -       simple within MPLS fabric connectivity breaks (at
> > or below the LSP
> > > > level considered);
> > >
> > > Both of these will be detected by the RSVP signalling, won't they?
> >
> > Sure but the question is when ?
> >
> > Do you think that RSVP Error/Tear msgs will travel
> > immediately - case of
> > link failure or are you proposing to run RSVP refresh in 
> the interval
> > less then 1 sec - to detect the case of node failure ? The
> > point is that
> > this draft is not about detection, but about backup LSP setup
> > and label
> > allocation under the __local__ protection scheme. So let's 
> talk on the
> > subject here.
> >
> > If one questions the use of local protection all together
> > please specify
> > how else you will achive the same results of even less then 1
> > sec end to
> > end traffic disruption with end to end protection under both
> > link & node
> > failures for the TE- LSP ?
> NH=> Fair point Robert.....but it still leaves me wondering:
> 1       Why do we need such fast action......voice surely 
> does not need few
> 10s ms restoration, 1-3s would be fine I feel sure (for the 
> relatively rare
> case of failure......unless, perhaps, one expects such 
> failures to occur on
> a very frequent basis)?
> BTW- I suspect the biggest source of 'disruptions' will be 
> planned-works by
> operators at L1, ie pre-meditiated re-routing of 
> traffic.....so some care
> should be taken that such actions don't invoke unecessary 
> actions in higher
> layers.
> 2       Where are the failures referenced specified?  Have 
> Cisco their own
> specifications for this?  We would really like to see these 
> specified in
> some standard manner.
> 
> thanks/regards, neil
> 

Delivery-date: Fri, 06 Apr 2001 05:05:56 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
Date: Fri, 6 Apr 2001 08:01:35 -0400 

Voice switches will drop the connections after 2.5 seconds. A large number
of dropped calls will cause FCC reportable events, which is something that
US carriers need to avoid. So restoration within this time frame is needed
for support of trunks carrying voice traffic.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 02, 2001 5:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels

Robert Raszuk [mailto:[email-masked]] wrote 01 April 2001 09:02
> Giles,
>
> > > For the user-plane, the failure modes which must be
> considered/defined are:
> > > -       simple below MPLS fabric server layer connectivity breaks;
> > > -       simple within MPLS fabric connectivity breaks (at
> or below the LSP
> > > level considered);
> >
> > Both of these will be detected by the RSVP signalling, won't they?
>
> Sure but the question is when ?
>
> Do you think that RSVP Error/Tear msgs will travel
> immediately - case of
> link failure or are you proposing to run RSVP refresh in the interval
> less then 1 sec - to detect the case of node failure ? The
> point is that
> this draft is not about detection, but about backup LSP setup
> and label
> allocation under the __local__ protection scheme. So let's talk on the
> subject here.
>
> If one questions the use of local protection all together
> please specify
> how else you will achive the same results of even less then 1
> sec end to
> end traffic disruption with end to end protection under both
> link & node
> failures for the TE- LSP ?
NH=> Fair point Robert.....but it still leaves me wondering:
1       Why do we need such fast action......voice surely does not need few
10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare
case of failure......unless, perhaps, one expects such failures to occur on
a very frequent basis)?
BTW- I suspect the biggest source of 'disruptions' will be planned-works by
operators at L1, ie pre-meditiated re-routing of traffic.....so some care
should be taken that such actions don't invoke unecessary actions in higher
layers.
2       Where are the failures referenced specified?  Have Cisco their own
specifications for this?  We would really like to see these specified in
some standard manner.

thanks/regards, neil

Delivery-date: Wed, 04 Apr 2001 11:49:08 -0700
Date: Wed, 04 Apr 2001 14:47:33 -0400
To: Tim Hall <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: GMPLS MIBs

         Hi Tim,

         We are working on extensions to these MIBs
at the present time, and welcome your feedback. Please
email us your suggestions.

         --Tom

>We have some GMPLS extensions to the existing MPLS MIBs, and these
>extensions are being implemented by a large number of optical equipment
>vendors.  Are there any plans to extend the current MIBs? - we'd like to
>co-operate in producing a draft.
>
>Regards,
>Tim
>
>Tim Hall
>MPLS Development Manager, Network Convergence Group
>Data Connection Ltd
>Tel:   +44 20 8366 1177            Fax:  +44 20 8363 1468
>mailto:[email-masked]  Web:  http://www.dataconnection.com

Delivery-date: Wed, 04 Apr 2001 11:14:29 -0700
From: Tim Hall <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: GMPLS MIBs
Date: Wed, 4 Apr 2001 19:11:36 +0100 

Hi,

We have some GMPLS extensions to the existing MPLS MIBs, and these
extensions are being implemented by a large number of optical equipment
vendors.  Are there any plans to extend the current MIBs? - we'd like to
co-operate in producing a draft.

Regards,
Tim

Tim Hall
MPLS Development Manager, Network Convergence Group
Data Connection Ltd
Tel:   +44 20 8366 1177            Fax:  +44 20 8363 1468
mailto:[email-masked]  Web:  http://www.dataconnection.com

Delivery-date: Tue, 03 Apr 2001 05:30:19 -0700
Date: Tue, 03 Apr 2001 05:25:22 -0700
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

Hi Neil,

> > If one questions the use of local protection all together
> > please specify
> > how else you will achive the same results of even less then 1
> > sec end to
> > end traffic disruption with end to end protection under both
> > link & node
> > failures for the TE- LSP ?
>
> NH=> Fair point Robert.....but it still leaves me wondering:
> 1       Why do we need such fast action......voice surely does not need few
> 10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare
> case of failure......unless, perhaps, one expects such failures to occur on
> a very frequent basis)?
> BTW- I suspect the biggest source of 'disruptions' will be planned-works by
> operators at L1, ie pre-meditiated re-routing of traffic.....so some care
> should be taken that such actions don't invoke unecessary actions in higher
> layers.

Well 10s of ms is just that with local link protection we get it for
free. It would be quite artificial to try to slow this down :). For node
protection sure one can reduce the detection frequency to make it
slower. I think vendors will support knob to do this if one desire.

> 2       Where are the failures referenced specified?  Have Cisco their own
> specifications for this?  We would really like to see these specified in
> some standard manner.

I understand but I don't have any pointer to the formal detailed
specification of failure cases which would be addressed by local
protection. 

R.

Delivery-date: Mon, 02 Apr 2001 02:22:34 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
Date: Mon, 2 Apr 2001 10:19:07 +0100 

Robert Raszuk [mailto:[email-masked]] wrote 01 April 2001 09:02
> Giles,
> 
> > > For the user-plane, the failure modes which must be 
> considered/defined are:
> > > -       simple below MPLS fabric server layer connectivity breaks;
> > > -       simple within MPLS fabric connectivity breaks (at 
> or below the LSP
> > > level considered);
> > 
> > Both of these will be detected by the RSVP signalling, won't they?
> 
> Sure but the question is when ? 
> 
> Do you think that RSVP Error/Tear msgs will travel 
> immediately - case of
> link failure or are you proposing to run RSVP refresh in the interval
> less then 1 sec - to detect the case of node failure ? The 
> point is that
> this draft is not about detection, but about backup LSP setup 
> and label
> allocation under the __local__ protection scheme. So let's talk on the
> subject here. 
> 
> If one questions the use of local protection all together 
> please specify
> how else you will achive the same results of even less then 1 
> sec end to
> end traffic disruption with end to end protection under both 
> link & node
> failures for the TE- LSP ? 
NH=> Fair point Robert.....but it still leaves me wondering:
1	Why do we need such fast action......voice surely does not need few
10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare
case of failure......unless, perhaps, one expects such failures to occur on
a very frequent basis)?
BTW- I suspect the biggest source of 'disruptions' will be planned-works by
operators at L1, ie pre-meditiated re-routing of traffic.....so some care
should be taken that such actions don't invoke unecessary actions in higher
layers.
2	Where are the failures referenced specified?  Have Cisco their own
specifications for this?  We would really like to see these specified in
some standard manner.

thanks/regards, neil

Delivery-date: Sun, 01 Apr 2001 22:16:43 -0700
Date: Sun, 01 Apr 2001 22:13:26 -0700
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
CC: Bora Akyol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

Giles,

> In any case yes I would expect link failures to be detected
> immediately.  

Detection does not equal headend notification, but anyway as you agree
that local protection is a good thing I don't see a reason to hold this
draft and not to proceed to last call - we needed it for customers using
FRR today and want to interoperate with multiple vendors. 

Unless there is any other piece of work addressing this very specific
issue of label allocation on bypass tunnels (not reroute in general) in
mpls or ccamp I would agree with George's last call.

R.

Delivery-date: Sun, 01 Apr 2001 21:35:30 -0700
Date: Mon, 02 Apr 2001 06:25:24 +0100
From: Giles Heron <[email-masked]>
Reply-To: [email-masked]
Organization: Gone2 Inc.
To: [email-masked]
Cc: Bora Akyol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

Robert Raszuk wrote:
> 
> Giles,
> 
> > > For the user-plane, the failure modes which must be considered/defined are:
> > > -       simple below MPLS fabric server layer connectivity breaks;
> > > -       simple within MPLS fabric connectivity breaks (at or below the LSP
> > > level considered);
> >
> > Both of these will be detected by the RSVP signalling, won't they?
> 
> Sure but the question is when ?
> 
> Do you think that RSVP Error/Tear msgs will travel immediately - case of
> link failure or are you proposing to run RSVP refresh in the interval
> less then 1 sec - to detect the case of node failure ? The point is that
> this draft is not about detection, but about backup LSP setup and label
> allocation under the __local__ protection scheme. So let's talk on the
> subject here.

Sorry if I drifted off (or was led off) topic there.

In any case yes I would expect link failures to be detected
immediately.  Node failures presumably require some form of polling to
detect - so the questions are:

at what level should this occur (link layer, RSVP, "MPLS OAM"?)
how low is it reasonable to set the timers?
 
> If one questions the use of local protection all together please specify
> how else you will achive the same results of even less then 1 sec end to
> end traffic disruption with end to end protection under both link & node
> failures for the TE- LSP ?

I'm all for local protection - precisely because it would be so hard to
get end to end protection to meet the <1 sec goal.

Giles

> 
> Bora,
> 
> Which CCAMP IDs address the setup & label allocation of backup tunnels
> for local protection ?
> 
> R.

-- 
============================================================
Giles Heron      Principal Network Architect      Gone2 Inc.
ph: +44 7880 506185         "if you build it they will yawn"
============================================================

Delivery-date: Sun, 01 Apr 2001 00:07:46 -0800
Date: Sun, 01 Apr 2001 00:02:15 -0800
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked], Bora Akyol <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

Giles,

> > For the user-plane, the failure modes which must be considered/defined are:
> > -       simple below MPLS fabric server layer connectivity breaks;
> > -       simple within MPLS fabric connectivity breaks (at or below the LSP
> > level considered);
> 
> Both of these will be detected by the RSVP signalling, won't they?

Sure but the question is when ? 

Do you think that RSVP Error/Tear msgs will travel immediately - case of
link failure or are you proposing to run RSVP refresh in the interval
less then 1 sec - to detect the case of node failure ? The point is that
this draft is not about detection, but about backup LSP setup and label
allocation under the __local__ protection scheme. So let's talk on the
subject here. 

If one questions the use of local protection all together please specify
how else you will achive the same results of even less then 1 sec end to
end traffic disruption with end to end protection under both link & node
failures for the TE- LSP ? 

Bora,

Which CCAMP IDs address the setup & label allocation of backup tunnels
for local protection ?

R.