Subject: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-03

From: David Allan I <[email-masked]>
Date: Mon, 10 May 2010 13:12:57 -0400

Hi Loa:

We've just posted a revised version of draft-asm. We'd like see this become a WG document and request this gets taken to the list...

https://datatracker.ietf.org/doc/draft-asm-mpls-tp-bfd-cc-cv/

Cheers
D

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 May 2010 12:16:41 -0700

Dear David, Editors and All,
below are my comments to the document:

   - The following sentence in the Abstract doesn't read right "Continuity
   Check monitors the integrity of the continuity of the path for any loss of
   continuity defect." Perhaps "CC monitors the path for any loss of
   continuity" or "CC monitors continuity of the path for any defect or loss."
   - Capitalization for Connectivity Verification (CV) and Continuity Check
   (CC) should be consistent in the text (second sentence in second paragraph
   of the Abstract)
   - I think that it would be logical to move Section 2.2 towards end part
   of the document as it summarizes questions still open for discussion
   - Section 3 - distinct encapsulations for CC and CV might pose a
   challenge for efficient and scalable HW support. That might be argument for
   merging CC and CV
   - Bullet #2 (CV) doesn't mention that the RDI functionality is supported
   (according to bullet #3 RDI is supported by both CC and CV)
   - I think that the following statement will benefit from listing specific
   examples "It's possible to run BFD in CC mode on some transport paths and
   BFD in CV mode on other transport paths."
   - "For a given Maintenance Entity Group (MEG) only one mode can be used."
   Though the sentence that follows expands this statement I'd propose to add
   "for the lifetime of that MEG."
   - Section 3.4 Why an associated bi-directional connection presents a
   special case (requires configuration on two MEs) in regard to state of a BFD
   session? And would state of BFD session on p2mp path be determined by
   configuration on all possible MEs or a subset of MEs?
   - Section 3.5 "This rate is typically a fixed value for the lifetime of
   the session." If terms "BFD session" and "session" are used interchangeably,
   then it would be helpful to add such statement.
   - "This document specifies bi-directional BFD for p2p transport paths
   ..." If this statement defines the scope of the document it would be
   reasonable to mention the scope in the Abstract and/or Introduction
   - "In the rare circumstance where an operator has a reason to change
   session parameters, poll/final discipline is used." Though this
   functionality is native to BFD we're not obliged to use it. Operator can
   simply take the BFD session into Admin Down state , reconfigure the timers,
   and bring it Up again.
   - "The base spec is unclear on aspects of how a session with a BFD source
   set to zero interval behaves." Setting MinRxInterval, in fact the BFD base
   uses "Required Min RX Interval" term in regard to BFD session originator, to
   zero commands remote BFD peer not to send BFD Control packets. The peer sets
   its RemoteMinRxInterval accordingly.
   - The first clarification in Section 3.5 (p.7) regarding behavior of p2p
   BFD session, in my view, doesn't consider operation over unidirectional p2p
   connection.
   - I think that the following sentence "The second is that the originating
   MEP (the one with a non-zero TxInterval) will ignore a DOWN state received
   from a zero interval peer" can be clarified. Both end-points of the BFD
   session might have non-zero DesiredMinTxInterval but only one would have
   RemoteMinRxInterval set to zero. Perhaps the following change will make it
   better "The second is that MEP with non-zero RemoteMinRxInterval will ignore
   DOWN state received from a peer if the MEP set Required MinRx Interval to
   zero at session initialization."
   - Session 3.5.1 As mentioned above, I think that consideration for
   unidirectional p2p connection is missing. Would CC/CV session be initiated
   in-band and/or out-band? Perhaps this is a gap that needs to be addressed
   with RSVP-TE (for LSP) and Targeted LDP (for  PW) extensions. Or mention use
   of LSP-ping to bootstrap BFD session.
   - Section 3.5.2 " 2. BFD control packets are received with an unexpected
   encapsulation (Mis-connectivity defect), these include - a PW receiving a
   packet with a GAL - an LSP receiving an IP header instead of a GAL (note
   there are other possibilities but these can also alias ..." I think that
   mis-encapsulated packets must be not delivered to the BFD (e.g. wrong ACH
   Code Point) but dropped and proper stats (MIB?) incremented. The CC/CV will
   see this as Loss of Continuity then
   - Section 3.5.4 "Loss of continuity", "loss of connectivity" -
   capitalization J
   - I think that we have Loss of Continuity and Mis-connectivity defects.
   Do we have Loss of Connectivity? Isn't it the same defect condition as Loss
   of Continuity?

Regards,
Greg

On Mon, May 10, 2010 at 10:12 AM, David Allan I
<[email-masked]>wrote:

> Hi Loa:
>
> We've just posted a revised version of draft-asm. We'd like see this become
> a WG document and request this gets taken to the list...
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 09:26:48 -0400

Hi Folks

Another version of the draft was just posted. This simply corrects artifacts from the resolving ID-nits process and other non-technical content mistakes...

For those reviewing version 03, there are no changes to the content whatsoever...nor document layout...

Comments received to date (e.g. from Greg Mirsky) will be resolved in the next revision....

cheers
D & co.

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 May 2010 09:44:05 -0700

Hi David,

I had comments on the previos version of the draft. If there have been
no changes they would probably hold good for this version too.

I had the following comments on the draft:

1. I did not understand why we have a seperate CC and CC/CV mode. In
other words when would CV not be required? Some justification on why
some decisions have been taken would be helful, rather than just the
packet formats.

2. If we have CV it is good to be able to allow different packet sizes
te test a packet. So the packet should be like:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|     Flags     |0xHH  MPLS-TP CV/CC Code Point |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ACH TLV Header                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~          Unique MEP-ID of source of the BFD packet            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. For BFD profile for MPLS-TP we should probably clarify that echo
function in the asynch mode is not supported.

4. I think an error BFD packet should not bring the BFD session to
down. The draft states that:

   On a Sink MEP, a BFD session is declared Down if one of the following
   defects identified by the proactive CC-CV functions occurs:
     - an unexpected globally unique Source MEP identifier is received

An error BFD packet in my view should be discraded and the respective
conutners need to be updated.

5. The Admin Down state section unnecessarily confuses/ breaks the BFD
specification (for bidirectional sessions). It states that:

   When the MEP source function is disabled, BFD Control packets
   SHOULD be sent in AdminDown state for a period equal
   to (bfd.DesiredMinTxInterval * bfd.DetectMult) in order to ensure
   that the remote system is aware of the state change.

However a packet is never sent at  but also is based on the peers
RxInterval and we should not voilate the same. So BFD packets should
be sent "at least" till bfdSessNegotiatedInterval * bfdDetectMult and
can be sent for more. Note this interval can be bigger than the
interval you have specified in your document.

6. Section 3.4.2 should be clarified with respect to the slow timer
and fast timer, as that is how BFD sessions are currently controlled.
Also this section seems to change the BFD behavior but does not
clarify the same. Should the "Required Min RX Interval" be a big value
greater than the peer "esired Min TX Interval field"? If so an
explicit statement for the same needs to be added.

7.  Section 3.4.2 should come before 3.4.1.

Thanks,
Vishwas

On Tue, May 11, 2010 at 6:26 AM, David Allan I
<[email-masked]> wrote:
> Hi Folks
>
> Another version of the draft was just posted. This simply corrects artifacts
> from the resolving ID-nits process and other non-technical content
> mistakes...
>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 15:11:04 -0400

Hi Greg:

Thanks for the detailed review... some responses that reflect my opinions...

 *   The following sentence in the Abstract doesn't read right "Continuity Check monitors the integrity of the continuity of the path for any loss of continuity defect." Perhaps "CC monitors the path for any loss of continuity" or "CC monitors continuity of the path for any defect or loss."

We'll find a way to improve the wording...

 *   Capitalization for Connectivity Verification (CV) and Continuity Check (CC) should be consistent in the text (second sentence in second paragraph of the Abstract)

Good catch

 *   I think that it would be logical to move Section 2.2 towards end part of the document as it summarizes questions still open for discussion

It will disappear eventually.... I liked it up front as it was the stuff that really needed resolving... ;-)

 *   Section 3 - distinct encapsulations for CC and CV might pose a challenge for efficient and scalable HW support. That might be argument for merging CC and CV

I'd tend to agree. But we need the WG to sort that one out.

 *   Bullet #2 (CV) doesn't mention that the RDI functionality is supported (according to bullet #3 RDI is supported by both CC and CV)

Will address in the next revision

 *   I think that the following statement will benefit from listing specific examples "It's possible to run BFD in CC mode on some transport paths and BFD in CV mode on other transport paths."

I'm not sure what would constitute a good example, suggestions welcome.

 *   "For a given Maintenance Entity Group (MEG) only one mode can be used." Though the sentence that follows expands this statement I'd propose to add "for the lifetime of that MEG."

That one appear to make sense, changing horses in midstream would appear as a mis-connectivity defect at some point.

 *   Section 3.4 Why an associated bi-directional connection presents a special case (requires configuration on two MEs) in regard to state of a BFD session? And would state of BFD session on p2mp path be determined by configuration on all possible MEs or a subset of MEs?

I think that could be a discussion point...and I believe that distinction is a hangover of historical discussions and that distinction also exists in the OAM framework. So it would be good to get it right there as well.

 *   Section 3.5 "This rate is typically a fixed value for the lifetime of the session." If terms "BFD session" and "session" are used interchangeably, then it would be helpful to add such statement.

We'll edit for consistency in the next version.

 *   "This document specifies bi-directional BFD for p2p transport paths ..." If this statement defines the scope of the document it would be reasonable to mention the scope in the Abstract and/or Introduction

OK

 *   "In the rare circumstance where an operator has a reason to change session parameters, poll/final discipline is used." Though this functionality is native to BFD we're not obliged to use it. Operator can simply take the BFD session into Admin Down state , reconfigure the timers, and bring it Up again.

I suppose they could, we actually wanted the P/F discipline.

 *   "The base spec is unclear on aspects of how a session with a BFD source set to zero interval behaves." Setting MinRxInterval, in fact the BFD base uses "Required Min RX Interval" term in regard to BFD session originator, to zero commands remote BFD peer not to send BFD Control packets. The peer sets its RemoteMinRxInterval accordingly.

Not quite understanding your point...

 *   The first clarification in Section 3.5 (p.7) regarding behavior of p2p BFD session, in my view, doesn't consider operation over unidirectional p2p connection.

No, uni-directional paths are not in this doc, whether a separate doc or future version is TBD.

 *   I think that the following sentence "The second is that the originating MEP (the one with a non-zero TxInterval) will ignore a DOWN state received from a zero interval peer" can be clarified. Both end-points of the BFD session might have non-zero DesiredMinTxInterval but only one would have RemoteMinRxInterval set to zero. Perhaps the following change will make it better "The second is that MEP with non-zero RemoteMinRxInterval will ignore DOWN state received from a peer if the MEP set Required MinRx Interval to zero at session initialization."

I like that.

 *   Session 3.5.1 As mentioned above, I think that consideration for unidirectional p2p connection is missing. Would CC/CV session be initiated in-band and/or out-band? Perhaps this is a gap that needs to be addressed with RSVP-TE (for LSP) and Targeted LDP (for  PW) extensions. Or mention use of LSP-ping to bootstrap BFD session.

IMO that is FFS.

 *   Section 3.5.2 " 2. BFD control packets are received with an unexpected encapsulation (Mis-connectivity defect), these include - a PW receiving a packet with a GAL - an LSP receiving an IP header instead of a GAL (note there are other possibilities but these can also alias ..." I think that mis-encapsulated packets must be not delivered to the BFD (e.g. wrong ACH Code Point) but dropped and proper stats (MIB?) incremented. The CC/CV will see this as Loss of Continuity then

Issue is dataplane supports merging, so I can be recieving both valid and mis-directed BFD packets simulttaneously.... ideally because they can be different periodicities, I'd want to know the arrival rate of the mis-directed ones so I do not flap if there is a significant delta between the misdirected packets and the correct ones... it is an inconvenient problem.. ;-)

 *
 *   Section 3.5.4 "Loss of continuity", "loss of connectivity" - capitalization J

OK

 *   I think that we have Loss of Continuity and Mis-connectivity defects. Do we have Loss of Connectivity? Isn't it the same defect condition as Loss of Continuity?

Again needs an editing for consistency pass, thanks

cheers
D

<snipped>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 15:37:32 -0400

Hi Vishwas: 

Thanks for your comments, some feedback from this editor in line prefaced with DA>

I had comments on the previos version of the draft. If there have been no changes they would probably hold good for this version too.

DA> As I said, no content or formatting changes from 03 whatsoever, so comments from 03 are perfectly valid. I am concerned that you are working from 02 based on one comment below...

1. I did not understand why we have a seperate CC and CC/CV mode. In other words when would CV not be required? Some justification on why some decisions have been taken would be helful, rather than just the packet formats.

DA> That is a discussion topic that dates back to the OAM requirements draft and carries into the OAM framework, so whatever passes for justification predates this draft. Arguments for keeping them separate relate to the overhead of parsing the MEP ID TLV for all OAM CC messages. Arguments in favor of keeping them together are simplicity of configuration, consistency of implementation (at least until some other TLV appears..), and overall broader fault coverage.

2. If we have CV it is good to be able to allow different packet sizes te test a packet. So the packet should be like:

   0                   1                   2                   3

DA> If the suggestion is an additional padding TLV can be inserted, I actually do not think we want that for a proactive tool as it simply comsumes bandwidth all the time. I believe an on demand CC/CV would be more along the lines of LSP PING functionality which can be suitably padded for that sort of test today. That is covered in section 6.1 of the OAM framework draft...

3. For BFD profile for MPLS-TP we should probably clarify that echo function in the asynch mode is not supported.

DA> Current draft does state that it is purely BFD async mode... We can go further if you think it is necessary...

4. I think an error BFD packet should not bring the BFD session to down. The draft states that:

An error BFD packet in my view should be discraded and the respective conutners need to be updated.

DA> If one thinks traffic is leaking into an LSP from some unknown source, the plan is to both take the LSP down, and block traffic so misdirected traffic does not get out of the network. Actual ideal is that the LSP was protected in some form, and the traffic will be switched to a path that is not being leaked into or otherwise corrupted. So IMO both DOWN and blocking of traffic are desirable behaviours...

5. The Admin Down state section unnecessarily confuses/ breaks the BFD specification (for bidirectional sessions). It states that:

However a packet is never sent at  but also is based on the peers RxInterval and we should not voilate the same. So BFD packets should be sent "at least" till bfdSessNegotiatedInterval * bfdDetectMult and can be sent for more. Note this interval can be bigger than the interval you have specified in your document.

DA> Are you looking at version 02 not version 03/04. We thought the clarifications in 03 sorted this and made it clearer. This text is not in the recently posted version(s) and I had to go back to 02 to find it.

DA> Hence, in adcance, my apologies for any confusion by the updating of 03 with 04.

6. Section 3.4.2 should be clarified with respect to the slow timer and fast timer, as that is how BFD sessions are currently controlled.
Also this section seems to change the BFD behavior but does not clarify the same. Should the "Required Min RX Interval" be a big value greater than the peer "esired Min TX Interval field"? If so an explicit statement for the same needs to be added.

DA> We'll review accordingly, for 7 below as well. But again, not sure what version you are working from...

Cheers
Dave
<snipped to end>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 May 2010 12:45:07 -0700

Hi David,

Let me get back to you after reading the latest version. I found the
comments lying in my drafts folder which I assumed were for version
03.

I will get back with comments with the latest version of the draft.

thanks,
Vishwas

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 May 2010 13:30:01 -0700

Hi Dave,

I also have a comment:

- the role and processing of "your discriminator" is not clear from the text. The text says it must be set to a non-zero value. But can it be changed? Is it checked on reception or is it ignored? If checked, then against what value is it checked? What happens if it doesn't match that value, what happens if is set to zero?

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 18:27:17 -0400

Hi Shahram:

That is an area that might need a bit of embellishment in the document :-( 

At the moment I consider BFD Base spec to be the authority. Which means the My discriminator field is non zero and has meaning (e.g. is checked by existing implementations). Your discriminator is set to zero until such time as it is known. As described in section 6.3 of the BFD base spec, the discriminator is used by implementations in a way analogous to a per platform label for indexing BFD state, so I'd expect that not to change...which means other misbranching tests would appear to be comparing received information in the GACH TLV etc. with data elements indexed off the discriminator...

So in that regard I'd consider the discriminators to be invariant once established for a session and having value even if appearently redundant in the presence of (for example) a MEP ID TLV. An unknown discriminator, or one to which other associated data elements (MEP ID etc.) did not match would constitute a mis-connectivity fault. (item 4 in 3.5.2 in the draft) although this could also be applied to CC to produce a non-authoritative CV capability as well...a node receiving CC with an unexpected disciminator by itself being sufficient to declare a mis-connectivity fault. IMO it is the mis-connectivity scenarios when running CC that are a bit of a weak spot in the draft at the moment because there is some CV capability inherent to getting bad discriminator, bad encapsulation of OAM packets etc. The blurring of the two functions IMO is getting a bit butt ugly....

I hope this helps
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 18:35:43 -0400

One additional clarification....

That the discriminators are invariant is not exactly correct. Being receiver administered, the receiver can choose to change it (according to the base spec). But I'd suspect it requires both old and new discriminators to be supported until the far end authoritatively was using new in order to make messing with them hitless...any change needing to allow for control packets in flight. IMO purely an implementation decision by the receiver implementation.

Cheers
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 May 2010 15:44:11 -0700

Hi Dave,

You said:

" As described in section 6.3 of the BFD base spec, the discriminator is used by implementations in a way analogous to a per platform label for indexing BFD state, so I'd expect that not to change..."

I don't think this is what the draft says:

" MPLS labels at peer MEPs are used to provide context for the received BFD packets. In the BFD control packet the discriminator values have either local or no significance."

So is the Label the session identifier or "your discriminator" or both?

Thanks,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Shahram:

I hope this helps
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 18:54:51 -0400

That is somewhere where the wording can be improved ..

'Your discriminator' is zero if not known (hence no significance) or if non-zero it has local (to the platform) significance....

I know, I know. It could be a lot clearer, and will be next rev...

D 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:44 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

You said:

Thanks,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Shahram:

I hope this helps
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 May 2010 15:58:22 -0700

Hi Dave,

What I want to know is should "your discriminator" be unique per BFD session or not? It seems from the draft that it does not  have to be unique, because it is not used to identify the BFD session.

Regards,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 3:55 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:44 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

You said:

Thanks,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Shahram:

I hope this helps
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 May 2010 19:11:15 -0400

"Your discriminator" is the hint a source MEP sends a sink MEP to allow the sink MEP to locally index its data structures for BFD state. 

It is the value the sink MEP chooses it to be, and the sink MEP advertises it in the reverse direction as "my discriminator"....

It only has to be unique to the sink MEP, who administers it. But the source MEP needs to send that value to the sink MEP AFAIK in order to minimize the impact on existing implementations. It is inherent to the design of BFD....

If some mis-connectivity defect aliases the discrimiator, the additional tests of uniqueness added to CV should detect this.

I hope that is clearer...

Cheers
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:58 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

Regards,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 3:55 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 6:44 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

You said:

Thanks,
Shahram

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Shahram:

I hope this helps
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Dave,

I also have a comment:

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, May 11, 2010 12:38 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi Vishwas: 

   0                   1                   2                   3

Cheers
Dave
<snipped to end>

---

From: <[email-masked]>
Date: Wed, 12 May 2010 09:46:22 +0100

Hi Dave...have to confess up-front I simply have not had time to read
the draft yet (I will soon) but I wanted to provide a few quick comments
in this general area:

-	a CC function (ie sans SA) is really waste of time....we must
always have a CV function that contains a proper SA for the
simple/sparse always-on defect detecting OAM.

-	I am aware that the term discriminator came from BFD (as some
local source generated ID) but this really ought to be the proper SA
that has network-significance for the LSP connection in MPLS-TP.
Aside=> I was not over impressed by what I can see the MPLS-TP
identifiers draft
http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-01 ....if
anything this tends to show what a hotchpotch addressing is in this
whole area.

-	I am assuming the defect detection always-on CV function will be
synchronised in activation/deactivation with whatever MP or CP process
sets-up/tears-down the LSP connection in MPLS-TP....this is obviously
practically rather important.

-	I ran a network design team (all modes, various technologies)
for many years.  For a whole tranche of very practical reasons real
networks must operate well to the LHS of the congestion knee for >99% of
time...if they don't the base network design and planning cycle
methodology is broken.  This means QoS must not have much practical
significance in real-world networks (and in transport networks it really
ought to be a total non-issue - see next bullet)...and when it does it
not a 'temporal urgency' issue anyway but rather a 'survivability
importance' issue......and of course now we are operating to the RHS of
the congestion knee (ie the network essentially broken) and, most
significantly, *as a server transport network providing a transparent
client service to its clients* we must make no judgement call on which
client message/file/stream applications survive...since we must not be
attempting to infer meaning of their symbols.

Note - Another way of interpreting what I have just said is that in
co-ps and co-cs mode networks it is the parent connection entity that
carries the 'importance' semantic and not the child traffic units it
carries.  In fact this behaviour is forced (like many other good arch
behaviours, eg OOB CP/MP, no merging, etc) in the co-cs mode but we have
to conscious provide good engineering design to get the right behaviours
in the co-ps mode.

-	Transparency is perhaps the key service a transport network
provides to its clients.  As noted above, a transparent transport
network must not attempt to infer client symbol meaning....and a key
corollary of this is that a transport network MUST preserve the ordering
of its client symbols...what this means is that a connection can
practically only provide a single QoS class.

Note - Practical considerations of entry/exit of degraded and
unavailable states and when to invoke prot-sw say, can become rather
complex if one tries to make some judgement on this based on multiple
QoS classes in a single connection.

-	 Given real networks will operate for the vast majority of time
well to the LHS of the congestion knee then PM monitoring should
normally be thought of as an ad-hoc/on-demand function rather than an
always-on function.  There is always a cost to
generate/collect/process(OSS) PM metrics in networks...I have known
instances where PM collection (when it is provided, often it isn't) has
been turned-off and simply used as a on-demand problem diagnostics tool
because of this.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Allan I
> Sent: 11 May 2010 23:27
> To: Shahram Davari
> Cc: [email-masked]
> At the moment I consider BFD Base spec to be the authority. 
> Which means the My discriminator field is non zero and has 
> meaning (e.g. is checked by existing implementations). Your 
> discriminator is set to zero until such time as it is known. 
> As described in section 6.3 of the BFD base spec, the 
> discriminator is used by implementations in a way analogous 
> to a per platform label for indexing BFD state, so I'd expect 
> that not to change...which means other misbranching tests 
> would appear to be comparing received information in the GACH 
> TLV etc. with data elements indexed off the discriminator...
> 
> So in that regard I'd consider the discriminators to be 
> invariant once established for a session and having value 
> even if appearently redundant in the presence of (for 
> example) a MEP ID TLV. An unknown discriminator, or one to 
> which other associated data elements (MEP ID etc.) did not 
> match would constitute a mis-connectivity fault. (item 4 in 
> 3.5.2 in the draft) although this could also be applied to CC 
> to produce a non-authoritative CV capability as well...a node 
> receiving CC with an unexpected disciminator by itself being 
> sufficient to declare a mis-connectivity fault. IMO it is the 
> mis-connectivity scenarios when running CC that are a bit of 
> a weak spot in the draft at the moment because there is some 
> CV capability inherent to getting bad discriminator, bad 
> encapsulation of OAM packets etc. The blurring of the two 
> functions IMO is getting a bit butt ugly....
> 
> I hope this helps
> D
> 
> 
> 
> 
> - the role and processing of "your discriminator" is not 
> clear from the text. The text says it must be set to a 
> non-zero value. But can it be changed? Is it checked on 
> reception or is it ignored? If checked, then against what 
> value is it checked? What happens if it doesn't match that 
> value, what happens if is set to zero?
> 
> Thanks,
> Shahram
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Allan I
> I had comments on the previos version of the draft. If there 
> have been no changes they would probably hold good for this 
> version too.
> 
> DA> As I said, no content or formatting changes from 03 
> whatsoever, so comments from 03 are perfectly valid. I am 
> concerned that you are working from 02 based on one comment below...
> 
> 1. I did not understand why we have a seperate CC and CC/CV 
> mode. In other words when would CV not be required? Some 
> justification on why some decisions have been taken would be 
> helful, rather than just the packet formats.
> 
> DA> That is a discussion topic that dates back to the OAM 
> requirements draft and carries into the OAM framework, so 
> whatever passes for justification predates this draft. 
> Arguments for keeping them separate relate to the overhead of 
> parsing the MEP ID TLV for all OAM CC messages. Arguments in 
> favor of keeping them together are simplicity of 
> configuration, consistency of implementation (at least until 
> some other TLV appears..), and overall broader fault coverage.
> 
> 2. If we have CV it is good to be able to allow different 
> packet sizes te test a packet. So the packet should be like:
> 
>    0                   1                   2                   3
> DA> If the suggestion is an additional padding TLV can be 
> inserted, I actually do not think we want that for a 
> proactive tool as it simply comsumes bandwidth all the time. 
> I believe an on demand CC/CV would be more along the lines of 
> LSP PING functionality which can be suitably padded for that 
> sort of test today. That is covered in section 6.1 of the OAM 
> framework draft...
> 
> 
> 3. For BFD profile for MPLS-TP we should probably clarify 
> that echo function in the asynch mode is not supported.
> 
> DA> Current draft does state that it is purely BFD async 
> mode... We can go further if you think it is necessary...
> 
> DA> If one thinks traffic is leaking into an LSP from some 
> unknown source, the plan is to both take the LSP down, and 
> block traffic so misdirected traffic does not get out of the 
> network. Actual ideal is that the LSP was protected in some 
> form, and the traffic will be switched to a path that is not 
> being leaked into or otherwise corrupted. So IMO both DOWN 
> and blocking of traffic are desirable behaviours...
> 
> 5. The Admin Down state section unnecessarily confuses/ 
> breaks the BFD specification (for bidirectional sessions). It 
> states that:
> 
> However a packet is never sent at  but also is based on the 
> peers RxInterval and we should not voilate the same. So BFD 
> packets should be sent "at least" till 
> bfdSessNegotiatedInterval * bfdDetectMult and can be sent for 
> more. Note this interval can be bigger than the interval you 
> have specified in your document.
> 
> DA> Are you looking at version 02 not version 03/04. We 
> thought the clarifications in 03 sorted this and made it 
> clearer. This text is not in the recently posted version(s) 
> and I had to go back to 02 to find it.
> 
> 6. Section 3.4.2 should be clarified with respect to the slow 
> timer and fast timer, as that is how BFD sessions are 
> currently controlled.
> Also this section seems to change the BFD behavior but does 
> not clarify the same. Should the "Required Min RX Interval" 
> be a big value greater than the peer "esired Min TX Interval 
> field"? If so an explicit statement for the same needs to be added.
> 
> DA> We'll review accordingly, for 7 below as well. But again, 
> not sure what version you are working from...
>

---

From: David Allan I <[email-masked]>
Date: Wed, 12 May 2010 07:46:24 -0400

HI Neil: 

You wrote...
..have to confess up-front I simply have not had time to read the draft yet (I will soon) but I wanted to provide a few quick comments in this general area:

DA> Comments welcome....

-	a CC function (ie sans SA) is really waste of time....we must
always have a CV function that contains a proper SA for the simple/sparse always-on defect detecting OAM.

DA> As I've indicated elsewhere this is a discussion item. Vote noted.

-	I am aware that the term discriminator came from BFD (as some
local source generated ID) but this really ought to be the proper SA that has network-significance for the LSP connection in MPLS-TP.

DA> As I indicated to Shahram, it is simply a "hint" to help implementations index state, which in the TP/CV case would include a proper SA. 

Aside=> I was not over impressed by what I can see the MPLS-TP identifiers draft
http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-01 ....if anything this tends to show what a hotchpotch addressing is in this whole area.

DA> I'm sure the authors would welcome suggestions to improve the document.

-	I am assuming the defect detection always-on CV function will be
synchronised in activation/deactivation with whatever MP or CP process sets-up/tears-down the LSP connection in MPLS-TP....this is obviously practically rather important.

DA> Can I point you at draft-bellegamba...

-	I ran a network design team (all modes, various technologies)
for many years.  For a whole tranche of very practical reasons real networks must operate well to the LHS of the congestion knee for >99% of time...if they don't the base network design and planning cycle methodology is broken.  This means QoS must not have much practical significance in real-world networks (and in transport networks it really ought to be a total non-issue - see next bullet)...and when it does it not a 'temporal urgency' issue anyway but rather a 'survivability importance' issue......and of course now we are operating to the RHS of the congestion knee (ie the network essentially broken) and, most significantly, *as a server transport network providing a transparent client service to its clients* we must make no judgement call on which client message/file/stream applications survive...since we must not be attempting to infer meaning of their symbols.

Note - Another way of interpreting what I have just said is that in co-ps and co-cs mode networks it is the parent connection entity that carries the 'importance' semantic and not the child traffic units it carries.  In fact this behaviour is forced (like many other good arch behaviours, eg OOB CP/MP, no merging, etc) in the co-cs mode but we have to conscious provide good engineering design to get the right behaviours in the co-ps mode.

-	Transparency is perhaps the key service a transport network
provides to its clients.  As noted above, a transparent transport network must not attempt to infer client symbol meaning....and a key corollary of this is that a transport network MUST preserve the ordering of its client symbols...what this means is that a connection can practically only provide a single QoS class.

DA> IMO mapping of client symbols to a PHB in an E-LSP is simply a slightly more sophisticated example of the principle you elucidate above. There is no layer violation at intermediate nodes, and ordering within a PHB is preserved.

Note - Practical considerations of entry/exit of degraded and unavailable states and when to invoke prot-sw say, can become rather complex if one tries to make some judgement on this based on multiple QoS classes in a single connection.

DA> They can only fate share as a group, and as you observe if the operation is 99% of the time to the LHS of the knee, a PS to address a degrade of a portion of a PHB should be a non-existant event, the individual PHBs existing to preserve guarantees during the 1% periods of bursty behavior. I believe this plays into your following remark as well (w.r.t. proactive PM).

-	 Given real networks will operate for the vast majority of time
well to the LHS of the congestion knee then PM monitoring should normally be thought of as an ad-hoc/on-demand function rather than an always-on function.  There is always a cost to
generate/collect/process(OSS) PM metrics in networks...I have known instances where PM collection (when it is provided, often it isn't) has been turned-off and simply used as a on-demand problem diagnostics tool because of this.

DA> That is useful feedback

best
D

> Which means the My discriminator field is non zero and has meaning 
> (e.g. is checked by existing implementations). Your discriminator is 
> set to zero until such time as it is known.
> As described in section 6.3 of the BFD base spec, the discriminator is 
> used by implementations in a way analogous to a per platform label for 
> indexing BFD state, so I'd expect that not to change...which means 
> other misbranching tests would appear to be comparing received 
> information in the GACH TLV etc. with data elements indexed off the 
> discriminator...
> 
> So in that regard I'd consider the discriminators to be invariant once 
> established for a session and having value even if appearently 
> redundant in the presence of (for
> example) a MEP ID TLV. An unknown discriminator, or one to which other 
> associated data elements (MEP ID etc.) did not match would constitute 
> a mis-connectivity fault. (item 4 in
> 3.5.2 in the draft) although this could also be applied to CC to 
> produce a non-authoritative CV capability as well...a node receiving 
> CC with an unexpected disciminator by itself being sufficient to 
> declare a mis-connectivity fault. IMO it is the mis-connectivity 
> scenarios when running CC that are a bit of a weak spot in the draft 
> at the moment because there is some CV capability inherent to getting 
> bad discriminator, bad encapsulation of OAM packets etc. The blurring 
> of the two functions IMO is getting a bit butt ugly....
> 
> I hope this helps
> D
> 
> 
> 
> 
> - the role and processing of "your discriminator" is not clear from 
> the text. The text says it must be set to a non-zero value. But can it 
> be changed? Is it checked on reception or is it ignored? If checked, 
> then against what value is it checked? What happens if it doesn't 
> match that value, what happens if is set to zero?
> 
> Thanks,
> Shahram
> 
> whatsoever, so comments from 03 are perfectly valid. I am concerned 
> that you are working from 02 based on one comment below...
> 
> requirements draft and carries into the OAM framework, so whatever 
> passes for justification predates this draft.
> Arguments for keeping them separate relate to the overhead of parsing 
> the MEP ID TLV for all OAM CC messages. Arguments in favor of keeping 
> them together are simplicity of configuration, consistency of 
> implementation (at least until some other TLV appears..), and overall 
> broader fault coverage.
> 
> inserted, I actually do not think we want that for a proactive tool as 
> it simply comsumes bandwidth all the time.
> I believe an on demand CC/CV would be more along the lines of LSP PING 
> functionality which can be suitably padded for that sort of test 
> today. That is covered in section 6.1 of the OAM framework draft...
> 
> 
> unknown source, the plan is to both take the LSP down, and block 
> traffic so misdirected traffic does not get out of the network. Actual 
> ideal is that the LSP was protected in some form, and the traffic will 
> be switched to a path that is not being leaked into or otherwise 
> corrupted. So IMO both DOWN and blocking of traffic are desirable 
> behaviours...
> 
> thought the clarifications in 03 sorted this and made it clearer. This 
> text is not in the recently posted version(s) and I had to go back to 
> 02 to find it.
> 
> clarify the same. Should the "Required Min RX Interval"
> be a big value greater than the peer "esired Min TX Interval field"? 
> If so an explicit statement for the same needs to be added.
>