RE: 答复: RE: issues about draft-ietf-bfd-rfc5884-clarifications-02

[Gregory Mirsky]

Hi Shahram,
but mp2p with IP/UDP encapsulation of BFD session would not have the problem 
either if it will use LSP Ping bootstrap because source IP addresses, I expect, 
would be different. After bootstrap demultiplexing will be by Your 
Discriminator for each p2p BFD session of the same mp2p LSP. Would you agree?

                Regards,
                                Greg

From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of S. Davari
Sent: Friday, July 17, 2015 9:15 AM
To: peng.sha...@zte.com.cn
Cc: rtg-bfd@ietf.org
Subject: Re: 答复: RE: issues about draft-ietf-bfd-rfc5884-clarifications-02

Peng

I think you are assuming mp2p LSP. Since for P2P
LSP we won't have this problem. Right?

Regards,
Shahram


On Jul 17, 2015, at 12:03 AM, 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> wrote:

Hi Santosh

For example, there are two diferrent ingress (LSR1 & LSR2) want to establish 
BFD session with the same egress (LSR3) for same FEC (3.3.3.9/32). PLease see 
the following steps.

step1: LSR1 construct an LSP echo request message, including LSR1-LD (100) and 
FEC (3.3.3.9/32)
step2: LSR3 received the echo request message, if FEC validation check succeed, 
it will NEW a BFD entity, allocate LSR3-LD (200) based on tuple <FEC, LSR1-LD>.
       Now LSR3 can send a BFD control packet with MD=200 YD=100.
step3: LSR2 also construct an LSP echo request message, including LSR2-LD (100) 
and FEC (3.3.3.9/32)
step4: LSR3 received the echo request message, if FEC validation check succeed, 
it will match to the above already existing BFD session, because tuple <FEC, 
LSR2-LD> equal <FEC, LSR1-LD>

thanks
Deccan


Santosh P K <santos...@juniper.net<mailto:santos...@juniper.net>>

2015-07-17 下午 01:27

收件人

"MALLIK MUDIGONDA (mmudigon)" <mmudi...@cisco.com<mailto:mmudi...@cisco.com>>, 
"S. Davari" <davar...@yahoo.com<mailto:davar...@yahoo.com>>

抄送

"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
<peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

主题

RE: issues about draft-ietf-bfd-rfc5884-clarifications-02







Mallik,
   When a BFD packet is received with your_disc as non-zero then we use only 
that as demux entity. Your_discr is a value allocated by local router and 
should be unique across the system. So where is the question of having any 
other field to be used as demux? Are you talking about same discr for BFD 
session for same LSP in case of ECMP? Can you please explain more in detail 
what is the scenario? I might have missed some basic thing here.


Thanks
Santosh P K

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudi...@cisco.com]
Sent: Friday, July 17, 2015 10:45 AM
To: Santosh P K; S. Davari
Cc: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: issues about draft-ietf-bfd-rfc5884-clarifications-02

Hi,

The question is even with LSP ping, how to de-mutiplex if all the parameters 
are the same. That’s where the source address comes into picture.

Thanks

Regards
Mallik

From: Santosh P K <santos...@juniper.net<mailto:santos...@juniper.net>>
Date: Friday, 17 July 2015 10:21
To: "S. Davari" <davar...@yahoo.com<mailto:davar...@yahoo.com>>
Cc: "peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
<peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>>, Mallik Mudigonda 
<mmudi...@cisco.com<mailto:mmudi...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: issues about draft-ietf-bfd-rfc5884-clarifications-02

Sharam,
   True but here it is 5884 and for 5884 (MPLS BFD) we do bootstrapping using 
LSP ping and that exchange discr right? So you should ideally not receive any 
BFD packet with your_disc = 0.

Thanks
Santosh P K

From: S. Davari [mailto:davar...@yahoo.com]
Sent: Friday, July 17, 2015 9:51 AM
To: Santosh P K
Cc: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>; MALLIK MUDIGONDA 
(mmudigon); rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: issues about draft-ietf-bfd-rfc5884-clarifications-02

Hi Santosh

I think the issue is the first BFD packet that has your Desc =0. Question is 
how to differentiate them when they are from different ingress LSR.

Regards,
Shahram


On Jul 16, 2015, at 8:48 PM, Santosh P K 
<santos...@juniper.net<mailto:santos...@juniper.net>> wrote:
Hello Deccan, MALLIK and Shahram,
     I want to understand why do we need this? When BFD bootstrapping is 
completed then we use local discr (BFD packet your discr) as a key which will 
be unique with in the local system. Please take a look at below section of RFC 
5880.

https://tools.ietf.org/html/rfc5880#section-6.3

We don’t need to really use any other fields as we would have exchanged the 
discr using LSP ping. I might have misunderstood your question and would like 
to be corrected.


Thanks
Santosh P K

From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: Thursday, July 16, 2015 1:00 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; S. Davari
Subject: 答复: Re: issues about draft-ietf-bfd-rfc5884-clarifications-02


Hi Mallik

Source address is also a good method. But it is better to form as standard.

thanks



"MALLIK MUDIGONDA (mmudigon)" <mmudi...@cisco.com<mailto:mmudi...@cisco.com>>

2015-07-16 下午 02:16


收件人

"S. Davari" <davar...@yahoo.com<mailto:davar...@yahoo.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
<peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>>

抄送

"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

主题

Re: issues about draft-ietf-bfd-rfc5884-clarifications-02











Hi,

I think the question is 2 different ingress LSRs using the same FEC, LSP, 
Discriminator values. Discriminator values can be the same for 2 different 
ingress LSRs and if the other values are same we can always use the Source 
address to differentiate. Am I missing something?

Regards
Mallik

From: "S. Davari" <davar...@yahoo.com<mailto:davar...@yahoo.com>>
Date: Wednesday, 15 July 2015 20:12
To: "peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
<peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: issues about draft-ietf-bfd-rfc5884-clarifications-02

Hi

Why can't the ingress allocate different LD to each of those BFD sessions?

Regards,
Shahram


On Jul 15, 2015, at 7:30 AM, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
<peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>> wrote:


hi authors

It is neccessary to address the case that different ingress LSR establish BFD 
session with the same egress LSR, with same FEC, same local descriminator.
I think it is very useful to introduce a BFD Initiator TLV to LSP ping echo 
request message, to distinguish different ingress LSR. So that ingress allocate 
LD based on tuple <FEC, LSP> as defined in this draft, but egress allocate LD 
based on tuple <Initiator, FEC, RD>.

thanks
deccan


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.






--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.





--------------------------------------------------------

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.