Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

From: Mahesh Akula <[email-masked]>
Date: Tue, 6 Jul 2010 22:38:50 -0700

Hi Apratim,

Based on my understanding, please see the response inline [MA]:

On Fri, Jun 25, 2010 at 6:10 AM, Apratim Mukherjee
<[email-masked]>wrote:

>  [Corrected subject]
>
>
>
> *From:* Apratim Mukherjee
> *Sent:* Friday, June 25, 2010 6:39 PM
> *To:* [email-masked]; [email-masked]'; [email-masked]';
> [email-masked]
> *Subject:* RE: [mpls-tp] comments on draft-asm-mpls-tp-bfd-cc-cv
>
>
>
> Hi
>
>
>
> “3.5.6. Discriminator values
>
>       My Discriminator field MUST be set to a nonzero value (it can be a
> fixed value), the transmitted your discriminator value MUST reflect  back
> the received value of My discriminator field  or be set to 0 if   that value
> is not known. “
>
>
>
> My concern is with the 'or be set to 0' when operating in ‘independent
> mode’
>
>
>
> Situation : BFD is providing independent service over the Tx and Rx links
> of an active bidirectional MPLS-TP LSP  (say because this lsp is part of a
> 1+1 protection group supporting uni-directional protection switching ; looks
> like the real world use-case  from other mails and also mentioned fleetingly
> in current draft version). You can replace Node with MEP if that makes
> understanding easier.
>
>                 Node A                                                 Node
> B
>
>                 OutLabel = L11                                  InLabel =
> L11
>
>                 InLabel  = L12                                    OutLabel
> = L12
>
>
>
> This bidirectional LSP is configured to run two independent BFD sessions ,
> one BFD session helping Node B to detect that its Rx connection via InLabel
> L11 is good , and the other helping Node A to detect that its Rx connection
> via InLabel L12 is good.
>
>
>
> If I understand correctly , for this to work , Node A and Node B MUST give
> different My Discriminators for each of the two BFD sessions on this LSP .
>  (i.e. each Node sends out two different sets of BFD packets , where the My
> and Your Discriminator values are different , one for the ‘fast’ session and
> one for the ‘quiet’ session , for which it sends BFD messages only during
> state changes )
>
>
>
> The BFD packets Node A receives for the session in which it is 'active' (
> during state changes only),i.e. these packets have MinRxInterval set to 0
> and the BFD packets Node A receives for the session in which it is
> 'passive', every 3.33/10ms will be identical if BFD packet for both sessions
> contain 0 in 'Your Discriminator' field .
>
MA:- In your example, BFD packets Node A receives for the session for which
it is 'active' can contain the "Your discriminator" value set to the
discriminator assigned by the Node A for that session, as Node B will be
aware of that. I guess this should be enough to distinguish the packets
received for the active session and the passive session at Node A, right?

Also, once any Node receives the BFD packet from the passive node (due to
state change at the peer node), it can start setting the correct "Your
discriminator" for the subsequent packets sent to the peer.

>
>
> To me , for this to work , right from first packet for each BFD session ,
> it appears that the Your Discriminator field MUST be set and can't be 0 .
> Can an implementation assume this when attempting to interop in
> ‘independent’ mode ?
>
>
>
> Please correct me if this logic has gone all wrong somewhere.
>
>
>
> Also , if we were to assume that Your Discriminator Field is always set in
> incoming BFD packets , we dont appear to need the Label Stack any more for
> demultiplexing , only to direct  the packets to the correct end-point. This
> would make it very similar to normal MPLS BFD.
>
> If we are concerned about misconfiguration  and BFD packets coming in from
> wrong source , the CV function would/should anyway take care of that in a
> proper manner.
>
>
>
> Thanks,
>
> Apratim
>
>
>
Regards,
Mahesh

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

---

From: Apratim Mukherjee <[email-masked]>
Date: Wed, 7 Jul 2010 00:56:04 -0700

Hi Mahesh

Thanks for the reply.

