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

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

Hi Dave 

I am talking about the asm draft. This draft explicitly says your discriminator is not used for mplstp. 

THX 
SD

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

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 

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 22:59:45 -0400

Hi Shahram:

Other than the fact that the wording can be improved, I do not see anything in conflict with the usage of the discriminator in the BFD base draft.

If it appears so, that is a matter of interpretation and draft-asm requires improvement. Frankly we were more focused on getting the state transitions correct in this version.

I've offered what I believe to be a more precise interpretation in this thread consistent with the base draft, and we will edit the document accordingly in the next version...

Does that work for you?

Cheers
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 8:40 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 17:23:55 2010
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 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>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 May 2010 12:15:40 -0700

Dear David,
after reading discussion between Shahram and you I've got a question whether
receiving unexpected Your Discriminator constitutes mis-connectivity fault.
Another question is with demultiplexing BFD sessions (CC/CV sessions)
between pair of end-points. The BFD Base is, in my view, pretty strict on
what provides context and must be used to demultiplex BFD sessions between
two end-points:
"Once the remote end echoes back the local discriminator, all further
received packets are demultiplexed based on the Your Discriminator field
only (which means that, among other things, the source address field can
change or the interface over which the packets are received can change, but
the packets will still be associated with the proper session)."
I read that as tunnel can change (i.e. FRR in use) but the session (based on
Your Discriminator) is properly identified. I think that wording in Section
3.5.6 "MPLS labels at peer MEPs are used to provide context for the received
BFD packets." is not in sync with the BFD Base.

Regards,
Greg

On Tue, May 11, 2010 at 7:59 PM, David Allan I
<[email-masked]>wrote:

> Hi Shahram:
>
> Other than the fact that the wording can be improved, I do not see anything
> in conflict with the usage of the discriminator in the BFD base draft.
>
> If it appears so, that is a matter of interpretation and draft-asm requires
> improvement. Frankly we were more focused on getting the state transitions
> correct in this version.
>
> I've offered what I believe to be a more precise interpretation in this
> thread consistent with the base draft, and we will edit the document
> accordingly in the next version...
>
> Does that work for you?
>
> Cheers
> D
>
> "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.
>
> 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
>
> 'Your discriminator' is zero if not known (hence no significance) or if
> non-zero it has local (to the platform) significance....
>
> " 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..."
>
> " 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."
>
> 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
>
> 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> 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.
>

---

From: David Allan I <[email-masked]>
Date: Wed, 12 May 2010 15:26:21 -0400

Hi greg:

An unexpected and non-zero "your discriminator" SHOULD be a mis-connectivity fault.  This would only be detected if the particular discriminator value was not in use at all by the sink MEP. If it was in use, further testing would be required to determine if the discriminator was aliasing another session (e.g. CV processing of a Source MEP TLV).

The comment on section 3.5.6 highlights an issue where draft-asm-02 deviated from the base spec. That being said, IMO the label of arrival should be somthing that is checked to ensure it matches the label of arrival associated with the discriminator value else we could have an undetected misconnectivy fault occuring in the last hop, which does sort of suggest they can stunt double for each other...although interoperability does demand that use of "your discriminator" follows the rules of the BFD base spec....

