Subject: [mpls-tp] Asking for comments on draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

From: "Elisa Bellagamba" <[email-masked]>
Date: Thu, 26 Nov 2009 17:56:07 +0100

Hello,

We are planning to upload an updated version of
http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ex
t-03 for the week of December the 7th. 

We would like to receive as many comments as possible from you before
that date.

We are already working on keeping aligned this draft with the
http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-02 and
the other existing technology specific drafts. Loa will send a specific
email to discuss this point.

Thanks to who will provide some feedbacks!

Regards,
Elisa

---

From: David Allan I <[email-masked]>
Date: Fri, 27 Nov 2009 08:14:30 -0500

HI Elisa:

A few comments on the draft...

1) Consistent with the OAM framework, you may want to identify the scope as intended to be broader than simply the exemplary BFD in the introduction, a suggestion would be:

    - the exchange or configuration of identifiers used explicitly as part of data plane OAM procedures  for the MEG and the ME (MEP ID, ME ID, MEG ID...?), this is clearly above and beyond BFD as it would apply to all on-demand functions as well as the proactive monitoring ones...

    - the exchange, negotiation or configuration of parameters associated with proactive monitoring functions
        (in the future periodicity of PM may also figure into this...)

Out of scope would be the triggering of the performance of on-demand functions above and beyond the OAM identifier exchange to facilitate on demand operation identified above...as these are typically operator initiated, and do not need any further apriori setup by the control plane...

2) I believe one agreement in Hiroshima was to consolidate CC and CV by simply deprecating CC as it was simply a degenerate version of CV, at least I advocated that and thought there was agreement in the room. So assuming no objections appear to this email, you can simplify the draft by taking the CC aspects out...

3) 2nd para of section 2. Presumably we are applying BFD to the full gamut of paths.... co-routed bi-dir, associated bi-dir, uni-dir p2p and unidir p2mp... the description focuses on co-routed bi-dir and would need some elaboration....

4) 4th para of section 2... although BFD allows asymmetrical periods (different send rates at either end of the path), transport is about an availaility definition that would assume a common rate and the TLV design seems to reflect this as it only exchanges suggested TX rates... if you are to generalize this across the MPLS architecture, you may want to separate out "what the sender wants to send" and "what the sender will tolerate from the destination"...right now my read of the TLVs is what the sender will send and by inference what it expects the destination to send... it is not clear to me what happens if these values get adjusted...

5) Section 3 para 2... you use ingress and egress to describe the signalling roles, while RFC 3209 already has estalished sender and destination nodes as the "proper terms"...it would be best to line up with existing terminology where possible.

6) Section 3.3.2, I'm not sure what I'm missing but I cannot find a description of the "detect. mult" field...

7) I'd move the source unique MEP TLV up to being a peer of the BFD TLVs instead of a sub-TLV as it would be independent of BFD itself...and of utility for Ping, PM etc.  There should also be a MEG ID TLV and an ME TLV...P2MP needing a bit of thought as it would require a bunch of ME ID TLVs...in this way sender and destination can exchange MEP and other IDs for the gamut of OAM functions.

hope this helps
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elisa Bellagamba
Sent: Thursday, November 26, 2009 5:56 PM
To: [email-masked]
Subject: [mpls-tp] Asking for comments on draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

Hello,

We are planning to upload an updated version of http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 for the week of December the 7th.

We would like to receive as many comments as possible from you before that date.

We are already working on keeping aligned this draft with the http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-02 and the other existing technology specific drafts. Loa will send a specific email to discuss this point.

Regards,
Elisa

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 13:49:37 -0000

Apologies not had time to read the draft, but just wanted to strongly
support a comment from Dave....have snipped mail below to this:

	David Allan  wrote 27 November 2009 13:15
	
	<snipped>
	2) I believe one agreement in Hiroshima was to consolidate CC
and CV by simply deprecating CC as it was simply a degenerate version of
CV, at least I advocated that and thought there was agreement in the
room. So assuming no objections appear to this email, you can simplify
the draft by taking the CC aspects out...
	 
	NH=> A bit of history might also help here.  I coined the term
CV (Connectivity Verification) to differentiate it from CC (Continuity
Check) because CC was originally associated with ATM OAM message where
the CC message did NOT contain an absolute source address of the
connection (just a null payload)......which is not a very smart idea if
one is trying to detect misconnectivity and identify the source of this!
The original CC messages in ATM need only be sent when traffic was
quiescent to 'maintain knowledge of still connected' as a sort of
trivial BW saving device (not a good reason).
	 
	So I support Dave's comments.
	 
	regards, Neil