"MA:- In your example, BFD packets Node A receives for the session for which it is 'active' can contain the "Your discriminator" value set to the discriminator assigned by the Node A for that session, as Node B will be aware of that. I guess this should be enough to distinguish the packets received for the active session and the passive session at Node A, right?
 Also, once any Node receives the BFD packet from the passive node (due to state change at the peer node), it can start setting the correct "Your discriminator" for the subsequent packets sent to the peer."

If I understand your reply correctly ,I believe you agree that the label stack is not enough to distinguish the BFD session since it will be same for both independent BFD sessions.
In which case there are two ways ,

a)      If we use CV mode and the two uni-directional LSPs are treated as separated MEGs , de-multiplexing issue can be solved with different MEP IDs for tx and rx lsp components ... it  is another discussion whether the mpls-identifiers draft allows for this separate MEGs for each direction of a bi-directional lsp.

b)      Rely on different Your Discriminator + Label Stack to distinguish the BFD packets ( definitely not only on Label , maybe not completely in sync with 3.5.6 of the draft) .

For b)  one method appears to ensure NOT be any BFD packets ever transmitted with Your Discriminator = 0 . ( true if discriminators are configured beforehand or exchanged before-hand using LSP Ping extensions)

For b) , if we want to avoid configuration overhead or lsp ping overhead above another method could be to require that packets for the 'passive' session will NOT be transmitted till it receives a packet from the peer node ( draft and your reply appears to hint at this ) . In which case , receiving a BFD packet with Your Discriminator = 0 would imply it is for the 'active' session on peer sender node and hence 'passive' session on receiver port.
i.e. in independent mode for receiver port.
      Label X + Your Disc = Disc1 -->  Active session
      Label X + Your Disc = Disc2 --> Passive session
      Label X + Your Disc  = 0        --> Passive session always (e.g. DOWN -> INIT) i.e. assumption is for Active session no  BFD "Your Discriminator = 0" packets will ever be received.

Note that the entire doubt is only related to initial startup. When in steady state, it is true that BFD packets for the two different session will have unique Your Discriminator values from which the BFD session can be located ( assuming Label Stack + Discriminator is the key ) .

Is this in sync with your understanding ?

Regards,
Apratim
From: Mahesh Akula [mailto:[email-masked]]
Sent: Wednesday, July 07, 2010 11:09 AM
To: Apratim Mukherjee
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

Hi Apratim,

Based on my understanding, please see the response inline [MA]:
On Fri, Jun 25, 2010 at 6:10 AM, Apratim Mukherjee <[email-masked]<mailto:[email-masked]>> wrote:
[Corrected subject]

From: Apratim Mukherjee
Sent: Friday, June 25, 2010 6:39 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls-tp] comments on draft-asm-mpls-tp-bfd-cc-cv

Hi

"3.5.6. Discriminator values
      My Discriminator field MUST be set to a nonzero value (it can be a   fixed value), the transmitted your discriminator value MUST reflect  back the received value of My discriminator field  or be set to 0 if   that value is not known. "

My concern is with the 'or be set to 0' when operating in 'independent mode'

Situation : BFD is providing independent service over the Tx and Rx links of an active bidirectional MPLS-TP LSP  (say because this lsp is part of a 1+1 protection group supporting uni-directional protection switching ; looks like the real world use-case  from other mails and also mentioned fleetingly in current draft version). You can replace Node with MEP if that makes understanding easier.
                Node A                                                 Node B
                OutLabel = L11                                  InLabel = L11
                InLabel  = L12                                    OutLabel = L12

This bidirectional LSP is configured to run two independent BFD sessions , one BFD session helping Node B to detect that its Rx connection via InLabel L11 is good , and the other helping Node A to detect that its Rx connection via InLabel L12 is good.

If I understand correctly , for this to work , Node A and Node B MUST give different My Discriminators for each of the two BFD sessions on this LSP .  (i.e. each Node sends out two different sets of BFD packets , where the My and Your Discriminator values are different , one for the 'fast' session and one for the 'quiet' session , for which it sends BFD messages only during state changes )

