Agree. Regards, Shahram
> On Jul 18, 2015, at 3:02 AM, Gregory Mirsky <[email protected]> > wrote: > > 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:[email protected]] On Behalf Of S. Davari > Sent: Friday, July 17, 2015 9:15 AM > To: [email protected] > Cc: [email protected] > 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, [email protected] 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 <[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. > >