my 2 cents
cheers
D

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, May 12, 2010 3:16 PM
To: David Allan I
Cc: Shahram Davari; [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Dear David,
after reading discussion between Shahram and you I've got a question whether receiving unexpected Your Discriminator constitutes mis-connectivity fault.
Another question is with demultiplexing BFD sessions (CC/CV sessions) between pair of end-points. The BFD Base is, in my view, pretty strict on what provides context and must be used to demultiplex BFD sessions between two end-points:
"Once the remote end echoes back the local discriminator, all further received packets are demultiplexed based on the Your Discriminator field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session)."
I read that as tunnel can change (i.e. FRR in use) but the session (based on Your Discriminator) is properly identified. I think that wording in Section 3.5.6 "MPLS labels at peer MEPs are used to provide context for the received BFD packets." is not in sync with the BFD Base.

Regards,
Greg

On Tue, May 11, 2010 at 7:59 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram:

Does that work for you?

Cheers
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 8:40 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>>
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
Sent: Tue May 11 17:23:55 2010
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 8:03 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>>
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 6:58 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 3:55 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 6:44 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]> [mailto:[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]<mailto:[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>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: David Allan I <[email-masked]>
Date: Wed, 12 May 2010 15:40:52 -0400

Let me correct my phrasing below, bolded in red.
cheers
D
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, May 12, 2010 3:26 PM
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Hi greg:

An unexpected and non-zero "your discriminator" SHOULD be a mis-connectivity fault.  This would only be detected if the particular discriminator value was not in use at all by  BFD at the node hosting the  sink MEP  hence the recevied BFD packet could not be mapped to a sink MEP . If it was in use, further testing would be required to determine if the discriminator was aliasing another session (e.g. CV processing of a Source MEP TLV).

The comment on section 3.5.6 highlights an issue where draft-asm-02 deviated from the base  BFD  spec. That being said, IMO the label of arrival should be somthing that is checked to ensure it matches the label of arrival associated with the discriminator value else we could have an undetected misconnectivy fault occuring in the last hop, which does sort of suggest the  discriminator and the label of arrival  can stunt double for each other...although interoperability does demand that use of "your discriminator" follows the rules of the BFD base spec....

my 2 cents
cheers
D

Dear David,

Regards,
Greg

Does that work for you?

Cheers
D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 8:40 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>>
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
Sent: Tue May 11 17:23:55 2010
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 8:03 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>>
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 6:58 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 3:55 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

D

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 6:44 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 3:27 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Tuesday, May 11, 2010 4:30 PM
To: David Allan I
Cc: [email-masked]<mailto:[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]> [mailto:[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]<mailto:[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: John E Drake <[email-masked]>
Date: Wed, 12 May 2010 12:43:04 -0700

+1

> Sent: Wednesday, May 12, 2010 12:26 PM
> To: Greg Mirsky
> Cc: [email-masked]
> An unexpected and non-zero "your discriminator" SHOULD be a mis-
> connectivity fault.  This would only be detected if the particular
> discriminator value was not in use at all by the sink MEP. If it was in
> use, further testing would be required to determine if the discriminator
> was aliasing another session (e.g. CV processing of a Source MEP TLV).
>
> The comment on section 3.5.6 highlights an issue where draft-asm-02
> deviated from the base spec. That being said, IMO the label of arrival
> should be somthing that is checked to ensure it matches the label of
> arrival associated with the discriminator value else we could have an
> undetected misconnectivy fault occuring in the last hop, which does sort
> of suggest they can stunt double for each other...although
> interoperability does demand that use of "your discriminator" follows the
> rules of the BFD base spec....
>
> my 2 cents
> cheers
> D
>
> after reading discussion between Shahram and you I've got a question
> whether receiving unexpected Your Discriminator constitutes mis-
> connectivity fault.
> change or the interface over which the packets are received can change,
> but the packets will still be associated with the proper session)."
> I read that as tunnel can change (i.e. FRR in use) but the session (based
> on Your Discriminator) is properly identified. I think that wording in
> Section 3.5.6 "MPLS labels at peer MEPs are used to provide context for
> the received BFD packets." is not in sync with the BFD Base.
>
> Regards,
> Greg
>
>
> <[email-masked]> wrote:
>
>
>       Hi Shahram:
>
>       Other than the fact that the wording can be improved, I do not see
> anything in conflict with the usage of the discriminator in the BFD base
> draft.
>
>       If it appears so, that is a matter of interpretation and draft-asm
> requires improvement. Frankly we were more focused on getting the state
> transitions correct in this version.
>
>       I've offered what I believe to be a more precise interpretation in
> this thread consistent with the base draft, and we will edit the document
>       "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
>       If some mis-connectivity defect aliases the discrimiator, the
> additional tests of uniqueness added to CV should detect this.
>
> 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
>
>       'Your discriminator' is zero if not known (hence no significance) or
> if non-zero it has local (to the platform) significance....
>
>       " As described in section 6.3 of the BFD base spec, the
> change..."
>       " 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."
>
>       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
> 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
>       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
>       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
> 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...
>
>
>       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:
>
> 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
>       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: Greg Mirsky <[email-masked]>
Date: Wed, 12 May 2010 21:18:17 -0700

Resending with clipped older posts to fit into 40K

On Wed, May 12, 2010 at 8:07 PM, Greg Mirsky <[email-masked]> wrote:

> Hi Shahram,
> I agree with Dave's point but would try to present a case where MPLS Label
> is not sufficient to establish context of BFD session. Noted, that scenario
> is based on my assumption that FRR one-to-one are not excluded from MPLS-TP
> and are applicable to associated bidirectional LSP as local protection. If
> assumptions correct, than in case when tail-end is MP, the LSP and detour is
> OAM'd by their respective own BFD sessions. How the tail-end treat BFD
> session of protected LSP when local protection is in use? Would it see it as
> mis-connectivity? Or the scenario is artificial because mixing local and
> end-to-end protection is, lightly speaking, not a good practice (another
> rope for an operator to hang on)?
>
> Regards,
> Greg
>
>
> On Wed, May 12, 2010 at 1:05 PM, Shahram Davari <[email-masked]>wrote:
>
>>  Hi Greg,
>>
>>
>>
>> Dave is correct.
>>
>>
>>
>> Since MPLS-TP does no support MP2P tunnels, this means that there is a
>> 1-to-1 relationship between the  Tunnel label and the BFD session for that
>> tunnel. This means that Tunnel label may be used for demultiplexing.
>> Alternatively, one could use “Your Discr” for demultiplexing too.
>>
>>
>>
>> Both the above-mentioned methods of demultiplexing works fine and should
>> not cause any interoperability issue, since both are directly or indirectly
>> advertised by the Sink MEP and both are local to the sink MEP.
>>
>>
>>
>> Thanks,
>>
>> Shahram
>>
>>
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *David Allan I
>> *Sent:* Wednesday, May 12, 2010 12:41 PM
>>
>> *To:* Greg Mirsky
>> *Cc:* [email-masked]
>> *Subject:* Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04
>>
>>
>>
>> Let me correct my phrasing below, *bolded in red.*
>>
>> cheers
>>
>> D
>>  ------------------------------
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *David Allan I
>> *Sent:* Wednesday, May 12, 2010 3:26 PM
>> *To:* Greg Mirsky
>> *Cc:* [email-masked]
>> *Subject:* Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04
>>
>> Hi greg:
>>
>>
>>
>> An unexpected and non-zero "your discriminator" SHOULD be a
>> mis-connectivity fault.  This would only be detected if the particular
>> discriminator value was not in use at all by  *BFD at the node hosting
>> the*  sink MEP  *hence the recevied BFD packet could not be mapped to a
>> sink MEP* . If it was in use, further testing would be required to
>> determine if the discriminator was aliasing another session (e.g. CV
>> processing of a Source MEP TLV).
>>
>>
>>
>> deviated from the base  BFD  spec. That being said, IMO the label of arrival
>> undetected misconnectivy fault occuring in the last hop, which does sort of
>> suggest the  *discriminator and the label of arrival*  can stunt double
>> for each other...although interoperability does demand that use of "your
>> discriminator" follows the rules of the BFD base spec....
>>
>>
>>
>> my 2 cents
>>
>> cheers
>>
>> D
>>
>>
>>  ------------------------------
>>
>> *From:* Greg Mirsky [mailto:[email-masked]]
>> *Sent:* Wednesday, May 12, 2010 3:16 PM
>> *To:* David Allan I
>> *Cc:* Shahram Davari; [email-masked]
>> *Subject:* Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04
>>
>> Dear David,
>> whether receiving unexpected Your Discriminator constitutes mis-connectivity
>> fault.
>> Section 3.5.6 "MPLS labels at peer MEPs are used to provide context for the
>> received BFD packets." is not in sync with the BFD Base.
>>
>> Regards,
>> Greg
>>
>> On Tue, May 11, 2010 at 7:59 PM, David Allan I <
>> [email-masked]> wrote:
>>
>> Hi Shahram:
>>

---

From: <[email-masked]>
Date: Thu, 13 May 2010 08:25:46 +0100

Colleagues,
 
This is hardly good design IMO.  cl-ps mode networks are always fine wrt
addressing and its relationship to DP connectivity verification since
they cannot take short-cuts on addressing, ie each/every traffic DP unit
must provide SA information and thus confirmation of correct
connectivity (because there is no connection to carry this important SA
information)....so we do not need an adjunct CV OAM flow in a cl-ps mode
network, it is self-protecting from misconnectivity.
 
Co-ps mode networks OTOH need to get their CV OAM right...and it should
not be based on any request/response message like BFD which is right for
the cl-ps mode but not for co-ps mode since here it needs to be
unidirectional.  Why?  Simply because "a connection is a constraining
construct to both traffic and OAM when there *are no misconnectivity
defects*"....so traffic or OAM never leaves a connection when it is
misconnectivity-free.  However, if we do have an unintended traffic
replication/leaking misconnectivity defect it is almost certainly going
to be unidirectional in nature ......so request/response OAM won't
elicit a response, and ergo OAM for misconnectivity detection MUST be
unidirectional (there are also other reasons why the OAM must be
unidirectional, eg p2mp connection case, on-demand Perf Mon OAM, etc). 
 
Having said this, the absolute best design solution for the co-ps mode
is to mimic the cl-ps mode and provide full SA/DA information in
each/every traffic unit (just like PBB-TE does for example). 
 
However, if we do take short-cuts on addressing in traffic units, as
indeed we can in the co-ps mode IF we assume that we respect the rules
of a connection (ie omit SA information as we assume only a single
source is allowed, and where DA only need be link-unique and acts as DA
proxy which can be swapped per link) then we need only provide full SA
information in periodic DP CV messages. 
 
But we should, IMO MUST, be using proper SA information...not just some
arbitrary locally generated sequence of bits........because we MUST
ensure that we provide network-wide unique identification of the source
of traffic in OAM messages that are verifying correct connectivity, and
so we should be using the proper SA of LSPs in either CV or a
unidirectional BFD doppelganger of this.
 
As I said at the outset, it is simply bad design to get this wrong...and
there is no excuse for technical ignorance here.  I am sure most
operators would like their suppliers to try and get it 'right first
time' (which is a clarion call in BT) more often in future.
 
<Snipped after a few mails below to try and mitigate any mail size
violation>
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Allan I
	Sent: 12 May 2010 20:41
	To: Greg Mirsky
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

	cheers
	D

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Allan I
	Sent: Wednesday, May 12, 2010 3:26 PM
	To: Greg Mirsky
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

	Hi greg:
	 
	An unexpected and non-zero "your discriminator" SHOULD be a
mis-connectivity fault.  This would only be detected if the particular
discriminator value was not in use at all by  BFD at the node hosting
the  sink MEP  hence the recevied BFD packet could not be mapped to a
sink MEP . If it was in use, further testing would be required to
determine if the discriminator was aliasing another session (e.g. CV
processing of a Source MEP TLV).
	 
	The comment on section 3.5.6 highlights an issue where
draft-asm-02 deviated from the base  BFD  spec. That being said, IMO the
label of arrival should be somthing that is checked to ensure it matches
the label of arrival associated with the discriminator value else we
could have an undetected misconnectivy fault occuring in the last hop,
which does sort of suggest the  discriminator and the label of arrival
can stunt double for each other...although interoperability does demand
that use of "your discriminator" follows the rules of the BFD base
spec....
	 
	my 2 cents
	cheers
	D

	Dear David,
	after reading discussion between Shahram and you I've got a
question whether receiving unexpected Your Discriminator constitutes
mis-connectivity fault. 
	Another question is with demultiplexing BFD sessions (CC/CV
sessions) between pair of end-points. The BFD Base is, in my view,
pretty strict on what provides context and must be used to demultiplex
BFD sessions between two end-points:
	"Once the remote end echoes back the local discriminator, all
further received packets are demultiplexed based on the Your
Discriminator field only (which means that, among other things, the
source address field can change or the interface over which the packets
are received can change, but the packets will still be associated with
the proper session)."
	I read that as tunnel can change (i.e. FRR in use) but the
session (based on Your Discriminator) is properly identified. I think
that wording in Section 3.5.6 "MPLS labels at peer MEPs are used to
provide context for the received BFD packets." is not in sync with the
BFD Base.
	
	Regards,
	Greg

		Hi Shahram:
		
		Other than the fact that the wording can be improved, I
do not see anything in conflict with the usage of the discriminator in
the BFD base draft.
		
		If it appears so, that is a matter of interpretation and
draft-asm requires improvement. Frankly we were more focused on getting
the state transitions correct in this version.
		
		I've offered what I believe to be a more precise
interpretation in this thread consistent with the base draft, and we
will edit the document accordingly in the next version...
		
		Does that work for you?

		Cheers
		D
		 <NH snipped>

---

From: David Allan I <[email-masked]>
Date: Thu, 13 May 2010 12:00:27 -0400

HI Neil:

We shouldn't confuse the role of the discriminator and authoritative identification of source/path binding required by CV....

The discriminator allows a generalized implentation (that works for IP, MPLS, MPLS_TP etc.) to quickly and simply map session state after which more authoritative identification of source becomes possible. Failing to successfully map state in the first place could be considered to be a pre-screening step.

BFD for IP/MPLS had an IP header, hence a more authoritative identification that this was not a mis-connected session was possible than is currently possible with CC under a GAL/GACH by itself, however in the presence of MP2P and PHP it could not be absolutely authoritative.

In the MPLS-TP case it can be. Given the presence of a source TLV and a labelled last hop sufficient infomation exists in both DP operation and PDU design to do this.

That is what we are documenting in draft-asm...

hope this helps
D

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 13, 2010 3:26 AM
To: David Allan I; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Draft-asm-mpls-tp-bfd-cc-cv-04

Colleagues,

This is hardly good design IMO.  cl-ps mode networks are always fine wrt addressing and its relationship to DP connectivity verification since they cannot take short-cuts on addressing, ie each/every traffic DP unit must provide SA information and thus confirmation of correct connectivity (because there is no connection to carry this important SA information)....so we do not need an adjunct CV OAM flow in a cl-ps mode network, it is self-protecting from misconnectivity.

Co-ps mode networks OTOH need to get their CV OAM right...and it should not be based on any request/response message like BFD which is right for the cl-ps mode but not for co-ps mode since here it needs to be unidirectional.  Why?  Simply because "a connection is a constraining construct to both traffic and OAM when there *are no misconnectivity defects*"....so traffic or OAM never leaves a connection when it is misconnectivity-free.  However, if we do have an unintended traffic replication/leaking misconnectivity defect it is almost certainly going to be unidirectional in nature ......so request/response OAM won't elicit a response, and ergo OAM for misconnectivity detection MUST be unidirectional (there are also other reasons why the OAM must be unidirectional, eg p2mp connection case, on-demand Perf Mon OAM, etc).

Having said this, the absolute best design solution for the co-ps mode is to mimic the cl-ps mode and provide full SA/DA information in each/every traffic unit (just like PBB-TE does for example).

However, if we do take short-cuts on addressing in traffic units, as indeed we can in the co-ps mode IF we assume that we respect the rules of a connection (ie omit SA information as we assume only a single source is allowed, and where DA only need be link-unique and acts as DA proxy which can be swapped per link) then we need only provide full SA information in periodic DP CV messages.

But we should, IMO MUST, be using proper SA information...not just some arbitrary locally generated sequence of bits........because we MUST ensure that we provide network-wide unique identification of the source of traffic in OAM messages that are verifying correct connectivity, and so we should be using the proper SA of LSPs in either CV or a unidirectional BFD doppelganger of this.

As I said at the outset, it is simply bad design to get this wrong...and there is no excuse for technical ignorance here.  I am sure most operators would like their suppliers to try and get it 'right first time' (which is a clarion call in BT) more often in future.

<Snipped after a few mails below to try and mitigate any mail size violation>

regards, Neil

Hi greg:

my 2 cents
cheers
D

Dear David,

Regards,
Greg

Does that work for you?

Cheers
D
 <NH snipped>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 13 May 2010 13:34:39 -0700

Once again hit by 40K limit. Procrustean bed seems too small for our
discussions.

On Thu, May 13, 2010 at 1:22 PM, Greg Mirsky <[email-masked]> wrote:

> Hi Shahram,
> I'm not sure that "mapping" will address my concern about this scenario.
> What is invariant in this scenario - MEP ID and Your Discriminator. As noted
> in BFD Base, BFD session remains in tact even if "the interface over which
> the packets are received can change, but the packets will still be
> associated with the proper session". Thus the MPLS Label, note that for LSP
> and Section the BoS will be GAL which has no connection context, may change
> but the BFD session must be seen as valid (no mis-connection to report).
> My conclusion on this scenario - MPLS Label does not provide demultiplexing
> for OAM.
>
> Regards,
 Greg

>
>
>
> On Thu, May 13, 2010 at 12:24 PM, Shahram Davari <[email-masked]>wrote:
>
>>  Hi Greg,
>>
>>
>>
>> I actually had thought of the scenario that you describe and it could
>> easily be accommodated by mapping both the working and protection (detour)
>> labels to the same BFD session.
>>
>>
>>
>> Regards,
>>
>> Shahram
>>
>>
>>
>> *Sent:* Wednesday, May 12, 2010 8:08 PM
>> *To:* Shahram Davari
>> *Cc:* David Allan I; [email-masked]
>>
>> "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.
>>
>> " 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
>> 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

---

From: <[email-masked]>
Date: Thu, 13 May 2010 23:07:34 +0100

Greg,
 
A further issue here which I have pointed out several times already is
that traffic DP OAM should never exist under a reserved label that is
supposed to to identify a logically OOB CP/MP network...these ought to
be like cheese/chalk.  DP OAM messages should have a labelling structure
which is as near as damn it identical to client traffic units....a 1 bit
flag in the *same* header is what should be used to distinguish the 2
cases.  I really have no good explanation why we continuously seem to
get things technically wrong here....but we are clearly getting rather
good at this.
 
regards, Neil

On Behalf Of Greg Mirsky
	Sent: 13 May 2010 21:35

	Once again hit by 40K limit. Procrustean bed seems too small for
our discussions.

	On Thu, May 13, 2010 at 1:22 PM, Greg Mirsky
<[email-masked]> wrote:

		Hi Shahram,
		I'm not sure that "mapping" will address my concern
about this scenario. What is invariant in this scenario - MEP ID and
Your Discriminator. As noted in BFD Base, BFD session remains in tact
even if "the interface over which the packets are received can change,
but the packets will still be associated with the proper session". Thus
the MPLS Label, note that for LSP and Section the BoS will be GAL which
has no connection context, may change but the BFD session must be seen
as valid (no mis-connection to report).
		My conclusion on this scenario - MPLS Label does not
provide demultiplexing for OAM. 

	Regards,
	 Greg

		On Thu, May 13, 2010 at 12:24 PM, Shahram Davari
<[email-masked]> wrote:

			Hi Greg,

			I actually had thought of the scenario that you
describe and it could easily be accommodated by mapping both the working
and protection (detour) labels to the same BFD session.

			Regards,

			Shahram

			Sent: Wednesday, May 12, 2010 8:08 PM
			To: Shahram Davari
			Cc: David Allan I; [email-masked] 

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

			Hi Shahram,
			I agree with Dave's point but would try to
present a case where MPLS Label is not sufficient to establish context
of BFD session. Noted, that scenario is based on my assumption that FRR
one-to-one are not excluded from MPLS-TP and are applicable to
associated bidirectional LSP as local protection. If assumptions
correct, than in case when tail-end is MP, the LSP and detour is OAM'd
by their respective own BFD sessions. How the tail-end treat BFD session
of protected LSP when local protection is in use? Would it see it as
mis-connectivity? Or the scenario is artificial because mixing local and
end-to-end protection is, lightly speaking, not a good practice (another
rope for an operator to hang on)?
			
			Regards,
			Greg

			On Wed, May 12, 2010 at 1:05 PM, Shahram Davari
<[email-masked]> wrote:

			Hi Greg,

			Dave is correct.

			Since MPLS-TP does no support MP2P tunnels, this
means that there is a 1-to-1 relationship between the  Tunnel label and
the BFD session for that  tunnel. This means that Tunnel label may be
used for demultiplexing. Alternatively, one could use "Your Discr" for
demultiplexing too. 

			Both the above-mentioned methods of
demultiplexing works fine and should not cause any interoperability
issue, since both are directly or indirectly advertised by the Sink MEP
and both are local to the sink MEP.

			Thanks,

			Shahram  

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Allan I
			Sent: Wednesday, May 12, 2010 12:41 PM

			To: Greg Mirsky
			Cc: [email-masked]
			Subject: Re: [mpls-tp]
Draft-asm-mpls-tp-bfd-cc-cv-04

			cheers

			D

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Allan I
			Sent: Wednesday, May 12, 2010 3:26 PM
			To: Greg Mirsky
			Cc: [email-masked]
			Subject: Re: [mpls-tp]
Draft-asm-mpls-tp-bfd-cc-cv-04

			Hi greg:

			An unexpected and non-zero "your discriminator"
SHOULD be a mis-connectivity fault.  This would only be detected if the
particular discriminator value was not in use at all by  BFD at the node
hosting the  sink MEP  hence the recevied BFD packet could not be mapped
to a sink MEP . If it was in use, further testing would be required to
determine if the discriminator was aliasing another session (e.g. CV
processing of a Source MEP TLV).

			The comment on section 3.5.6 highlights an issue
where draft-asm-02 deviated from the base  BFD  spec. That being said,
IMO the label of arrival should be somthing that is checked to ensure it
matches the label of arrival associated with the discriminator value
else we could have an undetected misconnectivy fault occuring in the
last hop, which does sort of suggest the  discriminator and the label of
arrival  can stunt double for each other...although interoperability
does demand that use of "your discriminator" follows the rules of the
BFD base spec....

			my 2 cents

			cheers

			D

			Sent: Wednesday, May 12, 2010 3:16 PM
			To: David Allan I
			Cc: Shahram Davari; [email-masked]
			Subject: Re: [mpls-tp]
Draft-asm-mpls-tp-bfd-cc-cv-04

			Dear David,
			after reading discussion between Shahram and you
I've got a question whether receiving unexpected Your Discriminator
constitutes mis-connectivity fault. 
			Another question is with demultiplexing BFD
sessions (CC/CV sessions) between pair of end-points. The BFD Base is,
in my view, pretty strict on what provides context and must be used to
demultiplex BFD sessions between two end-points:
			"Once the remote end echoes back the local
discriminator, all further received packets are demultiplexed based on
the Your Discriminator field only (which means that, among other things,
the source address field can change or the interface over which the
packets are received can change, but the packets will still be
associated with the proper session)."
			I read that as tunnel can change (i.e. FRR in
use) but the session (based on Your Discriminator) is properly
identified. I think that wording in Section 3.5.6 "MPLS labels at peer
MEPs are used to provide context for the received BFD packets." is not
in sync with the BFD Base.
			
			Regards,
			Greg

			Hi Shahram:
			
			Other than the fact that the wording can be
improved, I do not see anything in conflict with the usage of the
discriminator in the BFD base draft.
			
			If it appears so, that is a matter of
interpretation and draft-asm requires improvement. Frankly we were more
focused on getting the state transitions correct in this version.

			Does that work for you?

			Cheers
			D
			
			-----Original Message-----
			From: Shahram Davari
[mailto:[email-masked]]

			Sent: Tuesday, May 11, 2010 8:40 PM
			To: David Allan I
			Cc: [email-masked]'
			Subject: Re: [mpls-tp]
Draft-asm-mpls-tp-bfd-cc-cv-04
			
			Hi Dave
			
			I am talking about the asm draft. This draft
explicitly says your discriminator is not used for mplstp.

			THX
			SD
			
			----- Original Message -----
			From: David Allan I <[email-masked]>
			To: Shahram Davari
			Cc: [email-masked]' <[email-masked]>
			Sent: Tue May 11 17:23:55 2010
			Subject: RE: [mpls-tp]
Draft-asm-mpls-tp-bfd-cc-cv-04
			
			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
			
			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.

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

			" 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

---

From: "ietfc" <[email-masked]>
Date: Fri, 14 May 2010 14:10:45 +0200

---- Original Message -----
From: "Greg Mirsky" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 13, 2010 10:34 PM

<tp>
Greg (and Neil:-)

This indeed was 40kb of e-mail, but if you could find a way to send it as plain
text, dropping the html alternative, then it would be only 18kb, so you could go
on including previous posts for twice as long.

(Of course, it might have been in pdf, as some on this list have been, and then
it would be more like 100kb, which, for me, is a good case for a 40kb limit:-)

Tom Petch

</tp>

 Greg