The BFD packets Node A receives for the session in which it is 'active' ( during state changes only),i.e. these packets have MinRxInterval set to 0 and the BFD packets Node A receives for the session in which it is 'passive', every 3.33/10ms will be identical if BFD packet for both sessions contain 0 in 'Your Discriminator' field .
MA:- In your example, BFD packets Node A receives for the session for which it is 'active' can contain the "Your discriminator" value set to the discriminator assigned by the Node A for that session, as Node B will be aware of that. I guess this should be enough to distinguish the packets received for the active session and the passive session at Node A, right?

Also, once any Node receives the BFD packet from the passive node (due to state change at the peer node), it can start setting the correct "Your discriminator" for the subsequent packets sent to the peer.

To me , for this to work , right from first packet for each BFD session , it appears that the Your Discriminator field MUST be set and can't be 0 . Can an implementation assume this when attempting to interop in 'independent' mode ?

Also , if we were to assume that Your Discriminator Field is always set in incoming BFD packets , we dont appear to need the Label Stack any more for demultiplexing , only to direct  the packets to the correct end-point. This would make it very similar to normal MPLS BFD.
If we are concerned about misconfiguration  and BFD packets coming in from wrong source , the CV function would/should anyway take care of that in a proper manner.

Thanks,
Apratim

Regards,
Mahesh

---

From: Mahesh Akula <[email-masked]>
Date: Wed, 7 Jul 2010 01:14:08 -0700

Hi Apratim,

Pls see inline [MA2]:-

On Wed, Jul 7, 2010 at 12:56 AM, Apratim Mukherjee
<[email-masked]>wrote:

>  Hi Mahesh
>
>
>
> Thanks for the reply.
>
>
>
> “MA:- In your example, BFD packets Node A receives for the session for
> which it is 'active' can contain the "Your discriminator" value set to the
> discriminator" for the subsequent packets sent to the peer.”
>
>
>
> If I understand your reply correctly ,I believe you agree that the label
> stack is not enough to distinguish the BFD session since it will be same for
> both independent BFD sessions.
>
> a)      If we use CV mode and the two uni-directional LSPs are treated as
> separated MEGs , de-multiplexing issue can be solved with different MEP IDs
> for tx and rx lsp components … it  is another discussion whether the
> mpls-identifiers draft allows for this separate MEGs for each direction of a
> bi-directional lsp.
>
> b)      Rely on different Your Discriminator + Label Stack to distinguish
> the BFD packets ( definitely not only on Label , maybe not completely in
> sync with 3.5.6 of the draft) .
>
MA2:- I would rather go with option b, it seems simple to implement
and should work in all scenarios. Basically if the received BFD control
packet has "Your descriminator" set to 0, then de-mulitplex based on Label,
else de-mulitplex based on "Your discriminator". At any point there is no
need to look at both the values.

>
>
> For b)  one method appears to ensure NOT be any BFD packets ever
> transmitted with Your Discriminator = 0 . ( true if discriminators are
> configured beforehand or exchanged before-hand using LSP Ping extensions)
>
>
>
MA2:- I'm not sure if i understood your point correctly, but always the
initial packets sent from the Active Node to the Passive Node will contain
the "Your discriminator" set to 0. (Since there is no boot-strapping
mechanism), iIn which case passive node need to de-multiplex the control
packet based on Label value.

>  For b) , if we want to avoid configuration overhead or lsp ping overhead
> above another method could be to require that packets for the ‘passive’
> session will NOT be transmitted till it receives a packet from the peer node
> ( draft and your reply appears to hint at this ) . In which case , receiving
> a BFD packet with Your Discriminator = 0 would imply it is for the ‘active’
> session on peer sender node and hence ‘passive’ session on receiver port.
>

MA2:- As such I can't think of scenario where passive node has to send the
BFD control packet to the Active Node without ever receiving one from the
Active node. If Passive node has to send the control packets only on state
change, then BFD session state at the passive node will be "Down" until
unless it receives atleast one packet from the active node, right? correct
me if i'm missing out something here.

>       Label X + Your Disc = Disc1 à  Active session
>
>       Label X + Your Disc = Disc2 à Passive session
>
>       *Label X + Your Disc  = 0*        à Passive session always (e.g.
> DOWN -> INIT) i.e. assumption is for Active session no  BFD “Your
> Discriminator = 0” packets will ever be received.
>
>
>
> Note that the entire doubt is only related to initial startup. When in
> steady state, it is true that BFD packets for the two different session will
> have unique Your Discriminator values from which the BFD session can be
> located ( assuming Label Stack + Discriminator is the key ) .
>
>
>

Regards,
Mahesh

>   *From:* Mahesh Akula [mailto:[email-masked]]
> *Sent:* Wednesday, July 07, 2010 11:09 AM
> *To:* Apratim Mukherjee
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 :
> 'independent' mode BFD related.
>
>
>
> Hi Apratim,
>
>
>
> On Fri, Jun 25, 2010 at 6:10 AM, Apratim Mukherjee <[email-masked]>
> wrote:
>
> [Corrected subject]
>
>
>

---

From: Apratim Mukherjee <[email-masked]>
Date: Wed, 7 Jul 2010 03:23:41 -0700

Hi Mahesh

Comment inline [Apratim]

Regards,
Apratim
From: Mahesh Akula [mailto:[email-masked]]
Sent: Wednesday, July 07, 2010 1:44 PM
To: Apratim Mukherjee
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

Hi Apratim,

Pls see inline [MA2]:-
On Wed, Jul 7, 2010 at 12:56 AM, Apratim Mukherjee <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mahesh

Thanks for the reply.

b)      Rely on different Your Discriminator + Label Stack to distinguish the BFD packets ( definitely not only on Label , maybe not completely in sync with 3.5.6 of the draft) .
MA2:- I would rather go with option b, it seems simple to implement and should work in all scenarios. Basically if the received BFD control packet has "Your descriminator" set to 0, then de-mulitplex based on Label, else de-mulitplex based on "Your discriminator". At any point there is no need to look at both the values.
[Apratim Mukherjee]  I think we possibly have a disconnect here. The whole query regarding independent sessions arose with the understanding that any one node can receive two sets of BFD packets with same label stack , one set at a frequent interval ( it is passive side for this ) and one more rarely ( it is active side for this ).  Hence de-multiplex based only on Label can never be complete. Rest of the arguments / concerns are on top of this premise only.

MA2:- I'm not sure if i understood your point correctly, but always the initial packets sent from the Active Node to the Passive Node will contain the "Your discriminator" set to 0. (Since there is no boot-strapping mechanism), iIn which case passive node need to de-multiplex the control packet based on Label value.
[Apratim Mukherjee] I am trying to convey that in exactly this case , we cannot directly de-multiplex based on Label Value since the 'reply' packets for the other 'active' BFD session originating from this Node will also contain exactly same Label value. Which is where my doubts lie.
For b) , if we want to avoid configuration overhead or lsp ping overhead above another method could be to require that packets for the 'passive' session will NOT be transmitted till it receives a packet from the peer node ( draft and your reply appears to hint at this ) . In which case , receiving a BFD packet with Your Discriminator = 0 would imply it is for the 'active' session on peer sender node and hence 'passive' session on receiver port.

MA2:- As such I can't think of scenario where passive node has to send the BFD control packet to the Active Node without ever receiving one from the Active node. If Passive node has to send the control packets only on state change, then BFD session state at the passive node will be "Down" until unless it receives atleast one packet from the active node, right? correct me if i'm missing out something here.
[Apratim Mukherjee] Not for the passive session till state change where passive session does not send any packets unless active side sends at least one packet. But on same lsp , with same label , it needs to send BFD packets for the independent BFD session of which it is the originator .That is why the three options below. Where "Disc1 = Discriminator assigned to say active session" and "Disc2 = Discriminator assigned to passive session" by receiving node.
i.e. in independent mode for receiver port.
      Label X + Your Disc = Disc1 -->  Active session
      Label X + Your Disc = Disc2 --> Passive session
      Label X + Your Disc  = 0        --> Passive session always i.e. assumption is for Active session no  BFD "Your Discriminator = 0" packets will ever be received.