---

From: "Elisa Bellagamba" <[email-masked]>
Date: Mon, 30 Nov 2009 15:29:35 +0100

Dave,
 
thanks a lot for your useful comments.

you say that we broaden the scope beyond plain BFD e.g. by including

>    - the exchange or configuration of identifiers used explicitly as
part of data plane OAM procedures  for the MEG and the ME (MEP ID, ME
ID, MEG ID...?), this is clearly above and beyond BFD as it would apply
to all on-demand functions as well as the proactive monitoring ones...

>    - the exchange, negotiation or configuration of parameters
associated with proactive monitoring functions
        (in the future periodicity of PM may also figure into this...)

We'll try to include more clarity in the next version of the draft.

You also say:

> Presumably we are applying BFD to the full gamut of paths...co-routed
bi-dir, associated bi-dir, uni-dir p2p and unidir p2mp... the
description focuses on co-routed bi-dir and would need some
elaboration....

Could you help us with text on this?

Thanks,
Elisa

From: David Allan I 
Sent: den 27 november 2009 14:15
To: Elisa Bellagamba; [email-masked]; [email-masked]
Subject: RE: Asking for comments on
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

HI Elisa:

1) Consistent with the OAM framework, you may want to identify the scope
as intended to be broader than simply the exemplary BFD in the
introduction, a suggestion would be:
 
    - the exchange or configuration of identifiers used explicitly as
part of data plane OAM procedures  for the MEG and the ME (MEP ID, ME
ID, MEG ID...?), this is clearly above and beyond BFD as it would apply
to all on-demand functions as well as the proactive monitoring ones...
 
    - the exchange, negotiation or configuration of parameters
associated with proactive monitoring functions
        (in the future periodicity of PM may also figure into this...)
 
Out of scope would be the triggering of the performance of on-demand
functions above and beyond the OAM identifier exchange to facilitate on
demand operation identified above...as these are typically operator
initiated, and do not need any further apriori setup by the control
plane...
 
2) I believe one agreement in Hiroshima was to consolidate CC and CV by
simply deprecating CC as it was simply a degenerate version of CV, at
least I advocated that and thought there was agreement in the room. So
assuming no objections appear to this email, you can simplify the draft
by taking the CC aspects out...
 
3) 2nd para of section 2. Presumably we are applying BFD to the full
gamut of paths.... co-routed bi-dir, associated bi-dir, uni-dir p2p and
unidir p2mp... the description focuses on co-routed bi-dir and would
need some elaboration....
 
4) 4th para of section 2... although BFD allows asymmetrical periods
(different send rates at either end of the path), transport is about an
availaility definition that would assume a common rate and the TLV
design seems to reflect this as it only exchanges suggested TX rates...
if you are to generalize this across the MPLS architecture, you may want
to separate out "what the sender wants to send" and "what the sender
will tolerate from the destination"...right now my read of the TLVs is
what the sender will send and by inference what it expects the
destination to send... it is not clear to me what happens if these
values get adjusted...
 
5) Section 3 para 2... you use ingress and egress to describe the
signalling roles, while RFC 3209 already has estalished sender and
destination nodes as the "proper terms"...it would be best to line up
with existing terminology where possible.
 
6) Section 3.3.2, I'm not sure what I'm missing but I cannot find a
description of the "detect. mult" field...
 
7) I'd move the source unique MEP TLV up to being a peer of the BFD TLVs
instead of a sub-TLV as it would be independent of BFD itself...and of
utility for Ping, PM etc.  There should also be a MEG ID TLV and an ME
TLV...P2MP needing a bit of thought as it would require a bunch of ME ID
TLVs...in this way sender and destination can exchange MEP and other IDs
for the gamut of OAM functions.
 
hope this helps
D

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elisa Bellagamba
Sent: Thursday, November 26, 2009 5:56 PM
To: [email-masked]
Subject: [mpls-tp] Asking for comments on
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

Hello, 

We are planning to upload an updated version of
http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ex
t-03
<http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-e
xt-03>  for the week of December the 7th. 

We are already working on keeping aligned this draft with the
http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-02
<http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-02>
and the other existing technology specific drafts. Loa will send a
specific email to discuss this point.

Regards, 
Elisa