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

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

Hi Dave 

I disagree. The text explicitly says the label is used as session identifier and not your discriminator. 

THX 
SD

----- Original Message -----
From: David Allan I <[email-masked]>
To: Shahram Davari
Cc: [email-masked] <[email-masked]>
Sent: Tue May 11 16:11:15 2010
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

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

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

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:

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

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:

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

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

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.

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
    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                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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:

   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.

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:

   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.

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

7.  Section 3.4.2 should come before 3.4.1.

Cheers
Dave
<snipped to end>
_______________________________________________
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 20:23:55 -0400

I've lost the plot, what are you disagreeing with, BFD base or draft-asm....?

If the latter, you are welcome to suggest improvements on this list, if the former there is a separate WG...

D 

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

Hi Dave 

THX
SD

----- Original Message -----
From: David Allan I <[email-masked]>
To: Shahram Davari
Cc: [email-masked] <[email-masked]>
Sent: Tue May 11 16:11:15 2010
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

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>