where Label X de-multiplexes to two separate BFD sessions , one 'active' and other 'passive'.

Regards,
Apratim

Regards,
Mahesh
From: Mahesh Akula [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 07, 2010 11:09 AM
To: Apratim Mukherjee
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

Hi Apratim,

From: Apratim Mukherjee

Hi

Thanks,
Apratim

Regards,
Mahesh

---

From: Mahesh Akula <[email-masked]>
Date: Thu, 8 Jul 2010 23:43:20 -0700

Hi Apratim,

Pls see inline [MA3]:

On Wed, Jul 7, 2010 at 3:23 AM, Apratim Mukherjee <[email-masked]>wrote:

> *Sent:* Wednesday, July 07, 2010 1:44 PM
>
> *To:* Apratim Mukherjee
> On Wed, Jul 7, 2010 at 12:56 AM, Apratim Mukherjee <[email-masked]>
> wrote:
>
> Hi Mahesh
>
>
>
> Thanks for the reply.
>
>
>
> [Apratim Mukherjee]  I think we possibly have a disconnect here. The whole
> query regarding independent sessions arose with the understanding that any
> one node can receive two sets of BFD packets with *same *label stack , one
> set at a frequent interval ( it is passive side for this ) and one more
> rarely ( it is active side for this ).  Hence de-multiplex based only on
> Label can never be complete. Rest of the arguments / concerns are on top of
> this premise only.
>
MA3:-  I guess we are in sync. Let me put my point this way,
   When control packet is received at Node X:-
   -> If "Your discriminator" is not zero, then de-multiplex the control
packet using the discrimintor value. This packet can belong either of the
Active or Passive BFD sessions at Node X.
      else de-multiplex the packet based on Label. As this can never happen
with Active BFD session at Node X, this can only belong to Passive BFD
session at this node.

This is exactly what you are trying to convey below right?

> [Apratim Mukherjee] I am trying to convey that in exactly this case , we
> cannot directly de-multiplex based on Label Value since the ‘reply’ packets
> for the other ‘active’ BFD session originating from this Node will also
> contain exactly same Label value. Which is where my doubts lie.
>
> [Apratim Mukherjee] Not for the passive session till state change where
> passive session does not send any packets unless active side sends at least
> one packet. But on same lsp , with same label , it needs to send BFD packets
> for the independent BFD session of which it is the originator .That is why
> the three options below. Where “Disc1 = Discriminator assigned to say active
> session” and “Disc2 = Discriminator assigned to passive session” by
> receiving node.
>
>       *Label X + Your Disc  = 0*        à Passive session always i.e.
> assumption is for Active session no  BFD “Your Discriminator = 0” packets
> will ever be received.
>
> where Label X de-multiplexes to two separate BFD sessions , one ‘active’
> and other ‘passive’.
>
>
>
Regards,
Mahesh

---

From: Apratim Mukherjee <[email-masked]>
Date: Fri, 9 Jul 2010 06:26:38 -0700

Hi Mahesh 

Thanks for your inputs. 
Yes,  we are in sync.
Just hope that this understanding is indeed the correct understanding !!

Regards,
Apratim

===================================================================================================================
From: Mahesh Akula [mailto:[email-masked]] 
Sent: Friday, July 09, 2010 12:13 PM
To: Apratim Mukherjee
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

Hi Apratim,
 
Pls see inline [MA3]:
On Wed, Jul 7, 2010 at 3:23 AM, Apratim Mukherjee <[email-masked]> wrote:
Hi Mahesh 
 
Comment inline [Apratim]
 
Regards,
Apratim

To: Apratim Mukherjee
 
Hi Apratim,
 
Pls see inline [MA2]:-
On Wed, Jul 7, 2010 at 12:56 AM, Apratim Mukherjee <[email-masked]> wrote:
Hi Mahesh
 
Thanks for the reply. 
 
“MA:- In your example, BFD packets Node A receives for the session for which it is 'active' can contain the "Your discriminator" value set to the discriminator assigned by the Node A for that session, as Node B will be aware of that. I guess this should be enough to distinguish the packets received for the active session and the passive session at Node A, right? 
 Also, once any Node receives the BFD packet from the passive node (due to state change at the peer node), it can start setting the correct "Your discriminator" for the subsequent packets sent to the peer.”
 
If I understand your reply correctly ,I believe you agree that the label stack is not enough to distinguish the BFD session since it will be same for both independent BFD sessions.
In which case there are two ways , 
a)      If we use CV mode and the two uni-directional LSPs are treated as separated MEGs , de-multiplexing issue can be solved with different MEP IDs for tx and rx lsp components … it  is another discussion whether the mpls-identifiers draft allows for this separate MEGs for each direction of a bi-directional lsp. 
b)      Rely on different Your Discriminator + Label Stack to distinguish the BFD packets ( definitely not only on Label , maybe not completely in sync with 3.5.6 of the draft) .
MA2:- I would rather go with option b, it seems simple to implement and should work in all scenarios. Basically if the received BFD control packet has "Your descriminator" set to 0, then de-mulitplex based on Label, else de-mulitplex based on "Your discriminator". At any point there is no need to look at both the values.
[Apratim Mukherjee]  I think we possibly have a disconnect here. The whole query regarding independent sessions arose with the understanding that any one node can receive two sets of BFD packets with same label stack , one set at a frequent interval ( it is passive side for this ) and one more rarely ( it is active side for this ).  Hence de-multiplex based only on Label can never be complete. Rest of the arguments / concerns are on top of this premise only.
MA3:-  I guess we are in sync. Let me put my point this way,
   When control packet is received at Node X:-
   -> If "Your discriminator" is not zero, then de-multiplex the control packet using the discrimintor value. This packet can belong either of the Active or Passive BFD sessions at Node X. 
      else de-multiplex the packet based on Label. As this can never happen with Active BFD session at Node X, this can only belong to Passive BFD session at this node. 

 
