The MPLS WG Archive

[<benjamin.niven-jenkins@bt.com>]

Colleagues,

draft-swallow-mpls-mcast-cv is a good start towards addressing P2MP OAM
in a scalable manner.

Following on from my comments at IETF 66, I have discussed the draft
with a few colleagues and below are some general comments on
draft-swallow-mpls-mcast-cv-00 and some editorial comments.

Ben

-- 
Ben Niven-Jenkins
Network Architect, BT Exact

 
General comments
----------------
1) Section 3 states:

"3. Connectivity Verification Bootstrapping

   Bootstrapping is accomplished by sending an MPLS Echo Request message
containing a Connectivity Verification Session object and a FEC stack
which specifies the LSP for which connectivity verification is desired.
The next section describes the Connectivity Verification Session object.
Subsequent sections describe the procedures for the root and leaves."

Which essentially means that Connectivity Verification is boot strapped
by LSP-Ping.  I would like to see an option whereby CV is bootstrapped
by the signalling protocol.  Architecturally, the
activation/deactivation of any proactive defect detection/handling (i.e.
CV) should be synchronised to whatever process is responsible for the
setup/tear down of that connection.  So CV activation/deactivation
should be synchronised to either NMS/OSS provisioning or the signalling
protocol used.  This also ensures that OAM activation/deactivation is
tied-in to connection setup/tear down wrt time, so as soon as the
connection is created the OAM is also initiated and the OAM is stopped
before the connection is torn down therefore avoids raising false
alarms.

The draft describes how to use LSP-Ping to bootstrap CV OAM once an LSP
is activated, but doesn't describe how to deactivate CV OAM prior to an
LSP being deactivated.  This needs clarification IMO.

A more subtle observation on the current approach is if we setup a P2MP
LSP and then use LSP-Ping which operates in-band wrt the data plane of
that P2MP LSP to bootstrap CV for that LSP, how do we know the LSP has
been correctly setup in the first place as the LSP-Ping bootstrap
message is being carried in the same data plane entity (i.e. LSP) that
the CV will monitor?

Can mpls-mcast-cv be initiated by an out of band process wrt the data
plane entity (i.e. LSP) that it will monitor? 

2) Section 3.1 states:

"Discriminator

A unique, nonzero discriminator value generated by the transmitting
system, used to demultiplex multiple BFD sessions between the same pair
of systems."

I would like to see a recommendation that this discriminator field
contain a network unique identifier (e.g. source address) of the LSP to
help with better identification under fault conditions than a possibly
arbitrarily generated number.

Also, is the reference to BFD a copy & paste error?  If not, then
further discussion of how this field is used and how it relates to BFD
is required.

3) Section 3.2 states

"The Refresh Interval is set to a relatively long value.  The root
MUST refresh the session within this interval.  The root MAY jitter
refresh messages but the Refresh Interval serves as a hard upper
bound on the jittering.  MPLS Echo Requests which refresh the CV
Session SHOULD be sent on average at approximately one third of the
Refresh Interval."

However Section 3.1 defines the Refresh Interval as "the minimum period
before a refresh message is sent in milliseconds."

There seems to a conflict in the two defintions, where Section 3.1
states it is a mininum period and Section 3.2 states that it is a upper
bound.  Which is it?

4) Section 3.3.1 states
"If the Forward Defect Flag is set, an up call to any registered
applications is made."

Is this up call supposed to cause any action by the application or imply
any consequences?  It would be good to clarify this here.  Also, the
term 'up call' is not familiar to me and is not defined.  I assume by up
call you mean that FDI is propagated upwards to the application
(assuming the application support some form of FDI).

5) Section 4 states:

"Forward Defect (F)

This flag indicates a defect upstream of the LSP.  It MAY be set in
order to suppress alarms downstream of the LSP."

This sounds like it is an FDI/AIS type function and IMO the
description/use of this field should be further clarified in the next
revision of the draft.

6) Section 4.3
It may be worthwhile to include an expiration mechanism.  When the root
node stops transmitting traffic and before the multicast states expires,

either the root node would need notify the leaves with a "A" flag or the
leaf would need to expire its probe state as well upon expiration of its
own multicast state.

Editorial comments
------------------
1) Section 3:

Replace
"Bootstrapping is accomplished by sending an MPLS Echo Request
Message containing a Connectivity Verification Session object and a FEC
stack which specifies the LSP for which connectivity verification is
desired."

With

"Bootstrapping is accomplished by sending an MPLS Echo Request
Message containing a Connectivity Verification Session object, defined
in this section, and a FEC stack, defined in section 5, which specifies
the LSP for which connectivity verification is desired."

2) Section 3.2, paragraph 5:

Replace "It this is not possible" with "If this is not possible".


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls