The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

	Hi,

	Thanks for reviewing. Replies inline start with TDN:

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

TDN: Agreed.

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

TDN: If the LSP was setup correctly, then the setup message will
	arrive at the end points correctly and then be replied to,
	otherwise it will not (if the LSP is not working).

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

TDN:	I suppose that it could, although the point of having
	the online process do this is to generate the
	traffic on the egress line cards (for distributed
	implementations).

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

TDN:	The discriminator is meant to be chosen from the same
	pool as BFD session discriminators are chosen.	These
	have only local significance. What provides the network-wide
	uniqueness is the binding between the source/destination
	IP addresses plus the discriminator.
	
> 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.

TDN:	Yes, although the next version of the draft will have
	more things borrowed from BFD.

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

TDN: The refresh interval for the bootstrapping messages is
	supposed to be relatively long -- on the order of
	multiple seconds or minutes.

> 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).

TDN: Yes, in essence, an indication that the path is not
	functioning is given.

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

TDN: OK.

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

TDN: Point taken, but I think we need to think about this some more.

> 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".

TDN: OK.

	--Tom


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

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