MA2:- I'm not sure if i understood your point correctly, but always the initial packets sent from the Active Node to the Passive Node will contain the "Your discriminator" set to 0. (Since there is no boot-strapping mechanism), iIn which case passive node need to de-multiplex the control packet based on Label value.
[Apratim Mukherjee] I am trying to convey that in exactly this case , we cannot directly de-multiplex based on Label Value since the ‘reply’ packets for the other ‘active’ BFD session originating from this Node will also contain exactly same Label value. Which is where my doubts lie.
For b) , if we want to avoid configuration overhead or lsp ping overhead above another method could be to require that packets for the ‘passive’ session will NOT be transmitted till it receives a packet from the peer node ( draft and your reply appears to hint at this ) . In which case , receiving a BFD packet with Your Discriminator = 0 would imply it is for the ‘active’ session on peer sender node and hence ‘passive’ session on receiver port.
 
MA2:- As such I can't think of scenario where passive node has to send the BFD control packet to the Active Node without ever receiving one from the Active node. If Passive node has to send the control packets only on state change, then BFD session state at the passive node will be "Down" until unless it receives atleast one packet from the active node, right? correct me if i'm missing out something here.
[Apratim Mukherjee] Not for the passive session till state change where passive session does not send any packets unless active side sends at least one packet. But on same lsp , with same label , it needs to send BFD packets for the independent BFD session of which it is the originator .That is why the three options below. Where “Disc1 = Discriminator assigned to say active session” and “Disc2 = Discriminator assigned to passive session” by receiving node. 
i.e. in independent mode for receiver port.
      Label X + Your Disc = Disc1 →  Active session
      Label X + Your Disc = Disc2 → Passive session
      Label X + Your Disc  = 0        → Passive session always i.e. assumption is for Active session no  BFD “Your Discriminator = 0” packets will ever be received.
