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 <[email protected]>
2015-07-17 下午 01:27
收件人
"MALLIK MUDIGONDA (mmudigon)" <[email protected]>, "S. Davari"
<[email protected]>
抄送
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
主题
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:[email protected]]
Sent: Friday, July 17, 2015 10:45 AM
To: Santosh P K; S. Davari
Cc: [email protected]; [email protected]
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 <[email protected]>
Date: Friday, 17 July 2015 10:21
To: "S. Davari" <[email protected]>
Cc: "[email protected]" <[email protected]>, Mallik Mudigonda <
[email protected]>, "[email protected]" <[email protected]>
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:[email protected]]
Sent: Friday, July 17, 2015 9:51 AM
To: Santosh P K
Cc: [email protected]; MALLIK MUDIGONDA (mmudigon); [email protected]
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 <[email protected]> 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:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, July 16, 2015 1:00 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: [email protected]; 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)" <[email protected]>
2015-07-16 下午 02:16
收件人
"S. Davari" <[email protected]>, "[email protected]" <
[email protected]>
抄送
"[email protected]" <[email protected]>
主题
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" <[email protected]>
Date: Wednesday, 15 July 2015 20:12
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
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, "[email protected]" <
[email protected]> 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.
