Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

From: Eric W Gray <[email-masked]>
Date: Sun, 01 Apr 2001 11:12:53 -0400

Bora,

    The idea of delaying work because other work that is
"in the pipe-line" may make it obsolete seems to come up
a lot.  There are two ways to look at this sort of idea:

1) the work will perform some necessary function as is
    and should be progressed; future work can then use
    this work as part of the "prior art" on which it should
    be based.

2) the work will not perform a useful function until the
    additional work that is "in the pipe-line" has reached
    some reasonably well understood state of maturity
    (e.g. - it published as a standard).

I believe the working group has weighed in on the side
of the former interpretation - which is a good thing, in
my mind, because the expression "in the pipe-line" is a
thinly disguised variation of another well-known white
lie ("in the mail").

--
Eric Gray

Bora Akyol wrote:

> George
>
> The point that I was trying to make is that there is **other** reroute
> work going on within the CCAMP WG and I am not sure about the
> interaction between that work and the draft that is in question. Hence I
> asked **a** question below.
>
> If it turns out that the WG consensus is to do a last call and send the
> draft forward, fine by me. However, the draft may get obsoleted quickly
> once the CCAMP WG concludes the fast reroute work.
>
> Bora
>
> On Friday, March 30, 2001, at 01:04 PM, George Swallow wrote:
>
> >> As far as I understand this draft outlines a mechanism for fast reroute
> >> in MPLS networks. With this in mind, shouldn't we delay the last call
> >> on
> >> this draft until ther **other** fast reroute related drafts in CCAMP
> >> run
> >> to completion?
> >>
> >> Regards
> >>
> >> Bora
> >
> > Bora -
> >
> > I don't get your point.  Would you suggest that Sonet not specify BLSR
> > or closer to home IPoPTR not work on rerouting schemes?  This is a
> > technology specific mechanism which has immediate application.  How or
> > even if it fits into a larger picture is irrelavant.
> >
> > ...George
> >
> >
> > ==================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> >

---

From: Giles Heron <[email-masked]>
Date: Mon, 02 Apr 2001 06:14:34 +0100

Neil,

[email-masked] wrote:
> 
> Giles Heron [mailto:[email-masked]] wrote 29 March 2001 22:27
> > [email-masked] wrote:
> > >
> <snip>
> > > 2       At the top of page 5 in section 2 it says:
> > > " When a failure occurs and the backup comes into use,......"
> > >
> > > All user-plane (and indeed control-plane) failure modes
> > must be identified
> > > and specified in terms of entry/exit criteria and
> > consequent actions before
> > > we can meaningfully proceed with this draft.
> > >
> > > 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?
> NH=> Not necessarily.  The functionality/processing of the user-plane and
> control-traffic is not identical......and they can be subject to different
> failure modes.  Each needs its own OAM to handle defects relevant to its own
> case.  Further, one would like to have SLAs for the user-plane (for
> customers) that require specific and consistent measurement.  They also
> require certain 'consequential actions' which are not currently specified
> anywhere else but in our ID.  And in general, one should not look at just
> 'some' cases of defect in isolation.....they all require a harmonised
> approach and, with careful up-front thought, this should also yield
> simplicity of design.  If you don't think about these aspects at the outset
> then things can get very complex later should you require to add such
> functionality.

I'm not sure what to make of this paragraph.

Can you please give us some examples of situations where the control
plane will not detect the user plane defect? (other than the buggy
software case below of course.)

> > > -       swapped LSPs, ie instead of A1->A2 and B1->B2 a
> > defect creates
> > > A1->B2 and B1->A2;
> > > -       mismerged LSPs, eg instead of A1->A2 and B1->B2 a
> > defect creates
> > > A1->A2 and A1+B1->B2 say (though there are potentially
> > several variations on
> > > this).
> >
> > Both of these would only occur (as far as I can tell) if the router
> > software is buggy.  As I have stated before I don't really see the
> > benefit of adding code to fix buggy code.
> NH=> It can be HW as well as SW that is faulty.  The OAM has nothing to do
> with 'fixing buggy code'....indeed it will not *fix* the defects, but only
> allow correct handling should they occur to protect my customers and help my
> Ops people diagnose the problem.  It is also there to ensure a consistent
> (and indeed simple) method of measuring availability and QoS (the former is
> *the* critical metric, and the latter is dependent on former since it only
> applies to the up-state).  I have not seen any work (other than what is in
> our ID) which shows how availability/QoS metrics can be consistently and
> simply measured for all defect cases.  And as a carrier this is something I
> want.  However, the overall purpose of the OAM is stated in the principles
> section of the ID.  I refer people back to this rather than repeat here.