where Label X de-multiplexes to two separate BFD sessions , one ‘active’ and other ‘passive’.

 
Regards,
Apratim
 
Regards,
Mahesh
 
Hi Apratim,
 
Based on my understanding, please see the response inline [MA]:
On Fri, Jun 25, 2010 at 6:10 AM, Apratim Mukherjee <[email-masked]> wrote:
[Corrected subject] 
 
From: Apratim Mukherjee 
Sent: Friday, June 25, 2010 6:39 PM
To: [email-masked]; [email-masked]'; [email-masked]'; [email-masked]
Subject: RE: [mpls-tp] comments on draft-asm-mpls-tp-bfd-cc-cv
 
Hi
 
“3.5.6. Discriminator values
      My Discriminator field MUST be set to a nonzero value (it can be a   fixed value), the transmitted your discriminator value MUST reflect  back the received value of My discriminator field  or be set to 0 if   that value is not known. “
 
My concern is with the 'or be set to 0' when operating in ‘independent mode’

   
If I understand correctly , for this to work , Node A and Node B MUST give different My Discriminators for each of the two BFD sessions on this LSP .  (i.e. each Node sends out two different sets of BFD packets , where the My and Your Discriminator values are different , one for the ‘fast’ session and one for the ‘quiet’ session , for which it sends BFD messages only during state changes ) 

   
To me , for this to work , right from first packet for each BFD session , it appears that the Your Discriminator field MUST be set and can't be 0 . Can an implementation assume this when attempting to interop in ‘independent’ mode ? 

 
Thanks,
Apratim
 
Regards,
Mahesh
 
Regards,
Mahesh

---

From: David Allan I <[email-masked]>
Date: Fri, 9 Jul 2010 16:00:38 -0400

HI

Apologies for not chiming in sooner. Fist, when operating independently yes you are correct there will be two sets of discriminator pairs (my/your when viewed from one end)...

Second w.r.t. zero discriminator...

Game plan is never to leave a "your discriminator" as unknown. That can only realy happen in a true unidirectional session as an implementation would never send my-discriminator=0 and the receiving implementation is required to use the offered discriminator value.

Only practical example of where a discriminator would be unknown at some point at the start of  the dialog is MPLS section OAM as there can be direct correlation and trust relationship with an immediate peer. For LSPs it is more complex as MEPs are not hosted on immediate peers, hence additional configuration is required either via LSP-PING initiation or the proposed extensions to RSVP-TE in http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03 so all aspects of the BFD session can be coordinated between the MEPs.

I hope this helps
D

________________________________
From: Apratim Mukherjee [mailto:[email-masked]]
Sent: Friday, June 25, 2010 9:11 AM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Subject: Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

[Corrected subject]

From: Apratim Mukherjee

Hi

Thanks,
Apratim

---

From: Mahesh Akula <[email-masked]>
Date: Fri, 9 Jul 2010 14:35:52 -0700

Hello David,

Does this mean that, we need to use LSP-PING or some other method for
boot-strapping the BFD sessions in MPLS-TP, similar to what is currently
being done for MPLS BFD sessions?

Then why does the draft mentions about using Label at MEP's to provide
context for the received BFD control packets? and discriminator having local
or no significance?

Regards,
Mahesh

On Fri, Jul 9, 2010 at 1:00 PM, David Allan I <[email-masked]>wrote:

>  HI
>
> Apologies for not chiming in sooner. Fist, when operating independently yes
> you are correct there will be two sets of discriminator pairs (my/your when
> viewed from one end)...
>
> Game plan is never to leave a "your discriminator" as unknown. That can
> only realy happen in a true unidirectional session as an implementation
> would never send my-discriminator=0 and the receiving implementation is
> required to use the offered discriminator value.
>
> Only practical example of where a discriminator would be unknown at some
> point at the start of  the dialog is MPLS section OAM as there can be direct
> correlation and trust relationship with an immediate peer. For LSPs it is
> more complex as MEPs are not hosted on immediate peers, hence additional
> configuration is required either via LSP-PING initiation or the proposed
> extensions to RSVP-TE in
> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03 so
> all aspects of the BFD session can be coordinated between the MEPs.
>
> I hope this helps
> D
>
>
>
>
>
>  ------------------------------
> *From:* Apratim Mukherjee [mailto:[email-masked]]
> *Sent:* Friday, June 25, 2010 9:11 AM
> *To:* David Allan I; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode
> BFD related.
>
>  [Corrected subject]
>
>
>

