The MPLS WG Archive

[neil.2.harrison@bt.com]

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