Subject: comments on nagarajan-ccamp-mpls-packet-protection-00.txt

From: [email-masked]
Date: Wed, 24 Apr 2002 13:18:24 +0100

I noted George S asked for comments on
nagarajan-ccamp-mpls-packet-protection-00.txt to be taken on the list in his
notes of the MPLS WG mtg.....so here are some 1st pass comments:

1	I noted a criticism in the mtg notes that it uses 2x the BW of one
LSP....well yes it is 1+1 so I'd say that's obvious.  However, I think we
have to place any such criticism of BW efficiency in context.  For example,
if I compare it with LDP as a server layer to (say) rfc2547 VPNs, then
because there is no relationship between a pkt's up-state QoS forwarding
treatment and a pkt's survivability requirements (vis-à-vis same or
different DS-coded pkts of *any* VPN), operators are forced to over-engineer
such networks and *hope* (because there is no assurance) that traffic
survives under failures....a factor of 2x over-engineering on some DS
classes is not uncommon.

Hence, the point I want to make here is that using BW wisely to
reduce/remove a complexity/problem is one thing (which I support), but
asking an operator to throw BW at a problem that should not really exist
(because the application/problem in question has only been partially
defined, eg just the connectivity bit of VPNs) is something else.  So any
criticism of BW efficiency only makes sense against the context of the
application/problem it is addressing IMO.

2	I noted in section 6.2 you address the practical issue of carrying
the sequence number (if implemented in such a way), and suggest that it sits
directly below the shim header (1st 4 octets of payload).  This is possible.
2 things spring to mind here:

-	IMO you really need some way to be sure you have correct A-B
connectivity....and this includes defects where perhaps another LSP, LSP X
say, gets merged unintentionally into the LSP Y between A-B.  In this case
you would get some unexpected results looking for a sequence number in such
mismerged pkts.  I would therefore recommend you run a periodic data-plane
LSP CV OAM flow on each of the LSPs to verify correct connectivity, since
these contain unique LSP source identifiers and will detect all defects, not
just simple breaks (and if following Y.1711, it will also invoke the correct
consequent actions on failure).

-	You will need to configure the LSP sink points to expect LSPs
containing sequence numbers.  This can be done manually of course, but you
may want to consider some auto signalling config...and I later noted that
you have considered this aspect in section 6.4 wrt RSVP say.  A further way
to achieve this signalling function could be by the use of special OAM
pkts....and its something being considered by those who are working on MPLS
OAM in Y.1711 for automatic CV activation/deactivation.

3	Given that the scheme you are proposing seems to fit where one has a
critical LSP connectivity application (like a control/management-channel
say), then I think you ought to be running some solid OAM fault
detection/handling function on it in any case....I gave one example above
wrt mismerging and seeing arbitrary sequence number effects.  Moreover, I
noted later you gave an algorithm for processing the sequence number
implementation case at the egress that is associated with a sliding window.
I would suggest that this needs coupling with defect detection mechanisms in
order to make the correct processing decisions.....one obvious cut-off point
is when you would consider one of the LSPs to have become 'unavailable'
(this is also defined in Y.1711).

4	Final comment....simple ideas are often the best, and this idea is
certainly simple in principle.  I think it could find excellent uses for
critical applications.	

regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Apr 2002 14:23:19 -0400

> application/problem it is addressing IMO.

Point of failure protection schemes (local-protect and fast-reroute)
provide 50msec recovery.  I'll just say FRR for short.  This technique
doesn't require sending double the bandwidth.  Some implementations
might not make the 50msec but some do.

Fully disjoint paths from the ingress yield from 1/4 to 1-2 seconds
recovery (depending again on who's implementation) and these require
less signaling than point of failure protection.  In our
implementation these are called "standby" LSPs.

Reservations on the backups (using either FRR or standby) at a
numerically higher setup/hold priority can help avoid congestion (or
completely avoid it) during the failure without impacting the traffic
engineering of the primary path (on the numerically lower priority).

The ISPs that I've talked to about the topic of restoration indicate
that although fast restoration is highly desireable for some services,
a strong requirement is efficient use of available bandwidth.  The
goal is to allow the most cost effective delivery of service and keep
the financial bottom line in the black.  This may have something to do
with a competative business environment but whatever the reason, the
"throw more bandwidth at it" approach does not seem to be in favor.

So far signaling extensions to share the backup bandwidth have been
proposed but gone nowhere (perhaps implementation will help).  This
would yield even better use of resources (or better avoidance of
congestion if overbooking backup bandwidth was eliminated).  Of
course, if the payload is non-IP overbooking backups may not be an
option so this then would just yield better use of resources.

Of course, FRR requires that the point of failure be able to detect
its own failure which may not be the case for optical devices.
Doubling the bandwidth is a steep price to pay to satisfy the
restoration needs.  If the cost of WDM port plus optical switch port
is half that of a router port, that might be fine.  It still might
make a lot more economic sense to use FRR to provide restoration at
the PSC capable boxes outside the optical domain which will generally
be plenty fast enough.

IMHO - there is no need for this draft.  In the end the ISPs/carriers
vote with their dollars and I haven't seen any "yes" votes of that
sort so I won't be coding this quite yet.

As far as VPN is concerned, some providers are using (at least in
trial if not production) LDP over MPLS/TE and using the MPLS/TE
traffic engineering and fast recovery capabilites.  This scales well
if the network is divided into a core and regions keeping the number
of LSPs manageable and can work well if the nodes (routers) at the
borders of the core and regions are very reliable.

Curtis