---

From: David Allan I <[email-masked]>
Date: Fri, 9 Jul 2010 17:42:53 -0400

Hi Mahesh:

Next revision of the draft will correct that text (posted in the next working day...). Technically the discrimiator does have local (to the platform) or no (if zero) significance. That text has been haunting folks for a  while...

Any confusion I hope is clarified with the next version...

D

________________________________
From: Mahesh Akula [mailto:[email-masked]]
Sent: Friday, July 09, 2010 5:36 PM
To: David Allan I
Cc: Apratim Mukherjee; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

Hello David,

Does this mean that, we need to use LSP-PING or some other method for boot-strapping the BFD sessions in MPLS-TP, similar to what is currently being done for MPLS BFD sessions?

Then why does the draft mentions about using Label at MEP's to provide context for the received BFD control packets? and discriminator having local or no significance?

Regards,
Mahesh

On Fri, Jul 9, 2010 at 1:00 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
HI

I hope this helps
D

________________________________
From: Apratim Mukherjee [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 25, 2010 9:11 AM
To: David Allan I; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Query abt draft-ietf-mpls-tp-cc-cv-rdi-00 : 'independent' mode BFD related.

[Corrected subject]

From: Apratim Mukherjee

Hi

Thanks,
Apratim

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

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 13 Jul 2010 10:27:19 -0700

Hi Dave,

Now that it seems you are going to the route of using "Your Descr" for BFD de-multiplexing, I would like to propose moving the MEP ID TLV after the BFD control packet, since having any TLV before BFD PDU would make it very hard for Hardware to find the "Your Descr" field.

Thanks,
Shahram

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 13 Jul 2010 11:42:07 -0700

Dear Shahram,
I'm concerned that repositioning Unique MEP ID TLV will change context
of ACH TLV Header. If you propose to move ACH TLV Header as well, then
it, in my view, will really change RFC 5586.

Regards,
Greg

On Tue, Jul 13, 2010 at 10:27 AM, Shahram Davari <[email-masked]> wrote:
> Hi Dave,
>
>
>
> Now that it seems you are going to the route of using “Your Descr” for BFD
> de-multiplexing, I would like to propose moving the MEP ID TLV after the BFD
> control packet, since having any TLV before BFD PDU would make it very hard
> for Hardware to find the “Your Descr” field.
>
>
>
> Thanks,
> Shahram
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 13 Jul 2010 13:17:56 -0700

Hi Greg,

One way to do this without violating RFC5586 is to not using ACH TLV rather may be defining a new field for BFD CV called MEP ID. Another way is to define an offset field in the ACH TLV header (using a currently reserved field) that points to the first TLV. 

Thanks,
Shahram

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 11:42 AM
To: Shahram Davari
Cc: David Allan I; [email-masked]
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-cc-cv-rdi-00

Dear Shahram,

Regards,
Greg

On Tue, Jul 13, 2010 at 10:27 AM, Shahram Davari <[email-masked]> wrote:
> Hi Dave,
>
>
>
> Now that it seems you are going to the route of using "Your Descr" for BFD
> for Hardware to find the "Your Descr" field.
>
>
>
> Thanks,
> Shahram
>

---

From: John E Drake <[email-masked]>
Date: Tue, 13 Jul 2010 13:59:46 -0700

We can always say that CC/CV/RDI does not use any ACH TLVs, and then define CC/CV/RDI specific TLVs that happen to contain the same information and that appear at the end of the CC/CV/RDI messages.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Greg Mirsky
> Cc: [email-masked]

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 13 Jul 2010 14:09:47 -0700

Sure, that is another option.

-Shahram