Hi Shahram,
if BFD session uses IP/UDP encapsulation then LSP Ping bootstrap should be
used. Thus the first BFD control packet would not have Your Discriminator == 0.
On the other hand ACH encapsulation unlikely to be used in p2mp as this is not
MPLS-TP construct.
Regards,
Greg
From: Rtg-bfd [mailto:[email protected]] On Behalf Of S. Davari
Sent: Friday, July 17, 2015 6:21 AM
To: Santosh P K
Cc: [email protected]; [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]<mailto:[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]<mailto:[email protected]>
Sent: Thursday, July 16, 2015 1:00 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: [email protected]<mailto:[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]<mailto:[email protected]>>
2015-07-16 下午 02:16
收件人
"S. Davari" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
抄送
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[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]<mailto:[email protected]>>
Date: Wednesday, 15 July 2015 20:12
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[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]<mailto:[email protected]>"
<[email protected]<mailto:[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.