I'll take your point that it could be hardware as well as software that
is buggy.  And no - when I used the word "fix" I wasn't envisioning your
OAM ID making binary patches to faulty code in real time ;-)

> > > For the latter 2 defects it will be vital to suppress the
> > traffic due to
> > > potential security/censorship/misbilling implications for
> > carriers and
> > > customers.  Speaking as a carrier these issues are
> > requirements that must be
> > > addressed.  This is not optional, and rigorous definitions
> > must be provided
> > > (or referenced).
> >
> > Speaking as another carrier I *don't* see these as requirements that
> > must be addressed.  If software is buggy things go wrong.  So
> > let's fix
> > the software rather than adding another layer to "manage" the bugs.
> NH=> How are you going to decide/detect that the SW (or HW) is wrong in
> order to fix it?  Are you really also telling me you have no requirements to
> offer/measure availability/QoS SLAs for customers?......but if you do then I
> would be interested to know how you are going to do this, ie do you have an
> alternative proposal you can share with us for evaluation please?  It would
> also be nice to hear from more carriers on this subject.....I know BT, FT,
> DT, NTT and AT&T have an interest since they have seen/commented on what
> appears in the work you have seen.

I expect I'll detect buggy software or hardware by the usual combination
of lab testing prior to deployment and network monitoring to look for
anomalous behaviours.

And yes, of course I have a requirement to offer SLAs to customers. 
Originally I had thought that some sort of MPLS OAM might be useful for
this.  Having read your draft, having seen the complexity involved,
having figured out that all it seems to detect that cannot be detected
by other means is mismerged/swapped LSPs, and having discovered that it
doesn't support merging LSPs, I have come to the conclusion (rightly or
wrongly) that I'm better off without.

Giles

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 16:25:40 -0400

In message <[email-masked]>, Bora Akyol writes:
> in MPLS networks. With this in mind, shouldn't we delay the last call on 
> this draft until ther **other** fast reroute related drafts in CCAMP run 
> to completion?
> 
> Regards
> 
> Bora

Bora,

This draft seems to provide only a means to reduce the number of
labels required to provide backup by allowing shared backup tunnels.
It is applicable to any technique that involves local protection as
opposed to ingress protection.  It does not preclude doing ingress
protection.

I don't understand your objection.

Curtis

> On Wednesday, March 28, 2001, at 03:03 PM, George Swallow wrote:
> 
> > This message commences a workgroup last call on "RSVP Label Allocation
> > for Backup Tunnels" <draft-swallow-rsvp-bypass-label-01.txt>.  This
> > draft is informational.  The last call closes April 11, 12 PM GMT.
> >
> > ...George
> >
> > ======================================================================

---

From: Marc Lewis <[email-masked]>
Date: Thu, 5 Apr 2001 07:56:52 -0700

Robin wrote:

> Alcatel's implementation of MPLS does support statically configured LSPs.
> I would guess other vendors support statically configured LSPs.

That is not true for the switch/routers produced by the former Packet
Engines (specifically, the Alcatel 7652 PowerRail Distribution Router).  Our
MPLS implementation does support statically configured LSPs, as well as LSPs
signalled via RSVP-TE.  We implemented our MPLS switching in hardware, and
can do up to 3 label push/pop/swaps per frame and still maintain gigabit
line rate.

----
H. Marc Lewis -- Sr. Software Engineer -- Alcatel Internetworking (PE) inc.
Spokane, WA  --  (509) 777-7316 -- [email-masked]

---

From: Zappacosta Rolando Jorge <[email-masked]>
Date: Fri, 6 Apr 2001 09:58:24 -0300

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

---

From: "Mak, L (Leen)" <[email-masked]>
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

> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 14:02
> To: [email-masked]'; [email-masked]
> 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
> should be taken that such actions don't invoke unecessary 
> actions in higher
> layers.

---

From: [email-masked]
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

> From: Zappacosta Rolando Jorge [mailto:[email-masked]]
> Sent: 06 April 2001 13:58
> To: 'Lazer, Monica A, NNAD'; [email-masked]'; 
> [email-masked]
<snipped to end>