The MPLS WG Archive

[neil.2.harrison@bt.com]

Jean Philippe,

Some comments on your (well-written) draft:

1	Assumption of single failure.  Understand the issue very well.
However, this is only strictly controllable if one has a full layer view to,
and including, the duct network (since all higher layer networks can mesh as
much as they like but cannot increase the disjoint connectivity degree
inherited from the duct layer).  This implies the scope should be restricted
to where this (commercial layer ownership issue) is true.....else attach
health warnings.


2	Says this is section 2:

"Typically a link down event does not tell to a PLR whether the link
attached to its NHOP or its NHOP itself has failed."

Well it would if proper OAM procedures are used on the server layer
technology connecting the nodes.  If we get a SDH L1 failure say you ought
to be seeing an incoming Forward Defect Indicator (FDI) [aka AIS - Alarm
Inhibition Signal] in the relevant VCs.  This tells one the failure is
*below* the MPLS layer in question and so is clearly a (server) layer/link
failure and not a nodal failure.  Moreover, it also tells you *not* to raise
any alarms at the MPLS layers or indeed higher, eg PWE3 case....assuming the
MPLS layers themselves are capable of relaying the FDI correctly.  Else
alarm storms (which can be organisationally disjoint and geographically
widespead in the general case).....this is not a good thing to do to
operators.

G.805 describes the functional architecture that needs to be taken into
account here.

Note - In section 8 'Optimisation 1' does, I believe, refer to the above
type scenario.  However, this should not be considered an optimisation as it
is the required default behaviour for the reasons noted above.  


3	The basic premise of the proposal is to use a signalling protocol to
test the connectivity status of an alternate data-plane path between 2
points, where the working path takes a different route between these 2
points.  This is possible, but it is strictly not exercising the data-plane
of the alternative path.  Note also that the alternative path may or may not
be required to become either fully or partially part of the the protection
path....as explained in sections 6 and 7.

I note in another ID from some of your colleagues
(draft-nadeau-ip-basedtool-requirements-00.txt) it says this as a
requirement (".....gathered from network operators in various workshops by
the authors of this document."):

" r) Separation of Data and Control Plane OAM. The inherent separation of
control and data planes in MPLS lends itself to being sometimes implemented
independently within an MPLS LSR.  For example, in a multi-slot LSR, one
slot may run a control process responsible for running MPLS control
protocols such as LDP and RSVP, and then programming line cards residing in
other slots to forward traffic accordingly. In doing so, the switch
separates out the data plane from the control plane in such as way that it
is possible for the line card to be mis-programmed whilst the control card
is unaware. This leads to a potential for the line card to black hole data
plane traffic.  This is one example of why it is important for LSRs to
possess functions that allow an operator to detect data plane liveliness.
Data Plane liveliness MUST use the exact same path as data."

I agree with the above.  This requirement also appears in Y.1710, and
effectively says that the traffic's data-plane connectivity verification
should be independent of any control-plane protocol (routing or signalling),
including case of none.  Not only is this for the reasons stated above, but
its is also to allow independent development of (data-plane and
control-plane) protocols.

Can you please comment on this apparent divergence of view?

thanks and regards, Neil