From Adrian.Farrel@huawei.com Thu Feb 4 07:23:32 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BD93A685A for ; Thu, 4 Feb 2010 07:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRHSYWzfZ4xQ for ; Thu, 4 Feb 2010 07:23:32 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E56A23A6768 for ; Thu, 4 Feb 2010 07:23:31 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXB007MEPGIPL@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 04 Feb 2010 07:24:18 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXB00MCYPGGF6@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 04 Feb 2010 07:24:18 -0800 (PST) Date: Thu, 04 Feb 2010 15:24:12 +0000 From: Adrian Farrel Subject: Re: Progressing draft-ietf-bfd-base and IPR concerns To: rtg-bfd@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <013C868A718045AB976371E6C2A5848E@your029b8cecfe> X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:23:32 -0000 The formatting of that email was a real mess! Here it is again with some useful CRLF Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, January 30, 2010 2:28 PM Subject: Progressing draft-ietf-bfd-base and IPR concerns > Hi BFD working group, > > Ross and I have done a shuffle for AD shepherding of the base BFD draft in > order to avoid any dominance by a single vendor. > > Looking at the IPR disclosures page for this draft > (https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-bfd-base) > I see two disclosures that claim to be related to this work. I am also > aware of rumours > that there may be more IPR out there that isrelated to this work that > people might like > to disclose. > > This email is to give the BFD working group a two week period (ending > Sunday14th > February) to raise any further IPR disclosures relating to this draft. > > 1. Where possible, please file a disclosure using the tools at > http://www.ietf.org/ipr/file-disclosure > > 2. If you know of IPR held by a third party, consider notifying the IETF > through the same web pages. > > 3. If you believe that IPR exists but that you are unable to disclose or > notify by following the previous two points, please consider whether you > can send a note to the BFD mailing list to warn the working group about > potential IPR.Can I recommend that all people with concerns about IPR > look at the IETF's IPR Policy page http://www.ietf.org From Adrian.Farrel@huawei.com Fri Feb 5 07:38:14 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA7A28C101 for ; Fri, 5 Feb 2010 07:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf3Q+LM9IIXg for ; Fri, 5 Feb 2010 07:38:13 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 548763A6DCF for ; Fri, 5 Feb 2010 07:38:13 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXD00EFLKT3F0@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Fri, 05 Feb 2010 07:39:04 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXD00DPWKT0E9@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Fri, 05 Feb 2010 07:39:03 -0800 (PST) Date: Fri, 05 Feb 2010 15:37:38 +0000 From: Adrian Farrel Subject: Fw: IPR Statement RE: draft-ietf-bfd-base-11.txt To: rtg-bfd@ietf.org Message-id: <5E627FEDAECA4515B9C575383F22A21D@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 15:38:14 -0000 Hi, I suspect this will also find its way through the IETF system as well. Adrian ----- Original Message ----- From: "Rachel Albright -X (ralbrigh - Unknown at Cisco)" To: Cc: Sent: Friday, February 05, 2010 1:39 AM Subject: IPR Statement RE: draft-ietf-bfd-base-11.txt Cisco Systems, Inc. is an owner of U.S. Patent No. 7,561,527 ("the '527 patent") relating to the subject matter of "Bidirectional Forwarding Detection" . To the extent technology in this document is included in a standard adopted by the IETF, Cisco hereby grants a royalty-free, non-exclusive, perpetual, sub-licensable, worldwide license to any party to make, use, sell, offer for sale, and import a product that implements and is fully compliant with the standard under Cisco's rights to any claim of the '527 patent that is necessarily infringed by such a product. For information contact: Dan Lang Director, Intellectual Property Cisco Systems, Inc. +1 408-526-6672 standards-ipr@cisco.com From vishwas.ietf@gmail.com Tue Feb 9 05:37:05 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77463A7393 for ; Tue, 9 Feb 2010 05:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UFaXR6nI+uS for ; Tue, 9 Feb 2010 05:37:04 -0800 (PST) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id BF0843A71D6 for ; Tue, 9 Feb 2010 05:37:03 -0800 (PST) Received: by gxk5 with SMTP id 5so4122410gxk.8 for ; Tue, 09 Feb 2010 05:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l4FnmckrjeUM9zAbEJK+uXTMMpuuX8CFqR119B7Ajqs=; b=tSbCob7WqcZec5GrZNAKFDhYYAm+sgBDNPimg2JzVISENrp499AJ6apUrqXMYLs4W/ dDYlf252HyW+F3F0PwZ3OnRlIJMHd3JgljUILBF5Dj6dwsKibdayhYbkQP9DsfKhaJhw vISl4cROA8+ooO6Ik1BcfewwqK0Mswn7XHQpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vjbmI4B3RZZCNJ2D8+GtKujXv4SFWvsS2V5ge6M3wQ+4Y6NAOukiCsRPhLLAf99VN5 oFUP+empBPxGNMnjsMr1hr+Lf9gZc02Ka0fot8GgFohC+CzMmQffOT8Ix2b5Bx+m4BCV okUt+5O3qmGm3vqJVvQTLZ+eVJg6RkaWsM468= MIME-Version: 1.0 Received: by 10.150.56.31 with SMTP id e31mr2699yba.259.1265722687086; Tue, 09 Feb 2010 05:38:07 -0800 (PST) In-Reply-To: <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> Date: Tue, 9 Feb 2010 05:38:07 -0800 Message-ID: <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> Subject: Re: Questions on BFD for MPLS LSP From: Vishwas Manral To: Mach Chen Content-Type: multipart/alternative; boundary=000e0cd720e825df35047f2b0712 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 13:37:06 -0000 --000e0cd720e825df35047f2b0712 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach, I think there is value in the draft for clamping forward and backward direction of an LSP. With BFD-MPLS a BFD session down means an FEC down and not an LSP down as a different BFD session is established per FEC, do we want to change this rule instead. Your draft seems to have a BFD session per LSP and not per FEC. Further comments below: 1. BFD-MPLS assumes that detection of failure is only in the forward direction. We are making a change in the assumption, so we must specify the same in the draft. This is particularly useful for GMPLS signalled LSP's which can be bidirectional (like MPLS-TP etc). 2. One thing I think we can add is that at the ingress BFD needs to be started in the passive mode. This is because packet send starts happening if the BFD session is added but is in default (active mode even though the BFD session at the other end is not established yet) 3. It is not clear what needs to be done in case of BFD failure when unidirectional LSP's are there. Failure in one direction will lead to failure in the other which may not be the desired behavior of unidirectional LSP's. 4. You talk about Optical networks, what/ how are the FEC's in the case of Optical networks defined? 5. You mention "For each direction of a LSP, a separate BFD session is required to be established." However BFD-MPLS allows the return packet to be MPLS encapsulated. This however is a choice of the receiver and this point could be made clearer. 6. I think for bidirectional LSP there is no ingress or egress there is signalling initiator. 7. I think point 3 section 3 needs to be further clarified. When we do not want an association between forward and reverse direction LSP's we should not use these extensions. As switchover in this case will happen as a unit. 8. The FEC for the forward and backward direction of the LSP will be different. As a different BFD session is established per FEC (I would have prefered it was not) how do we map the forward and backward direction FEC's. 9. Also as the extension is for MPLs LSP encapsulated reply, we need to mention the port number used for BFD is restricted to single hop. 10. What happens when the ingress supports this extension and egress does not and vice versa. 11. Let us not use the word backward but instead use the words reverse for LSP's. 12. How do we make sure of the case of larger IP address, especially because there are multiple addresses configured on a device. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: > Hi Vishwas, > > How are you doing? > > Remember that you promised to read and comment my draft, and I'm still > looking forward to receive your comments and suggestions. > > Here are the pointers of the draft and relevant sildes: > > Slides: > http://tools.ietf.org/agenda/76/slides/mpls-2.ppt > Draft: > http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 > > > Best regards, > Mach > > -------------------------------------------------- > From: "Mach Chen" > Sent: Thursday, November 19, 2009 8:51 AM > To: "Vishwas Manral" > Cc: "Sunil C Gutlapalli" ; "So Ning" < > ning.so@verizonbusiness.com>; > > Subject: Re: Questions on BFD for MPLS LSP > > Hi Vishwas, >> >> Looking forward to receive you comments! >> >> Thanks, >> Mach >> >> -------------------------------------------------- >> From: "Vishwas Manral" >> Sent: Wednesday, November 18, 2009 1:59 AM >> To: "Mach Chen" >> Cc: "Sunil C Gutlapalli" ; ; "So >> Ning" >> Subject: Re: Questions on BFD for MPLS LSP >> >> Hi Mach, >>> >>> Though I have not yet read through the draft, it seems that the draft >>> could be of interest. LEt me read the draft and get back to you with >>> comments. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>> >>>> Hi Sunil, >>>> >>>> Regarding to your questions, especially for the question 2 and 3, we >>>> also >>>> had the same doubts couple months ago. >>>> >>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows >>>> routing and the return path is "randomly" detetermined by the egress >>>> LSR, >>>> the failures in return path may lead to false positives. >>>> >>>> In addition to that, for bidirectional LSP or a pair of unidirectional >>>> LSP, >>>> there will be two separate BFD sessions( one for each direction) >>>> established, and these two BFD sessions have no any inherent >>>> relationship, >>>> it will result in not double the BFD sessions over the LSP, but failing >>>> to >>>> perform protection and switching when the bidirectional LSP or the pair >>>> of >>>> undirectional LSPs are desired to operated as a single entity. >>>> >>>> We submitted a draft that is intended to reslove these >>>> issues/limitation. >>>> This draft was just presented at MPLS WG, Hiroshima. >>>> >>>> >>>> Any comments and sugguestions are appreciated! >>>> >>>> >>>> PS: >>>> >>>> The links: >>>> >>>> Slides: >>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>> >>>> Draft: >>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>> >>>> >>>> Best regards, >>>> Mach >>>> >>>> -------------------------------------------------- >>>> From: "Sunil C Gutlapalli" >>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>> To: >>>> Subject: Questions on BFD for MPLS LSP >>>> >>>> Hi >>>>> >>>>> >>>>> >>>>> I have some question on BFD for MPLS LSP's >>>>> >>>>> >>>>> >>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>> Bi-directional failure detection. If we have an LSP from Ingress to >>>>> Egress, >>>>> BFD control packets are sent to UDP port 3784 (BFD single hop session >>>>> port) >>>>> from ingress to egress. Control packets from Egress to ingress are sent >>>>> to >>>>> UDP port 4784 (multi hop session port). So does the session is single >>>>> hop >>>>> session or multi hop session? What is the session behavior in ingress >>>>> and >>>>> egress? >>>>> 2. If LSP takes path1 from ingress to egress and the shortest path from >>>>> egress to ingress is path2, control packets takes different paths, if >>>>> path2 >>>>> fails then BFD session goes down. But LSP path is still up. How this >>>>> case >>>>> will be handled? >>>>> 3. If we have LSP from Ingress to egress and another LSP from egress to >>>>> ingress, do we need to create two BFD sessions or one session? >>>>> >>>>> If both LSP's take same path, then link failure causes both LSP's down, >>>>> but >>>>> if they take different paths, one link failure causes both LSP's down. >>>>> >>>>> >>>>> >>>>> Sunil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> --000e0cd720e825df35047f2b0712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mach,
=A0
I think there is value in the draft for clamping forward and backward = direction of an LSP.
=A0
With BFD-MPLS a BFD session down means an FEC down and not an LSP down= as a different BFD session is established per FEC, do we want to change th= is rule instead. Your draft seems to have a BFD session per LSP and not per= FEC. Further comments below:
=A0
1. BFD-MPLS assumes that detection of failure is only in the forward d= irection. We are making a change in the assumption, so we must specify the = same in the draft. This is particularly useful for GMPLS signalled LSP'= s which can be bidirectional (like MPLS-TP etc).
=A0
2. One thing I think we can add is that at the ingress BFD needs to be= started in the passive mode. This is because packet send starts happening = if the BFD session is added but is in default (active mode even though the = BFD session at the other end is not established yet)
=A0
3. It is not clear what needs to be done in case of BFD failure when u= nidirectional LSP's are there. Failure in one direction will lead to fa= ilure in the other which may not be the desired behavior of unidirectional = LSP's.
=A0
4. You talk about Optical networks, what/ how are=A0the FEC's in t= he case of Optical networks defined?
=A0
5. You mention
"For each direction of a LSP, a separate BFD session is required<= br>=A0=A0=A0=A0=A0=A0=A0 to be established."
=A0
However BFD-MPLS allows the return packet to be MPLS encapsulated. Thi= s however is a choice of the receiver and this point could be made clearer.=
=A0
6. I think for bidirectional LSP there is no ingress or egress there i= s signalling initiator.
=A0
7. I think point 3 section 3 needs to be further clarified. When we do= not want an association between forward and reverse direction LSP's we= should not use these extensions. As switchover in this case will happen as= a unit.
=A0
8. The FEC for the forward and backward direction of the LSP will be d= ifferent.=A0As a different BFD session is established per FEC (I would have= prefered it was not) how do we map the forward and backward direction FEC&= #39;s.
=A0
9. Also as the extension is for MPLs LSP encapsulated reply, we need t= o mention the port number used for BFD is restricted to single hop.
=A0
10. What happens when the ingress supports this extension and egress d= oes not and vice versa.
=A0
11. Let us not use the word backward but instead use the words reverse= for LSP's.
=A0
12. How do we make sure of the case of larger IP address, especially b= ecause there are multiple addresses configured on a device.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen <mach@huawei.com><= /span> wrote:
Hi Vishwas,

How are you d= oing?

Remember that you promised to read and comment my draft, and I= 'm still looking forward to receive your comments and suggestions.

Here are the pointers of the draft and relevant sildes:=20

Slides:
http://tools.ietf.org/agenda/76/slide= s/mpls-2.ppt
Draft:
http://tools.ietf.= org/html?draft=3Ddraft-chen-mpls-bfd-enhancement-00


Best regards,
Mach

--------------------------------------= ------------
From: "Mach Chen" <mach@huawei.com>
Sent: Thursday, = November 19, 2009 8:51 AM
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
Cc: "Sunil C Gut= lapalli" <sunilc@ipinfusion.com>; "So Ning" <ning.so@verizonbusiness.com<= /a>>; <rtg-bfd@= ietf.org>=20

Subject: Re: Questions on BFD for MPLS LSP

Hi Vishwas,

Looking forwa= rd to receive you comments!

Thanks,
Mach

-----------------= ---------------------------------
From: "Vishwas Manral" <vishwas.ietf@gmail.com>
Sent: Wednesday, No= vember 18, 2009 1:59 AM
To: "Mach Chen" <mach@huawei.com>
Cc: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>; <rtg-bfd@ietf.org>; "So Nin= g" <ning.so@verizonbusiness.com>
Subject: Re: Questions on BFD for MPLS LSP

Hi Mach,

Though I have no= t yet read through the draft, it seems that the draft
could be of intere= st. LEt me read the draft and get back to you with
comments.

Thanks,
Vishwas

On Tue, Nov 17, 2009 at 1:06 AM,= Mach Chen <mach@hu= awei.com> wrote:
Hi Sunil,

Regarding to yo= ur questions, especially for the question 2 and 3, =A0we also
had the sa= me doubts couple months ago.

Since the reverse direction of a "BFD for MPLS LSPs" sesssion= follows
routing and the return path is "randomly" detetermine= d by the egress LSR,
the failures in return path may lead to false posit= ives.

In addition to that, for bidirectional LSP or a pair of unidirectional = LSP,
there will be two separate BFD sessions( one for each direction)established, and these two BFD sessions have no any inherent relationship,=
it will result in not double the BFD sessions over the LSP, but failing to<= br>perform protection and switching when the bidirectional LSP or the pair = of
undirectional LSPs are desired to operated as a single entity.

We submitted a draft that is intended to reslove these issues/limitatio= n.
This draft was just presented at MPLS WG, Hiroshima.


Any c= omments and sugguestions are appreciated!


PS:

The links:<= br>
Slides:
http://tools.ietf.org/agenda/76/slides/mpls-2.ppt
Draft:
http://tools.ietf.org/html?draft= =3Ddraft-chen-mpls-bfd-enhancement-00


Best regards,
Mach

--------------------------------------= ------------
From: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>
S= ent: Tuesday, November 17, 2009 6:59 AM
To: <rtg-bfd@ietf.= org>
Subject: Questions on BFD for MPLS LSP

Hi



I have some qu= estion on BFD for MPLS LSP's



1. MPLS LSP's are uni-d= irectional and BFD sessions are for
Bi-directional failure detection. If we have an LSP from Ingress to
Egre= ss,
BFD control packets are sent to UDP port 3784 (BFD single hop sessio= n
port)
from ingress to egress. Control packets from Egress to ingres= s are sent to
UDP port 4784 (multi hop session port). So does the session is single hopsession or multi hop session? What is the session behavior in ingress and=
egress?
2. If LSP takes path1 from ingress to egress and the shortes= t path from
egress to ingress is path2, control packets takes different paths, if
pa= th2
fails then BFD session goes down. But LSP path is still up. How this= case
will be handled?
3. If we have LSP from Ingress to egress and a= nother LSP from egress to
ingress, do we need to create two BFD sessions or one session?

If bo= th LSP's take same path, then link failure causes both LSP's down,<= br>but
if they take different paths, one link failure causes both LSP= 9;s down.



Sunil







=

--000e0cd720e825df35047f2b0712-- From gregimirsky@gmail.com Tue Feb 9 13:35:45 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445D728C0D6 for ; Tue, 9 Feb 2010 13:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwumzgnEWu5V for ; Tue, 9 Feb 2010 13:35:44 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 1EC1B3A75E7 for ; Tue, 9 Feb 2010 13:35:43 -0800 (PST) Received: by bwz3 with SMTP id 3so2115904bwz.13 for ; Tue, 09 Feb 2010 13:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p4hxIFDWtYxvd6RFcpdli28ZoaMGk8j6c9bNJfjvdkI=; b=Azq2kjDchB6z7vo46kJBN11u3DQA68kSjpKnsW35cRuxOljj9AOa2D8sl4gVKhe0+2 W/F4wR9IeSjCogaBPu+w59nVNgjJ3vEnJDfWYBe7x4K2Kx5jjc0aAC4/BC/XcuArrYip IupcwA/aMTvptRXLDntM0/EZsEWS5bdGCjf1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SERPyYdtrsZooH2Sb/Z4hfZU7GaGhqclJ/22nokggc6R9OVm9qtfb+30OlwdRRWRtd 40iqaHyqfbM3A8sWk/Jon749rD2ip7HLyAB9AsHNR6S4BzYBYkXKQfXIYCHYX1JzDtkQ a6vKaBihxff+SZsK9OtuaUK2P9lVf9nfO98bg= MIME-Version: 1.0 Received: by 10.204.8.154 with SMTP id h26mr957876bkh.113.1265751408664; Tue, 09 Feb 2010 13:36:48 -0800 (PST) In-Reply-To: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> Date: Tue, 9 Feb 2010 13:36:48 -0800 Message-ID: <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> Subject: Re: BFD LSP Ping From: Greg Mirsky To: Vishwas Manral Content-Type: multipart/alternative; boundary=00151758b020166208047f31b747 Cc: Kireeti Kompella , rtg-bfd@ietf.org, rahul@juniper.net X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:35:45 -0000 --00151758b020166208047f31b747 Content-Type: text/plain; charset=ISO-8859-1 Dear All, I've found this thread is the closest to a question of my own and since I couldn't find any conclusion decided to add $.02 As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But it requires set IP TTL of BFD packet to 1 while BFD single hop document in Section 5 requires TTL == 255 if Authentication not in use. BFD packet must be discarded if received TTL /= 255. If Authentication being used, still, TTL == 255 required, but "check TTL" eased to "may drop if TTL /= 255". Should BFD MPLS text be changed to sync with BFD single hop in regard to setting TTL value? Regards, Greg On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral wrote: > Hi, > > I noticed a basic issue with BFD LSP ping with a a TTL processing in a > Uniform Model LSP. > > The draft states that: > > > The BFD control packet sent by the ingress LSR MUST be a UDP packet > with a well known destination port 3784 [BFD-IP] and a source port > assigned by the sender as per the procedures in [BFD-IP]. > > A single hop session verifies the TTL is 255. However the TTL in the > IP header is changed at the Egress before the IP header handling > because we are using hte uniform model. I think the easiest and the > best way for this would be to use Multihop sessions in both > directions. > > Do let me know if I am missing something? > > Thanks, > Vishwas > --00151758b020166208047f31b747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All,
I've found this thread is the closest to a question of my = own and since I couldn't find any conclusion decided to add $.02
As = Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 wh= en BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But = it requires set IP TTL of BFD packet to 1 while BFD single hop document in = Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD packet = must be discarded if received TTL /=3D 255. If Authentication being used, s= till, TTL =3D=3D 255 required, but "check TTL" eased to "may= drop if TTL /=3D 255".

Should BFD MPLS text be changed to sync with BFD single hop in regard t= o setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral <<= a href=3D"mailto:vishwas.ietf@gmail.com">vishwas.ietf@gmail.com> wrote:
Hi,

I noticed a basic issue with BFD LSP ping with a a TTL processing in a
Uniform Model LSP.

The draft states that:


=A0 The BFD control packet sent by the ingress LSR MUST be a UDP packet =A0 with a well known destination port 3784 [BFD-IP] and a source port
=A0 assigned by the sender as per the procedures in [BFD-IP].

A single hop session verifies the TTL is 255. However the TTL in the
IP header is changed at the Egress before the IP header handling
because we are using hte uniform model. I think the easiest and the
best way for this would be to use Multihop sessions in both
directions.

Do let me know if I am missing something?

Thanks,
Vishwas

--00151758b020166208047f31b747-- From davari@broadcom.com Tue Feb 9 14:01:24 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D394028C175 for ; Tue, 9 Feb 2010 14:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxaomBymRh6s for ; Tue, 9 Feb 2010 14:01:23 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id D8A343A72F4 for ; Tue, 9 Feb 2010 14:01:23 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 09 Feb 2010 14:02:22 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 9 Feb 2010 14:02:21 -0800 From: "Shahram Davari" To: "Greg Mirsky" , "Vishwas Manral" Date: Tue, 9 Feb 2010 14:02:21 -0800 Subject: RE: BFD LSP Ping Thread-Topic: BFD LSP Ping Thread-Index: Acqp0AU+NMBObMw0RdmTLA1je5BaiAAA3Qmw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> In-Reply-To: <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 676F04E720S21794526-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DASJEXCHCCR02co_ Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:01:24 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DASJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Greg, Do you know the reason why TTL=3D255 check is not required for BFD with Aut= hentication? Thanks, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Tuesday, February 09, 2010 1:37 PM To: Vishwas Manral Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Dear All, I've found this thread is the closest to a question of my own and since I c= ouldn't find any conclusion decided to add $.02 As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784= when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. B= ut it requires set IP TTL of BFD packet to 1 while BFD single hop document = in Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD pack= et must be discarded if received TTL /=3D 255. If Authentication being used= , still, TTL =3D=3D 255 required, but "check TTL" eased to "may drop if TTL= /=3D 255". Should BFD MPLS text be changed to sync with BFD single hop in regard to se= tting TTL value? Regards, Greg On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral > wrote: Hi, I noticed a basic issue with BFD LSP ping with a a TTL processing in a Uniform Model LSP. The draft states that: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. A single hop session verifies the TTL is 255. However the TTL in the IP header is changed at the Egress before the IP header handling because we are using hte uniform model. I think the easiest and the best way for this would be to use Multihop sessions in both directions. Do let me know if I am missing something? Thanks, Vishwas --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DASJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi=20 Greg,
 
Do you=20 know the reason why TTL=3D255 check is not required for BFD with=20 Authentication?
 
Thanks,
Shahram

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vis= hwas=20 Manral
Cc: Kireeti Kompella; rtg-bfd@ietf.org;=20 rahul@juniper.net
Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a question= of=20 my own and since I couldn't find any conclusion decided to add $.02
As=20 Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 wh= en=20 BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But it= =20 requires set IP TTL of BFD packet to 1 while BFD single hop document in Sec= tion=20 5 requires TTL =3D=3D 255 if Authentication not in use. BFD packet must be = discarded=20 if received TTL /=3D 255. If Authentication being used, still, TTL =3D=3D 2= 55=20 required, but "check TTL" eased to "may drop if TTL /=3D 255".

Shoul= d BFD=20 MPLS text be changed to sync with BFD single hop in regard to setting TTL=20 value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral <vishwas.ietf@gmail.com>=20 wrote:
Hi,

I=20 noticed a basic issue with BFD LSP ping with a a TTL processing in=20 a
Uniform Model LSP.

The draft states that:


  T= he=20 BFD control packet sent by the ingress LSR MUST be a UDP packet
 = with=20 a well known destination port 3784 [BFD-IP] and a source port
 =20 assigned by the sender as per the procedures in [BFD-IP].

A single= hop=20 session verifies the TTL is 255. However the TTL in the
IP header is=20 changed at the Egress before the IP header handling
because we are usi= ng=20 hte uniform model. I think the easiest and the
best way for this would= be=20 to use Multihop sessions in both
directions.

Do let me know if = I am=20 missing something?

Thanks,
Vishwas

--_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DASJEXCHCCR02co_-- From vishwas.ietf@gmail.com Tue Feb 9 14:03:04 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCBE28C18C for ; Tue, 9 Feb 2010 14:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV5ciQ3kMWVa for ; Tue, 9 Feb 2010 14:03:03 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 6A00528C175 for ; Tue, 9 Feb 2010 14:03:03 -0800 (PST) Received: by ywh15 with SMTP id 15so1843256ywh.5 for ; Tue, 09 Feb 2010 14:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=f9jRhcHy9THnYac2gEECw+mCDNWh3EGbV+tcTnC7Tk0=; b=S2+vtMDj9feeP8KebhrF0gGCVVCVuQhi6PZ2GK4aGwyuGYrRbtNJZ7wNbECwGGB+tl oy7cTTh04T9XrJhIQSaJ5EryFWGc6eYeOHsdW36RZOt8NXc85EDY6UJvROGGUWukDGZ9 nZxccEA2f53ZwDt5TziCDyFiGSGDFbfZYDLBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q+YhLR4h/P5JNpn0SwUyJ2nfTYcEDVpsP6MJNJYKN1OQEXqk6MtoZ52B23/GhcXDxV u5ZdvWxjWql9gtxM782t+C3wpa3+aY+Pe7ZTVZPYIAUgT05H/nqrK3dtJw5swsGL10w6 DoUxQWUP3+Tfqe1TGxGKY63/HShbOmWKLLYao= MIME-Version: 1.0 Received: by 10.150.120.8 with SMTP id s8mr1049093ybc.127.1265753048295; Tue, 09 Feb 2010 14:04:08 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 9 Feb 2010 14:04:08 -0800 Message-ID: <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=000e0cd7087cd12962047f32184e Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:03:04 -0000 --000e0cd7087cd12962047f32184e Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, The idea is the TTL check is an approximation of the sanity of the packet. When authentication is enabled this check is redundant in my view and hence the check is not required. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari wrote: > Hi Greg, > > Do you know the reason why TTL=255 check is not required for BFD with > Authentication? > > Thanks, > Shahram > > ------------------------------ > *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On > Behalf Of *Greg Mirsky > *Sent:* Tuesday, February 09, 2010 1:37 PM > *To:* Vishwas Manral > *Cc:* Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net > > *Subject:* Re: BFD LSP Ping > > Dear All, > I've found this thread is the closest to a question of my own and since I > couldn't find any conclusion decided to add $.02 > As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 > when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But > it requires set IP TTL of BFD packet to 1 while BFD single hop document in > Section 5 requires TTL == 255 if Authentication not in use. BFD packet must > be discarded if received TTL /= 255. If Authentication being used, still, > TTL == 255 required, but "check TTL" eased to "may drop if TTL /= 255". > > Should BFD MPLS text be changed to sync with BFD single hop in regard to > setting TTL value? > > Regards, > Greg > > On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral wrote: > >> Hi, >> >> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >> Uniform Model LSP. >> >> The draft states that: >> >> >> The BFD control packet sent by the ingress LSR MUST be a UDP packet >> with a well known destination port 3784 [BFD-IP] and a source port >> assigned by the sender as per the procedures in [BFD-IP]. >> >> A single hop session verifies the TTL is 255. However the TTL in the >> IP header is changed at the Egress before the IP header handling >> because we are using hte uniform model. I think the easiest and the >> best way for this would be to use Multihop sessions in both >> directions. >> >> Do let me know if I am missing something? >> >> Thanks, >> Vishwas >> > > --000e0cd7087cd12962047f32184e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
The idea is the TTL check is an approximation of the sanity of the pac= ket. When authentication is enabled this check is redundant in my view and = hence the check is not required.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom= .com> wrote:
Hi Greg,
= =A0
Do you know th= e reason why TTL=3D255 check is not required for BFD with Authentication?
= =A0
Thanks,=
Shahram=

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Greg Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vishwas Manra= l
Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

=
Dear All,
I've found this thread is the closest to a ques= tion of my own and since I couldn't find any conclusion decided to add = $.02
As Vishwas have mentioned, BFD MPLS draft requires single hop UDP p= ort 3784 when BFD control packets are sent over MPLS LSP in IP/UDP encapsul= ation. But it requires set IP TTL of BFD packet to 1 while BFD single hop d= ocument in Section 5 requires TTL =3D=3D 255 if Authentication not in use. = BFD packet must be discarded if received TTL /=3D 255. If Authentication be= ing used, still, TTL =3D=3D 255 required, but "check TTL" eased t= o "may drop if TTL /=3D 255".

Should BFD MPLS text be changed to sync with BFD single hop in regard t= o setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:
Hi,

I noticed= a basic issue with BFD LSP ping with a a TTL processing in a
Uniform Mo= del LSP.

The draft states that:


=A0 The BFD control packet sent by th= e ingress LSR MUST be a UDP packet
=A0 with a well known destination por= t 3784 [BFD-IP] and a source port
=A0 assigned by the sender as per the = procedures in [BFD-IP].

A single hop session verifies the TTL is 255. However the TTL in theIP header is changed at the Egress before the IP header handling
becaus= e we are using hte uniform model. I think the easiest and the
best way f= or this would be to use Multihop sessions in both
directions.

Do let me know if I am missing something?

Thanks,=
Vishwas

=

--000e0cd7087cd12962047f32184e-- From davari@broadcom.com Tue Feb 9 14:06:50 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069DC3A7623 for ; Tue, 9 Feb 2010 14:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqm1oTeCucsc for ; Tue, 9 Feb 2010 14:06:49 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id EBEF03A748E for ; Tue, 9 Feb 2010 14:06:48 -0800 (PST) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 09 Feb 2010 14:07:43 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 9 Feb 2010 14:07:42 -0800 From: "Shahram Davari" To: "Vishwas Manral" Date: Tue, 9 Feb 2010 14:07:41 -0800 Subject: RE: BFD LSP Ping Thread-Topic: BFD LSP Ping Thread-Index: Acqp08/k14bFqmnRSq2wEllVeI5aiQAACYQg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> In-Reply-To: <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 676F032431G23430643-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DCSJEXCHCCR02co_ Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:06:50 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DCSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Wishwas, One more questions. The BFD drafts are all very ambiguous regarding interfa= ce binding check? is there a requirement to check BFD binding to incoming i= nterface? How about binding to an incoming tunnel? Thanks, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 2:04 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, The idea is the TTL check is an approximation of the sanity of the packet. = When authentication is enabled this check is redundant in my view and hence= the check is not required. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari > wrote: Hi Greg, Do you know the reason why TTL=3D255 check is not required for BFD with Aut= hentication? Thanks, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Greg M= irsky Sent: Tuesday, February 09, 2010 1:37 PM To: Vishwas Manral Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juni= per.net Subject: Re: BFD LSP Ping Dear All, I've found this thread is the closest to a question of my own and since I c= ouldn't find any conclusion decided to add $.02 As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784= when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. B= ut it requires set IP TTL of BFD packet to 1 while BFD single hop document = in Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD pack= et must be discarded if received TTL /=3D 255. If Authentication being used= , still, TTL =3D=3D 255 required, but "check TTL" eased to "may drop if TTL= /=3D 255". Should BFD MPLS text be changed to sync with BFD single hop in regard to se= tting TTL value? Regards, Greg On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral > wrote: Hi, I noticed a basic issue with BFD LSP ping with a a TTL processing in a Uniform Model LSP. The draft states that: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. A single hop session verifies the TTL is 255. However the TTL in the IP header is changed at the Egress before the IP header handling because we are using hte uniform model. I think the easiest and the best way for this would be to use Multihop sessions in both directions. Do let me know if I am missing something? Thanks, Vishwas --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DCSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi=20 Wishwas,
 
One=20 more questions. The BFD drafts are all very ambiguous regarding interface=20 binding check? is there a requirement to check BFD binding to incoming=20 interface? How about binding to an incoming tunnel?
 
Thanks,
Shahram
 
 

From: Vishwas Manral=20 [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010= 2:04=20 PM
To: Shahram Davari
Cc: Greg Mirsky; Kireeti Kompella= ;=20 rtg-bfd@ietf.org; rahul@juniper.net
Subject: Re: BFD LSP=20 Ping

Hi Shahram,
 
The idea is the TTL check is an approximation of the sanity of the pac= ket.=20 When authentication is enabled this check is redundant in my view and hence= the=20 check is not required.
 
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <davari@broadcom.com> wrot= e:
Hi Greg,
&nbs= p;
Do you know the re= ason why=20 TTL=3D255 check is not required for BFD with Authentication?
&nbs= p;
Thanks,
Shahram

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To:=20 Vishwas Manral
Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

=
Dear All,
I've found this thread is the closest to a questi= on of=20 my own and since I couldn't find any conclusion decided to add $.02
As= =20 Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 = when=20 BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But i= t=20 requires set IP TTL of BFD packet to 1 while BFD single hop document in=20 Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD packe= t must be=20 discarded if received TTL /=3D 255. If Authentication being used, still, = TTL =3D=3D=20 255 required, but "check TTL" eased to "may drop if TTL /=3D 255".
Should=20 BFD MPLS text be changed to sync with BFD single hop in regard to setting= TTL=20 value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:
Hi,

I=20 noticed a basic issue with BFD LSP ping with a a TTL processing in=20 a
Uniform Model LSP.

The draft states that:


 = The=20 BFD control packet sent by the ingress LSR MUST be a UDP packet
&nbs= p;=20 with a well known destination port 3784 [BFD-IP] and a source port
&= nbsp;=20 assigned by the sender as per the procedures in [BFD-IP].

A sing= le=20 hop session verifies the TTL is 255. However the TTL in the
IP heade= r is=20 changed at the Egress before the IP header handling
because we are u= sing=20 hte uniform model. I think the easiest and the
best way for this wou= ld be=20 to use Multihop sessions in both
directions.

Do let me know i= f I=20 am missing something?

Thanks,
Vishwas


--_000_2C2F1EBA8050E74EA81502D5740B4BD68167E486DCSJEXCHCCR02co_-- From gregimirsky@gmail.com Tue Feb 9 14:21:03 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB2B3A6E17 for ; Tue, 9 Feb 2010 14:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIyRbusmm2+d for ; Tue, 9 Feb 2010 14:21:02 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 7C0B73A6A88 for ; Tue, 9 Feb 2010 14:21:01 -0800 (PST) Received: by bwz3 with SMTP id 3so2149673bwz.13 for ; Tue, 09 Feb 2010 14:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wi5XTpEnqktVGV+5cgv4Ek4LIt1V7w6GpGrjKorqcHM=; b=tjADDiJLiNyxc0bGtr7dhdLM1T/ed10Nij3v78bru2FAkLGDpmgXWqoxiU4HkMkha3 bKcslxA4NFutgrSDeQBMFNt/jeSkcnhWt+jxZMEEkE7LHZwzrBjV1A+6WDyoHRKUwPN0 W4L8BfJTI8lwHnPLBzUTmaBSCPSaGNUyb4wBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IzegoR82kgh8idSmeQMZ9GCAZ0+8EshvlfWdlkXBq+OKU0GzZQEUXIW+lhb+7mHxPZ TKT4DaFVXaysH2jaMLbk1K7VajcmKXUOUpQwJ2QXLY+Z8RiIrY+rn+yeGXA5njnaB8NJ QLgyZNtRf/ktnMYyEtsVRQB6fUxpIaxX38TAw= MIME-Version: 1.0 Received: by 10.204.133.27 with SMTP id d27mr3931263bkt.51.1265754125766; Tue, 09 Feb 2010 14:22:05 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 9 Feb 2010 14:22:05 -0800 Message-ID: <787be2781002091422m58633414i8eeae79521a0eddb@mail.gmail.com> Subject: Re: BFD LSP Ping From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=001517477f860a1361047f325943 Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:21:03 -0000 --001517477f860a1361047f325943 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I agree with Shahram. TTL Check is viewed as minimal, weaker than authentication, security measure to protect one from spoofing. To your second question (another mail I've noticed), I believe that Section 9. Security Considerations in BFD single hop document recommends association of a BFD session with incoming interface as method to improve infrastructure security. Regards, Greg On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari wrote: > Hi Greg, > > Do you know the reason why TTL=255 check is not required for BFD with > Authentication? > > Thanks, > Shahram > > ------------------------------ > *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On > Behalf Of *Greg Mirsky > *Sent:* Tuesday, February 09, 2010 1:37 PM > *To:* Vishwas Manral > *Cc:* Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net > > *Subject:* Re: BFD LSP Ping > > Dear All, > I've found this thread is the closest to a question of my own and since I > couldn't find any conclusion decided to add $.02 > As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 > when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But > it requires set IP TTL of BFD packet to 1 while BFD single hop document in > Section 5 requires TTL == 255 if Authentication not in use. BFD packet must > be discarded if received TTL /= 255. If Authentication being used, still, > TTL == 255 required, but "check TTL" eased to "may drop if TTL /= 255". > > Should BFD MPLS text be changed to sync with BFD single hop in regard to > setting TTL value? > > Regards, > Greg > > On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral wrote: > >> Hi, >> >> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >> Uniform Model LSP. >> >> The draft states that: >> >> >> The BFD control packet sent by the ingress LSR MUST be a UDP packet >> with a well known destination port 3784 [BFD-IP] and a source port >> assigned by the sender as per the procedures in [BFD-IP]. >> >> A single hop session verifies the TTL is 255. However the TTL in the >> IP header is changed at the Egress before the IP header handling >> because we are using hte uniform model. I think the easiest and the >> best way for this would be to use Multihop sessions in both >> directions. >> >> Do let me know if I am missing something? >> >> Thanks, >> Vishwas >> > > --001517477f860a1361047f325943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
I agree with Shahram. TTL Check is viewed as minimal, weaker= than authentication, security measure to protect one from spoofing.
To = your second question (another mail I've noticed), I believe that Sectio= n 9. Security Considerations in BFD single hop document recommends associat= ion of a BFD session with incoming interface as method to improve infrastru= cture security.

Regards,
Greg

On Tue, Feb 9, 2010 = at 2:02 PM, Shahram Davari <davari@broadcom.com> wrote:
Hi=20 Greg,
= =A0
Do you=20 know the reason why TTL=3D255 check is not required for BFD with=20 Authentication?
= =A0
Thanks,=
Shahram=

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vis= hwas=20 Manral
Cc: Kireeti Kompella; rtg-bfd@ietf.org;=20 rahul@juniper.net

Subject: Re: BFD LSP Ping
Dear All,
I've found this thread is the closest to a ques= tion of=20 my own and since I couldn't find any conclusion decided to add $.02
= As=20 Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784 wh= en=20 BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. But it= =20 requires set IP TTL of BFD packet to 1 while BFD single hop document in Sec= tion=20 5 requires TTL =3D=3D 255 if Authentication not in use. BFD packet must be = discarded=20 if received TTL /=3D 255. If Authentication being used, still, TTL =3D=3D 2= 55=20 required, but "check TTL" eased to "may drop if TTL /=3D 255= ".

Should BFD=20 MPLS text be changed to sync with BFD single hop in regard to setting TTL= =20 value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com>=20 wrote:
Hi,

I=20 noticed a basic issue with BFD LSP ping with a a TTL processing in=20 a
Uniform Model LSP.

The draft states that:


=A0 The= =20 BFD control packet sent by the ingress LSR MUST be a UDP packet
=A0 wi= th=20 a well known destination port 3784 [BFD-IP] and a source port
=A0=20 assigned by the sender as per the procedures in [BFD-IP].

A single= hop=20 session verifies the TTL is 255. However the TTL in the
IP header is= =20 changed at the Egress before the IP header handling
because we are usi= ng=20 hte uniform model. I think the easiest and the
best way for this would= be=20 to use Multihop sessions in both
directions.

Do let me know if = I am=20 missing something?

Thanks,
Vishwas
<= /font>


--001517477f860a1361047f325943-- From vishwas.ietf@gmail.com Tue Feb 9 15:04:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600D928C1AB for ; Tue, 9 Feb 2010 15:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVWeJeoZHAW9 for ; Tue, 9 Feb 2010 15:04:06 -0800 (PST) Received: from mail-yx0-f195.google.com (mail-yx0-f195.google.com [209.85.210.195]) by core3.amsl.com (Postfix) with ESMTP id 0C69A3A70FC for ; Tue, 9 Feb 2010 15:04:05 -0800 (PST) Received: by yxe33 with SMTP id 33so610306yxe.5 for ; Tue, 09 Feb 2010 15:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lfy0c0n5W+ZTqiAEe2k35B5OWrCDfdmPZkp7BWogYhs=; b=v3se8RM1//d1PNGBNmAuqLlAWokrLtOK0aTPgp9+RYzLDJ0DUUKnQgpWDCmr25lIHA t08oP81P9KnLaqn7CmSGYmZcVTcyTF7SCzTWU0KZciFro6mKXxtIYsS33vdZR9eZtDvn FmEgqHojp7YjVeJRbATHrRCOlbiHkH1Hvi1wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T8uomllnoEy5hFyA5Cfk91htpGFrKS1YRNA73AbFMa2YqjVdaHVNw1Jg6opSwzWPTb 9nh2PelM/ccjEhLDV6ntmW+GWafIVobhgze+CyJxPE+HiwU4OiN9GXgFsAv4Yu/3jNL9 T19MlvjHb2xB4Ev3+QUL0YpJGkTNiCscp1Ffs= MIME-Version: 1.0 Received: by 10.150.119.42 with SMTP id r42mr1065229ybc.325.1265756709745; Tue, 09 Feb 2010 15:05:09 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 9 Feb 2010 15:05:09 -0800 Message-ID: <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=000e0cd71a5a0e7501047f32f393 Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 23:04:07 -0000 --000e0cd71a5a0e7501047f32f393 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I think for single-hop sessions the interface/ tunnel binding check is necessary. This however may not be the case for Multi-hop sessions. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari wrote: > Hi Wishwas, > > One more questions. The BFD drafts are all very ambiguous regarding > interface binding check? is there a requirement to check BFD binding to > incoming interface? How about binding to an incoming tunnel? > > Thanks, > Shahram > > > > ------------------------------ > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, February 09, 2010 2:04 PM > *To:* Shahram Davari > *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net > > *Subject:* Re: BFD LSP Ping > > Hi Shahram, > > The idea is the TTL check is an approximation of the sanity of the packet. > When authentication is enabled this check is redundant in my view and hence > the check is not required. > > Thanks, > Vishwas > On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari wrote: > >> Hi Greg, >> >> Do you know the reason why TTL=255 check is not required for BFD with >> Authentication? >> >> Thanks, >> Shahram >> >> ------------------------------ >> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >> Behalf Of *Greg Mirsky >> *Sent:* Tuesday, February 09, 2010 1:37 PM >> *To:* Vishwas Manral >> *Cc:* Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >> >> *Subject:* Re: BFD LSP Ping >> >> Dear All, >> I've found this thread is the closest to a question of my own and since I >> couldn't find any conclusion decided to add $.02 >> As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port >> 3784 when BFD control packets are sent over MPLS LSP in IP/UDP >> encapsulation. But it requires set IP TTL of BFD packet to 1 while BFD >> single hop document in Section 5 requires TTL == 255 if Authentication not >> in use. BFD packet must be discarded if received TTL /= 255. If >> Authentication being used, still, TTL == 255 required, but "check TTL" eased >> to "may drop if TTL /= 255". >> >> Should BFD MPLS text be changed to sync with BFD single hop in regard to >> setting TTL value? >> >> Regards, >> Greg >> >> On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral wrote: >> >>> Hi, >>> >>> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >>> Uniform Model LSP. >>> >>> The draft states that: >>> >>> >>> The BFD control packet sent by the ingress LSR MUST be a UDP packet >>> with a well known destination port 3784 [BFD-IP] and a source port >>> assigned by the sender as per the procedures in [BFD-IP]. >>> >>> A single hop session verifies the TTL is 255. However the TTL in the >>> IP header is changed at the Egress before the IP header handling >>> because we are using hte uniform model. I think the easiest and the >>> best way for this would be to use Multihop sessions in both >>> directions. >>> >>> Do let me know if I am missing something? >>> >>> Thanks, >>> Vishwas >>> >> >> > --000e0cd71a5a0e7501047f32f393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
I think for single-hop sessions the interface/ tunnel=A0binding check = is necessary. This however may not be the case for Multi-hop sessions.
=A0
Thanks,
Vishwas

On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom= .com> wrote:
Hi Wishwas,
= =A0
One more quest= ions. The BFD drafts are all very ambiguous regarding interface binding che= ck? is there a requirement to check BFD binding to incoming interface? How = about binding to an incoming tunnel?
= =A0
Thanks,=
Shahram=
= =A0
= =A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.co= m]
Sent: Tuesday, February 09, 2010 2:04 PM
To: Sh= ahram Davari
Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
The idea is the TTL check is an approximation of the sanity of the pac= ket. When authentication is enabled this check is redundant in my view and = hence the check is not required.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi Greg,
= =A0
Do you know th= e reason why TTL=3D255 check is not required for BFD with Authentication?
= =A0
Thanks,=
Shahram=

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Greg Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vishwas Manra= l
Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a ques= tion of my own and since I couldn't find any conclusion decided to add = $.02
As Vishwas have mentioned, BFD MPLS draft requires single hop UDP p= ort 3784 when BFD control packets are sent over MPLS LSP in IP/UDP encapsul= ation. But it requires set IP TTL of BFD packet to 1 while BFD single hop d= ocument in Section 5 requires TTL =3D=3D 255 if Authentication not in use. = BFD packet must be discarded if received TTL /=3D 255. If Authentication be= ing used, still, TTL =3D=3D 255 required, but "check TTL" eased t= o "may drop if TTL /=3D 255".

Should BFD MPLS text be changed to sync with BFD single hop in regard t= o setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:
Hi,

I noticed= a basic issue with BFD LSP ping with a a TTL processing in a
Uniform Mo= del LSP.

The draft states that:


=A0 The BFD control packet sent by th= e ingress LSR MUST be a UDP packet
=A0 with a well known destination por= t 3784 [BFD-IP] and a source port
=A0 assigned by the sender as per the = procedures in [BFD-IP].

A single hop session verifies the TTL is 255. However the TTL in theIP header is changed at the Egress before the IP header handling
becaus= e we are using hte uniform model. I think the easiest and the
best way f= or this would be to use Multihop sessions in both
directions.

Do let me know if I am missing something?

Thanks,=
Vishwas

=

--000e0cd71a5a0e7501047f32f393-- From davari@broadcom.com Tue Feb 9 16:08:25 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3886328C104 for ; Tue, 9 Feb 2010 16:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiLUfNvWYLus for ; Tue, 9 Feb 2010 16:08:24 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 168A428C0E8 for ; Tue, 9 Feb 2010 16:08:24 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 09 Feb 2010 16:09:20 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 9 Feb 2010 16:09:20 -0800 From: "Shahram Davari" To: "Vishwas Manral" Date: Tue, 9 Feb 2010 16:09:18 -0800 Subject: RE: BFD LSP Ping Thread-Topic: BFD LSP Ping Thread-Index: Acqp3FnPYyE1ATwlTj2ZG6ocDPwMWwACLYYQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68167E48705@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> In-Reply-To: <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 676F26BA38O105875423-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48705SJEXCHCCR02co_ Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:08:25 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48705SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, But this doesn't work when you have MPLS PHP or when you have MPLS FRR or w= hen you have OSPF rerouting to a different interface. Regards, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 3:05 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, I think for single-hop sessions the interface/ tunnel binding check is nece= ssary. This however may not be the case for Multi-hop sessions. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari > wrote: Hi Wishwas, One more questions. The BFD drafts are all very ambiguous regarding interfa= ce binding check? is there a requirement to check BFD binding to incoming i= nterface? How about binding to an incoming tunnel? Thanks, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 2:04 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, The idea is the TTL check is an approximation of the sanity of the packet. = When authentication is enabled this check is redundant in my view and hence= the check is not required. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari > wrote: Hi Greg, Do you know the reason why TTL=3D255 check is not required for BFD with Aut= hentication? Thanks, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Greg M= irsky Sent: Tuesday, February 09, 2010 1:37 PM To: Vishwas Manral Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juni= per.net Subject: Re: BFD LSP Ping Dear All, I've found this thread is the closest to a question of my own and since I c= ouldn't find any conclusion decided to add $.02 As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784= when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. B= ut it requires set IP TTL of BFD packet to 1 while BFD single hop document = in Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD pack= et must be discarded if received TTL /=3D 255. If Authentication being used= , still, TTL =3D=3D 255 required, but "check TTL" eased to "may drop if TTL= /=3D 255". Should BFD MPLS text be changed to sync with BFD single hop in regard to se= tting TTL value? Regards, Greg On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral > wrote: Hi, I noticed a basic issue with BFD LSP ping with a a TTL processing in a Uniform Model LSP. The draft states that: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. A single hop session verifies the TTL is 255. However the TTL in the IP header is changed at the Egress before the IP header handling because we are using hte uniform model. I think the easiest and the best way for this would be to use Multihop sessions in both directions. Do let me know if I am missing something? Thanks, Vishwas --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48705SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,
 
But=20 this doesn't work when you have MPLS PHP or when you have MPLS FRR or when = you=20 have OSPF rerouting to a different interface.
 
Regards,
Shahram 

From: Vishwas Manral=20 [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010= 3:05=20 PM
To: Shahram Davari
Cc: Greg Mirsky; Kireeti Kompella= ;=20 rtg-bfd@ietf.org; rahul@juniper.net
Subject: Re: BFD LSP=20 Ping

Hi Shahram,
 
I think for single-hop sessions the interface/ tunnel binding che= ck is=20 necessary. This however may not be the case for Multi-hop sessions.
 
Thanks,
Vishwas

On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari <davari@broadcom.com> wrot= e:
Hi=20 Wishwas,
&nbs= p;
One more questions= . The BFD=20 drafts are all very ambiguous regarding interface binding check? is there= a=20 requirement to check BFD binding to incoming interface? How about binding= to=20 an incoming tunnel?
&nbs= p;
Thanks,
Shahram
&nbs= p;
 

From: Vishwas Manral [mailto:vishwas.ietf@gmail= .com]=20
Sent: Tuesday, February 09, 2010 2:04 PM
To: Shahram= =20 Davari
Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP=20 Ping

Hi Shahram,
 
The idea is the TTL check is an approximation of the sanity of the=20 packet. When authentication is enabled this check is redundant in my view= and=20 hence the check is not required.
 
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <= SPAN=20 dir=3Dltr><davari@broadcom.com> wrote:
Hi=20 Greg,
&n= bsp;
Do you know the = reason why=20 TTL=3D255 check is not required for BFD with=20 Authentication?
&n= bsp;
Thanks,
Shahram

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg= =20 Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To:= =20 Vishwas Manral
Cc: Kireeti Kompella; rtg-bfd@ietf.org; = rahul@juniper.net= =20

Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a ques= tion=20 of my own and since I couldn't find any conclusion decided to add $.02<= BR>As=20 Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 378= 4=20 when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation= . But=20 it requires set IP TTL of BFD packet to 1 while BFD single hop document= in=20 Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD pac= ket must=20 be discarded if received TTL /=3D 255. If Authentication being used, st= ill,=20 TTL =3D=3D 255 required, but "check TTL" eased to "may drop if TTL /=3D= =20 255".

Should BFD MPLS text be changed to sync with BFD single ho= p in=20 regard to setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manra= l <vishwas.ietf@gmail.com> wrote:
Hi,

I=20 noticed a basic issue with BFD LSP ping with a a TTL processing in=20 a
Uniform Model LSP.

The draft states that:


&nbs= p;=20 The BFD control packet sent by the ingress LSR MUST be a UDP=20 packet
  with a well known destination port 3784 [BFD-IP] and= a=20 source port
  assigned by the sender as per the procedures in= =20 [BFD-IP].

A single hop session verifies the TTL is 255. Howeve= r the=20 TTL in the
IP header is changed at the Egress before the IP header= =20 handling
because we are using hte uniform model. I think the easie= st=20 and the
best way for this would be to use Multihop sessions in=20 both
directions.

Do let me know if I am missing=20 something?

Thanks,
Vishwas



= --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48705SJEXCHCCR02co_-- From vishwas.ietf@gmail.com Tue Feb 9 16:41:33 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12503A75F2 for ; Tue, 9 Feb 2010 16:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA5BTSpIz7wi for ; Tue, 9 Feb 2010 16:41:32 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 2F8883A75F8 for ; Tue, 9 Feb 2010 16:41:31 -0800 (PST) Received: by ywh15 with SMTP id 15so1975835ywh.5 for ; Tue, 09 Feb 2010 16:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0Q56bTNZ8tZWrtkycAUN3sFpMKRPSssOnZmGbpIbnQ8=; b=SV2KBGEbkglxy//fyfCYfyww7FDB9jIMLS4/YkrIc9z8rsqzvGiFUiJVWa5bgLp3GM DcO02l3LdfKtnGfdUEbPivAf9Tpq/lF5yWO8/F0m2wnlXioCnPjEiEqHrpg8gXhLt98q XD7LNI5JadRb58sjFGxFllg6N058feP5S0+RE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wLyMQKcD21VjZkskguT5xYAafIK+qmt+KOzFIKQLI/a6j2wT1X60jPMbQ5LGoNJCVD B4/CMOjnG7kGnprrRglz4M38cJSyEh57FmkNC4klmaVgv6jPX/U7PAkHeWrA2KBEt8yW dfICD6PJHj9ZZCTfMAewbBuAkHipqr0PvcY/k= MIME-Version: 1.0 Received: by 10.150.119.42 with SMTP id r42mr1180232ybc.325.1265762556448; Tue, 09 Feb 2010 16:42:36 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E48705@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E48705@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 9 Feb 2010 16:42:36 -0800 Message-ID: <77ead0ec1002091642s7697f9abpc676d71af4bf25b2@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=000e0cd71a5a8c11ee047f344f46 Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:41:33 -0000 --000e0cd71a5a8c11ee047f344f46 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, There is no-rerouting allowed in the case of a directly connected interface adjacency in OSPF. However you are right regarding rerouting etc where we probably need to check the two LSP's as one. Thanks, Vishwas On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari wrote: > Hi, > > But this doesn't work when you have MPLS PHP or when you have MPLS FRR or > when you have OSPF rerouting to a different interface. > > Regards, > Shahram > > ------------------------------ > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, February 09, 2010 3:05 PM > > *To:* Shahram Davari > *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net > *Subject:* Re: BFD LSP Ping > > Hi Shahram, > > I think for single-hop sessions the interface/ tunnel binding check is > necessary. This however may not be the case for Multi-hop sessions. > > Thanks, > Vishwas > > On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari wrote: > >> Hi Wishwas, >> >> One more questions. The BFD drafts are all very ambiguous regarding >> interface binding check? is there a requirement to check BFD binding to >> incoming interface? How about binding to an incoming tunnel? >> >> Thanks, >> Shahram >> >> >> >> ------------------------------ >> *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> *Sent:* Tuesday, February 09, 2010 2:04 PM >> *To:* Shahram Davari >> *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >> >> *Subject:* Re: BFD LSP Ping >> >> Hi Shahram, >> >> The idea is the TTL check is an approximation of the sanity of the packet. >> When authentication is enabled this check is redundant in my view and hence >> the check is not required. >> >> Thanks, >> Vishwas >> On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari wrote: >> >>> Hi Greg, >>> >>> Do you know the reason why TTL=255 check is not required for BFD with >>> Authentication? >>> >>> Thanks, >>> Shahram >>> >>> ------------------------------ >>> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >>> Behalf Of *Greg Mirsky >>> *Sent:* Tuesday, February 09, 2010 1:37 PM >>> *To:* Vishwas Manral >>> *Cc:* Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >>> >>> *Subject:* Re: BFD LSP Ping >>> >>> Dear All, >>> I've found this thread is the closest to a question of my own and since I >>> couldn't find any conclusion decided to add $.02 >>> As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port >>> 3784 when BFD control packets are sent over MPLS LSP in IP/UDP >>> encapsulation. But it requires set IP TTL of BFD packet to 1 while BFD >>> single hop document in Section 5 requires TTL == 255 if Authentication not >>> in use. BFD packet must be discarded if received TTL /= 255. If >>> Authentication being used, still, TTL == 255 required, but "check TTL" eased >>> to "may drop if TTL /= 255". >>> >>> Should BFD MPLS text be changed to sync with BFD single hop in regard to >>> setting TTL value? >>> >>> Regards, >>> Greg >>> >>> On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral wrote: >>> >>>> Hi, >>>> >>>> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >>>> Uniform Model LSP. >>>> >>>> The draft states that: >>>> >>>> >>>> The BFD control packet sent by the ingress LSR MUST be a UDP packet >>>> with a well known destination port 3784 [BFD-IP] and a source port >>>> assigned by the sender as per the procedures in [BFD-IP]. >>>> >>>> A single hop session verifies the TTL is 255. However the TTL in the >>>> IP header is changed at the Egress before the IP header handling >>>> because we are using hte uniform model. I think the easiest and the >>>> best way for this would be to use Multihop sessions in both >>>> directions. >>>> >>>> Do let me know if I am missing something? >>>> >>>> Thanks, >>>> Vishwas >>>> >>> >>> >> > --000e0cd71a5a8c11ee047f344f46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
There is no-rerouting allowed in the case of a directly connected inte= rface adjacency in OSPF.
=A0
However you are right regarding rerouting etc where we probably need t= o check the two LSP's as one.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom= .com> wrote:
Hi,
= =A0
But this doesn= 't work when you have MPLS PHP or when you have MPLS FRR or when you ha= ve OSPF rerouting to a=A0different interface.
=A0
Regards,
Shahram= =A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010 3:05 PM=20

To: Shahram Davari
Cc: Greg Mirsky; = Kireeti Kompella; rtg= -bfd@ietf.org; r= ahul@juniper.net
Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
I think for single-hop sessions the interface/ tunnel=A0binding check = is necessary. This however may not be the case for Multi-hop sessions.
=A0
Thanks,
Vishwas

On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi Wishwas,
= =A0
One more quest= ions. The BFD drafts are all very ambiguous regarding interface binding che= ck? is there a requirement to check BFD binding to incoming interface? How = about binding to an incoming tunnel?
= =A0
Thanks,=
Shahram=
= =A0
= =A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.co= m]
Sent: Tuesday, February 09, 2010 2:04 PM
To: Sh= ahram Davari
Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
The idea is the TTL check is an approximation of the sanity of the pac= ket. When authentication is enabled this check is redundant in my view and = hence the check is not required.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi Greg,
= =A0
Do you know th= e reason why TTL=3D255 check is not required for BFD with Authentication?
= =A0
Thanks,=
Shahram=

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Greg Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vishwas Manra= l
Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a ques= tion of my own and since I couldn't find any conclusion decided to add = $.02
As Vishwas have mentioned, BFD MPLS draft requires single hop UDP p= ort 3784 when BFD control packets are sent over MPLS LSP in IP/UDP encapsul= ation. But it requires set IP TTL of BFD packet to 1 while BFD single hop d= ocument in Section 5 requires TTL =3D=3D 255 if Authentication not in use. = BFD packet must be discarded if received TTL /=3D 255. If Authentication be= ing used, still, TTL =3D=3D 255 required, but "check TTL" eased t= o "may drop if TTL /=3D 255".

Should BFD MPLS text be changed to sync with BFD single hop in regard t= o setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:
Hi,

I noticed= a basic issue with BFD LSP ping with a a TTL processing in a
Uniform Mo= del LSP.

The draft states that:


=A0 The BFD control packet sent by th= e ingress LSR MUST be a UDP packet
=A0 with a well known destination por= t 3784 [BFD-IP] and a source port
=A0 assigned by the sender as per the = procedures in [BFD-IP].

A single hop session verifies the TTL is 255. However the TTL in theIP header is changed at the Egress before the IP header handling
becaus= e we are using hte uniform model. I think the easiest and the
best way f= or this would be to use Multihop sessions in both
directions.

Do let me know if I am missing something?

Thanks,=
Vishwas

=


--000e0cd71a5a8c11ee047f344f46-- From davari@broadcom.com Tue Feb 9 17:25:08 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98E03A7649 for ; Tue, 9 Feb 2010 17:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5VK+a5EhdBx for ; Tue, 9 Feb 2010 17:25:07 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 9F0C03A6868 for ; Tue, 9 Feb 2010 17:25:07 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 09 Feb 2010 17:26:02 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 9 Feb 2010 17:26:02 -0800 From: "Shahram Davari" To: "Vishwas Manral" Date: Tue, 9 Feb 2010 17:26:00 -0800 Subject: RE: BFD LSP Ping Thread-Topic: BFD LSP Ping Thread-Index: Acqp6fna7cWNKnDLQTegRBcPwt5KCQABZAug Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68167E48720@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E48705@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091642s7697f9abpc676d71af4bf25b2@mail.gmail.com> In-Reply-To: <77ead0ec1002091642s7697f9abpc676d71af4bf25b2@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 676CD4A020S21936680-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48720SJEXCHCCR02co_ Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 01:25:09 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48720SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Wishwas, OK, may be no OSPF reroute is possible for 1-hop, but in a multi-access med= ia such as 802.1 Ethernet, the Spanning tree can change the arriving interf= ace. Also LAG can also change the interface. Therefore I don't think checking the interface is a good thing. Regards, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 4:43 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, There is no-rerouting allowed in the case of a directly connected interface= adjacency in OSPF. However you are right regarding rerouting etc where we probably need to che= ck the two LSP's as one. Thanks, Vishwas On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari > wrote: Hi, But this doesn't work when you have MPLS PHP or when you have MPLS FRR or w= hen you have OSPF rerouting to a different interface. Regards, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 3:05 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, I think for single-hop sessions the interface/ tunnel binding check is nece= ssary. This however may not be the case for Multi-hop sessions. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari > wrote: Hi Wishwas, One more questions. The BFD drafts are all very ambiguous regarding interfa= ce binding check? is there a requirement to check BFD binding to incoming i= nterface? How about binding to an incoming tunnel? Thanks, Shahram ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, February 09, 2010 2:04 PM To: Shahram Davari Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net Subject: Re: BFD LSP Ping Hi Shahram, The idea is the TTL check is an approximation of the sanity of the packet. = When authentication is enabled this check is redundant in my view and hence= the check is not required. Thanks, Vishwas On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari > wrote: Hi Greg, Do you know the reason why TTL=3D255 check is not required for BFD with Aut= hentication? Thanks, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Greg M= irsky Sent: Tuesday, February 09, 2010 1:37 PM To: Vishwas Manral Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juni= per.net Subject: Re: BFD LSP Ping Dear All, I've found this thread is the closest to a question of my own and since I c= ouldn't find any conclusion decided to add $.02 As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port 3784= when BFD control packets are sent over MPLS LSP in IP/UDP encapsulation. B= ut it requires set IP TTL of BFD packet to 1 while BFD single hop document = in Section 5 requires TTL =3D=3D 255 if Authentication not in use. BFD pack= et must be discarded if received TTL /=3D 255. If Authentication being used= , still, TTL =3D=3D 255 required, but "check TTL" eased to "may drop if TTL= /=3D 255". Should BFD MPLS text be changed to sync with BFD single hop in regard to se= tting TTL value? Regards, Greg On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral > wrote: Hi, I noticed a basic issue with BFD LSP ping with a a TTL processing in a Uniform Model LSP. The draft states that: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. A single hop session verifies the TTL is 255. However the TTL in the IP header is changed at the Egress before the IP header handling because we are using hte uniform model. I think the easiest and the best way for this would be to use Multihop sessions in both directions. Do let me know if I am missing something? Thanks, Vishwas --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48720SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi=20 Wishwas,
 
OK,=20 may be no OSPF reroute is possible for 1-hop, but in a multi-access media s= uch=20 as 802.1 Ethernet, the Spanning tree can change the arriving interface= .=20 Also LAG can also change the interface.
 
Therefore I don't think checking the interface is a good=20 thing.
 
Regards,
Shahram

From: Vishwas Manral=20 [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010= 4:43=20 PM
To: Shahram Davari
Cc: Greg Mirsky; Kireeti Kompella= ;=20 rtg-bfd@ietf.org; rahul@juniper.net
Subject: Re: BFD LSP=20 Ping

Hi Shahram,
 
There is no-rerouting allowed in the case of a directly connected inte= rface=20 adjacency in OSPF.
 
However you are right regarding rerouting etc where we probably need t= o=20 check the two LSP's as one.
 
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari <davari@broadcom.com> wrot= e:
Hi,<= /DIV>
&nbs= p;
But this doesn't w= ork when=20 you have MPLS PHP or when you have MPLS FRR or when you have OSPF rerouti= ng to=20 a different interface.
 
Regards,
Shahram 

From: Vishwas Manral [mailto:vishwas.ietf@gmail= .com]=20
Sent: Tuesday, February 09, 2010 3:05 PM=20

To: Shahram Davari
Cc: Greg Mirsky; = Kireeti=20 Kompella; rtg-bfd@ietf.org; rahul@juniper.net
Subject: Re: BFD LSP=20 Ping

Hi Shahram,
 
I think for single-hop sessions the interface/ tunnel binding c= heck=20 is necessary. This however may not be the case for Multi-hop sessions.
 
Thanks,
Vishwas

On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari <= SPAN=20 dir=3Dltr><davari@broadcom.com> wrote:
Hi=20 Wishwas,
&n= bsp;
One more questio= ns. The BFD=20 drafts are all very ambiguous regarding interface binding check? is the= re a=20 requirement to check BFD binding to incoming interface? How about bindi= ng to=20 an incoming tunnel?
&n= bsp;
Thanks,
Shahram
&n= bsp;
 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, F= ebruary=20 09, 2010 2:04 PM
To: Shahram Davari
Cc: Greg Mirsky= ;=20 Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Hi Shahram,
 
The idea is the TTL check is an approximation of the sanity of the= =20 packet. When authentication is enabled this check is redundant in my vi= ew=20 and hence the check is not required.
 
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari= <davari@broadcom.com> wrote:
Hi=20 Greg,
 
Do you know th= e reason=20 why TTL=3D255 check is not required for BFD with=20 Authentication?
 
Thanks,
Shahram

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gre= g=20 Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To:=20 Vishwas Manral
Cc: Kireeti Kompella; rtg-bfd@ietf.org= ; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a=20 question of my own and since I couldn't find any conclusion decided t= o add=20 $.02
As Vishwas have mentioned, BFD MPLS draft requires single hop= UDP=20 port 3784 when BFD control packets are sent over MPLS LSP in IP/UDP=20 encapsulation. But it requires set IP TTL of BFD packet to 1 while BF= D=20 single hop document in Section 5 requires TTL =3D=3D 255 if Authentic= ation not=20 in use. BFD packet must be discarded if received TTL /=3D 255. If=20 Authentication being used, still, TTL =3D=3D 255 required, but "check= TTL"=20 eased to "may drop if TTL /=3D 255".

Should BFD MPLS text be c= hanged=20 to sync with BFD single hop in regard to setting TTL=20 value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Man= ral=20 <vishwas.ietf@gmail.com> wrote:
Hi,

I=20 noticed a basic issue with BFD LSP ping with a a TTL processing in= =20 a
Uniform Model LSP.

The draft states that:


&n= bsp;=20 The BFD control packet sent by the ingress LSR MUST be a UDP=20 packet
  with a well known destination port 3784 [BFD-IP] a= nd a=20 source port
  assigned by the sender as per the procedures = in=20 [BFD-IP].

A single hop session verifies the TTL is 255. Howe= ver=20 the TTL in the
IP header is changed at the Egress before the IP= =20 header handling
because we are using hte uniform model. I think = the=20 easiest and the
best way for this would be to use Multihop sessi= ons=20 in both
directions.

Do let me know if I am missing=20 something?

Thanks,
Vishwas

=



--_000_2C2F1EBA8050E74EA81502D5740B4BD68167E48720SJEXCHCCR02co_-- From vishwas.ietf@gmail.com Tue Feb 9 17:30:21 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0732528C15C for ; Tue, 9 Feb 2010 17:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEZEEeP1b95Z for ; Tue, 9 Feb 2010 17:30:18 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id ACFC028C228 for ; Tue, 9 Feb 2010 17:30:17 -0800 (PST) Received: by ywh15 with SMTP id 15so2018962ywh.5 for ; Tue, 09 Feb 2010 17:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nNaaNWnT1AD6OPF7Krjc6iquOHDMLt4+vgyR/TSicoo=; b=n/e9mV7Bd+gm7mNvJYj7/RVJmSFBC2UWHcTJ810QGd0E8BNc/YIGog/qQXQ9dnVfy4 AM2wu1pnWhQqeRsOUncWHW5XjFCjPDOhocq5mbDAB5zaeunUN2jmlWpcrlReed50L3eT WoLF5rYJ5yooxPJlxebIwrlSnGvaDMI5Ji8TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RYkxep4GDYJqB3aE+y35HyuEEWGcd1Je3lddcoQX+VLNxSVw+oAYAIKBKPKWjwM0jB 6RtiPZSlQN3IOxYiYY5VLfjjE5xRt87h1EOvpuA5jnkM+RPj/BFV183AODYOLhsDpSmH eTafQU270NSazAJm8N+J1ZEYdpBW5VFlSGSts= MIME-Version: 1.0 Received: by 10.150.55.32 with SMTP id d32mr1250786yba.261.1265765482644; Tue, 09 Feb 2010 17:31:22 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E48720@SJEXCHCCR02.corp.ad.broadcom.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <787be2781002091336m7b639f66k44edc177577043ab@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DA@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091404pb1ddfa8s2dd573acf89ccfbb@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E486DC@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091505u52023162wb896625e274f28df@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E48705@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002091642s7697f9abpc676d71af4bf25b2@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E48720@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 9 Feb 2010 17:31:22 -0800 Message-ID: <77ead0ec1002091731y7e74f66eof0d8436a76303254@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=000e0cd70d3ef646e7047f34fd92 Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , "rahul@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 01:30:21 -0000 --000e0cd70d3ef646e7047f34fd92 Content-Type: text/plain; charset=ISO-8859-1 LAG interfaces will be shown as 1 interface to layer-3. Thanks, Vishwas On Tue, Feb 9, 2010 at 5:26 PM, Shahram Davari wrote: > Hi Wishwas, > > OK, may be no OSPF reroute is possible for 1-hop, but in a multi-access > media such as 802.1 Ethernet, the Spanning tree can change the arriving > interface. Also LAG can also change the interface. > > Therefore I don't think checking the interface is a good thing. > > Regards, > Shahram > > ------------------------------ > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, February 09, 2010 4:43 PM > > *To:* Shahram Davari > *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net > *Subject:* Re: BFD LSP Ping > > Hi Shahram, > > There is no-rerouting allowed in the case of a directly connected interface > adjacency in OSPF. > > However you are right regarding rerouting etc where we probably need to > check the two LSP's as one. > > Thanks, > Vishwas > On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari wrote: > >> Hi, >> >> But this doesn't work when you have MPLS PHP or when you have MPLS FRR or >> when you have OSPF rerouting to a different interface. >> >> Regards, >> Shahram >> >> ------------------------------ >> *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> *Sent:* Tuesday, February 09, 2010 3:05 PM >> >> *To:* Shahram Davari >> *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >> *Subject:* Re: BFD LSP Ping >> >> Hi Shahram, >> >> I think for single-hop sessions the interface/ tunnel binding check is >> necessary. This however may not be the case for Multi-hop sessions. >> >> Thanks, >> Vishwas >> >> On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari wrote: >> >>> Hi Wishwas, >>> >>> One more questions. The BFD drafts are all very ambiguous regarding >>> interface binding check? is there a requirement to check BFD binding to >>> incoming interface? How about binding to an incoming tunnel? >>> >>> Thanks, >>> Shahram >>> >>> >>> >>> ------------------------------ >>> *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> *Sent:* Tuesday, February 09, 2010 2:04 PM >>> *To:* Shahram Davari >>> *Cc:* Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >>> >>> *Subject:* Re: BFD LSP Ping >>> >>> Hi Shahram, >>> >>> The idea is the TTL check is an approximation of the sanity of the >>> packet. When authentication is enabled this check is redundant in my view >>> and hence the check is not required. >>> >>> Thanks, >>> Vishwas >>> On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari wrote: >>> >>>> Hi Greg, >>>> >>>> Do you know the reason why TTL=255 check is not required for BFD with >>>> Authentication? >>>> >>>> Thanks, >>>> Shahram >>>> >>>> ------------------------------ >>>> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >>>> Behalf Of *Greg Mirsky >>>> *Sent:* Tuesday, February 09, 2010 1:37 PM >>>> *To:* Vishwas Manral >>>> *Cc:* Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net >>>> >>>> *Subject:* Re: BFD LSP Ping >>>> >>>> Dear All, >>>> I've found this thread is the closest to a question of my own and since >>>> I couldn't find any conclusion decided to add $.02 >>>> As Vishwas have mentioned, BFD MPLS draft requires single hop UDP port >>>> 3784 when BFD control packets are sent over MPLS LSP in IP/UDP >>>> encapsulation. But it requires set IP TTL of BFD packet to 1 while BFD >>>> single hop document in Section 5 requires TTL == 255 if Authentication not >>>> in use. BFD packet must be discarded if received TTL /= 255. If >>>> Authentication being used, still, TTL == 255 required, but "check TTL" eased >>>> to "may drop if TTL /= 255". >>>> >>>> Should BFD MPLS text be changed to sync with BFD single hop in regard to >>>> setting TTL value? >>>> >>>> Regards, >>>> Greg >>>> >>>> On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >>>>> Uniform Model LSP. >>>>> >>>>> The draft states that: >>>>> >>>>> >>>>> The BFD control packet sent by the ingress LSR MUST be a UDP packet >>>>> with a well known destination port 3784 [BFD-IP] and a source port >>>>> assigned by the sender as per the procedures in [BFD-IP]. >>>>> >>>>> A single hop session verifies the TTL is 255. However the TTL in the >>>>> IP header is changed at the Egress before the IP header handling >>>>> because we are using hte uniform model. I think the easiest and the >>>>> best way for this would be to use Multihop sessions in both >>>>> directions. >>>>> >>>>> Do let me know if I am missing something? >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>> >>>> >>> >> > --000e0cd70d3ef646e7047f34fd92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
LAG interfaces will be shown as 1 interface to layer-3.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 5:26 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom= .com> wrote:
Hi Wishwas,
= =A0
OK, may be no = OSPF reroute is possible for 1-hop, but in a multi-access media such as 802= .1 Ethernet,=A0the Spanning tree can change the arriving interface. Also LA= G can also change the interface.
= =A0
Therefore I do= n't think checking the interface is a good thing.
= =A0
Regards,
Shahram=

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010 4:43 PM=20

To: Shahram Davari
Cc: Greg Mirsky; = Kireeti Kompella; rtg= -bfd@ietf.org; r= ahul@juniper.net
Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
There is no-rerouting allowed in the case of a directly connected inte= rface adjacency in OSPF.
=A0
However you are right regarding rerouting etc where we probably need t= o check the two LSP's as one.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 4:09 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi,
= =A0
But this doesn= 't work when you have MPLS PHP or when you have MPLS FRR or when you ha= ve OSPF rerouting to a=A0different interface.
=A0
Regards,
Shahram= =A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, February 09, 2010 3:05 PM=20

To: Shahram Davari
Cc: Greg Mirsky; Kireeti Kompe= lla; rtg-bfd@ietf.org= ; rahul@juniper.= net
Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
I think for single-hop sessions the interface/ tunnel=A0binding check = is necessary. This however may not be the case for Multi-hop sessions.
=A0
Thanks,
Vishwas

On Tue, Feb 9, 2010 at 2:07 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi Wishwas,
= =A0
One more quest= ions. The BFD drafts are all very ambiguous regarding interface binding che= ck? is there a requirement to check BFD binding to incoming interface? How = about binding to an incoming tunnel?
= =A0
Thanks,=
Shahram=
= =A0
= =A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.co= m]
Sent: Tuesday, February 09, 2010 2:04 PM
To: Sh= ahram Davari
Cc: Greg Mirsky; Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Hi Shahram,
=A0
The idea is the TTL check is an approximation of the sanity of the pac= ket. When authentication is enabled this check is redundant in my view and = hence the check is not required.
=A0
Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:02 PM, Shahram Davari <= span dir=3D"ltr"><davari@broadcom.com> wrote:
Hi Greg,
= =A0
Do you know th= e reason why TTL=3D255 check is not required for BFD with Authentication?
= =A0
Thanks,=
Shahram=

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Greg Mirsky
Sent: Tuesday, February 09, 2010 1:37 PM
To: Vishwas Manra= l
Cc: Kireeti Kompella; rtg-bfd@ietf.org; rahul@juniper.net=20

Subject: Re: BFD LSP Ping

Dear All,
I've found this thread is the closest to a ques= tion of my own and since I couldn't find any conclusion decided to add = $.02
As Vishwas have mentioned, BFD MPLS draft requires single hop UDP p= ort 3784 when BFD control packets are sent over MPLS LSP in IP/UDP encapsul= ation. But it requires set IP TTL of BFD packet to 1 while BFD single hop d= ocument in Section 5 requires TTL =3D=3D 255 if Authentication not in use. = BFD packet must be discarded if received TTL /=3D 255. If Authentication be= ing used, still, TTL =3D=3D 255 required, but "check TTL" eased t= o "may drop if TTL /=3D 255".

Should BFD MPLS text be changed to sync with BFD single hop in regard t= o setting TTL value?

Regards,
Greg

On Wed, Oct 28, 2009 at 9:58 AM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:
Hi,

I noticed= a basic issue with BFD LSP ping with a a TTL processing in a
Uniform Mo= del LSP.

The draft states that:


=A0 The BFD control packet sent by th= e ingress LSR MUST be a UDP packet
=A0 with a well known destination por= t 3784 [BFD-IP] and a source port
=A0 assigned by the sender as per the = procedures in [BFD-IP].

A single hop session verifies the TTL is 255. However the TTL in theIP header is changed at the Egress before the IP header handling
becaus= e we are using hte uniform model. I think the easiest and the
best way f= or this would be to use Multihop sessions in both
directions.

Do let me know if I am missing something?

Thanks,=
Vishwas

=



--000e0cd70d3ef646e7047f34fd92-- From mach@huawei.com Tue Feb 9 22:55:53 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C712C3A75C5 for ; Tue, 9 Feb 2010 22:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYsBumVskahN for ; Tue, 9 Feb 2010 22:55:50 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9110C3A7679 for ; Tue, 9 Feb 2010 22:55:50 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXM00JJO5YWT5@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Wed, 10 Feb 2010 14:56:56 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXM00IV05YVW2@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Wed, 10 Feb 2010 14:56:56 +0800 (CST) Date: Wed, 10 Feb 2010 14:56:55 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> To: Vishwas Manral Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> Cc: rtg-bfd@ietf.org, So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 06:55:53 -0000 Hi Vishwas, Thanks for you valuable comments! Please see inline... -------------------------------------------------- From: "Vishwas Manral" Sent: Tuesday, February 09, 2010 9:38 PM To: "Mach Chen" Cc: Subject: Re: Questions on BFD for MPLS LSP > Hi Mach, > > I think there is value in the draft for clamping forward and backward > direction of an LSP. Thanks! > > With BFD-MPLS a BFD session down means an FEC down and not an LSP down as > a > different BFD session is established per FEC, do we want to change this > rule > instead. Your draft seems to have a BFD session per LSP and not per FEC. We just relax the "rule", means except for "one BFD session per FEC", we could have a BFD session per LSP or per a group of LSPs(e.g., a pair of LSPs, one for each direction). One BFD session per LSP(s) is very useful for bidirectional LSP(e.g., GMPLS, MPLS-TP). > Further comments below: > > 1. BFD-MPLS assumes that detection of failure is only in the forward > direction. We are making a change in the assumption, so we must specify > the > same in the draft. This is particularly useful for GMPLS signalled LSP's > which can be bidirectional (like MPLS-TP etc). OK, will clarify it in the next revision. And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP. > > 2. One thing I think we can add is that at the ingress BFD needs to be > started in the passive mode. This is because packet send starts happening > if > the BFD session is added but is in default (active mode even though the > BFD > session at the other end is not established yet) With the extension defined in the draft, a BFD session will not be established before the echo reply received, and if the echo the echo reply received, the session at the other end should have been already established. > > 3. It is not clear what needs to be done in case of BFD failure when > unidirectional LSP's are there. Failure in one direction will lead to > failure in the other which may not be the desired behavior of > unidirectional > LSP's. If you want each of the two unidirectional LSPs to be operated separately, two seperate BFD sessions should be provisioned, just as is in current BFD-MPLS. If you provision a single BFD session for a pair unidirectional LSPs, that means you want the two LSPs to be operated as a single entity. So when one direction failed, no matter what the other direction is OK or not, it should switch to the protection path. We will add some text to clarify this in the next revision. > > 4. You talk about Optical networks, what/ how are the FEC's in the case of > Optical networks defined? Although the word "Optical" is mentioned in the draft, actually this draft is mainly about packet switching network. Maybe we should remove the word to avoid confusion. > > 5. You mention > "For each direction of a LSP, a separate BFD session is required > to be established." > > However BFD-MPLS allows the return packet to be MPLS encapsulated. This > however is a choice of the receiver and this point could be made clearer. OK. > > 6. I think for bidirectional LSP there is no ingress or egress there is > signalling initiator. Agree. > > 7. I think point 3 section 3 needs to be further clarified. When we do not > want an association between forward and reverse direction LSP's we should > not use these extensions. As switchover in this case will happen as a > unit. OK, will clarify it in the next revision. > > 8. The FEC for the forward and backward direction of the LSP will be > different. As a different BFD session is established per FEC (I would have > prefered it was not) how do we map the forward and backward direction > FEC's. In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims that are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txt for forward and backward direction FECs mapping. In short, the specific FEC (or the FEC selection policy) of the reply path is explicitly specified in the echo request message. PS: RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying an LSP as the return path of an echo reply. > > > 9. Also as the extension is for MPLs LSP encapsulated reply, we need to > mention the port number used for BFD is restricted to single hop. OK. > > 10. What happens when the ingress supports this extension and egress does > not and vice versa. This draft is based on the RPS mechanisms, in RPS draft, it defines a new reply mode: "Reply via specified return path". So when a node receive an echo request with reply mode set to "Reply via specified return path" and it does not know it, an echo reply with the return code set to "Malformed echo request" should be sent back to the sender. This error prcessing is defined in the RPS draft. And of cause, when this happen, the BFD session will not be estalished, we will add some text to clarify this in the next revision. > > 11. Let us not use the word backward but instead use the words reverse for > LSP's. OK. > > 12. How do we make sure of the case of larger IP address, especially > because > there are multiple addresses configured on a device. We could simply use the Router ID for comparison. But I have to think over about it. Thanks again for your valuable comments and suggesions! Best regards, Mach > > Thanks, > Vishwas > On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: > >> Hi Vishwas, >> >> How are you doing? >> >> Remember that you promised to read and comment my draft, and I'm still >> looking forward to receive your comments and suggestions. >> >> Here are the pointers of the draft and relevant sildes: >> >> Slides: >> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >> Draft: >> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >> >> >> Best regards, >> Mach >> >> -------------------------------------------------- >> From: "Mach Chen" >> Sent: Thursday, November 19, 2009 8:51 AM >> To: "Vishwas Manral" >> Cc: "Sunil C Gutlapalli" ; "So Ning" < >> ning.so@verizonbusiness.com>; >> >> Subject: Re: Questions on BFD for MPLS LSP >> >> Hi Vishwas, >>> >>> Looking forward to receive you comments! >>> >>> Thanks, >>> Mach >>> >>> -------------------------------------------------- >>> From: "Vishwas Manral" >>> Sent: Wednesday, November 18, 2009 1:59 AM >>> To: "Mach Chen" >>> Cc: "Sunil C Gutlapalli" ; ; >>> "So >>> Ning" >>> Subject: Re: Questions on BFD for MPLS LSP >>> >>> Hi Mach, >>>> >>>> Though I have not yet read through the draft, it seems that the draft >>>> could be of interest. LEt me read the draft and get back to you with >>>> comments. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>>> >>>>> Hi Sunil, >>>>> >>>>> Regarding to your questions, especially for the question 2 and 3, we >>>>> also >>>>> had the same doubts couple months ago. >>>>> >>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows >>>>> routing and the return path is "randomly" detetermined by the egress >>>>> LSR, >>>>> the failures in return path may lead to false positives. >>>>> >>>>> In addition to that, for bidirectional LSP or a pair of unidirectional >>>>> LSP, >>>>> there will be two separate BFD sessions( one for each direction) >>>>> established, and these two BFD sessions have no any inherent >>>>> relationship, >>>>> it will result in not double the BFD sessions over the LSP, but >>>>> failing >>>>> to >>>>> perform protection and switching when the bidirectional LSP or the >>>>> pair >>>>> of >>>>> undirectional LSPs are desired to operated as a single entity. >>>>> >>>>> We submitted a draft that is intended to reslove these >>>>> issues/limitation. >>>>> This draft was just presented at MPLS WG, Hiroshima. >>>>> >>>>> >>>>> Any comments and sugguestions are appreciated! >>>>> >>>>> >>>>> PS: >>>>> >>>>> The links: >>>>> >>>>> Slides: >>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>> >>>>> Draft: >>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>> >>>>> >>>>> Best regards, >>>>> Mach >>>>> >>>>> -------------------------------------------------- >>>>> From: "Sunil C Gutlapalli" >>>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>>> To: >>>>> Subject: Questions on BFD for MPLS LSP >>>>> >>>>> Hi >>>>>> >>>>>> >>>>>> >>>>>> I have some question on BFD for MPLS LSP's >>>>>> >>>>>> >>>>>> >>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>>> Bi-directional failure detection. If we have an LSP from Ingress to >>>>>> Egress, >>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop session >>>>>> port) >>>>>> from ingress to egress. Control packets from Egress to ingress are >>>>>> sent >>>>>> to >>>>>> UDP port 4784 (multi hop session port). So does the session is single >>>>>> hop >>>>>> session or multi hop session? What is the session behavior in ingress >>>>>> and >>>>>> egress? >>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path >>>>>> from >>>>>> egress to ingress is path2, control packets takes different paths, if >>>>>> path2 >>>>>> fails then BFD session goes down. But LSP path is still up. How this >>>>>> case >>>>>> will be handled? >>>>>> 3. If we have LSP from Ingress to egress and another LSP from egress >>>>>> to >>>>>> ingress, do we need to create two BFD sessions or one session? >>>>>> >>>>>> If both LSP's take same path, then link failure causes both LSP's >>>>>> down, >>>>>> but >>>>>> if they take different paths, one link failure causes both LSP's >>>>>> down. >>>>>> >>>>>> >>>>>> >>>>>> Sunil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> > From vishwas.ietf@gmail.com Wed Feb 10 04:58:02 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779CD3A72D3 for ; Wed, 10 Feb 2010 04:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3Rm548sDOIp for ; Wed, 10 Feb 2010 04:58:00 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 1A58B3A754D for ; Wed, 10 Feb 2010 04:58:00 -0800 (PST) Received: by yxe4 with SMTP id 4so1312625yxe.31 for ; Wed, 10 Feb 2010 04:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DOV3rtLqYvjBzfRXWHeJaMiPYJbeHkIJ5EQU4Pna5sM=; b=LejZ3JnejDnVoZA+h2Ii2MIhRIsOXTAESJV7WkQJ+E/XAvhugDndbczHIZZN8F24F+ NbmF3Axq2f452erSmNzXBZGxT+BOrZL+n/5QhYZhLxyNeT/J6XbWWCO5bY2QblJKttO6 zpja04lVEi/sTDwBPJ9+yV8Yc2xSIMomB1Iu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ioomnOMkxeTGo6Zu8uokyDilHokxbEx2ZVTu+cRQJ3CzsnQuf5cGDi+PQFBVBpLs2X +uRmgi99ltC1WliMcGXS21jTw7BQwm7QVO0d5ooQXsiCMq0lL/JjkHPCJQEJnFmxagYc CChoJe+Mcx+FIiy5mlCHbhvSkoQXtU67dJdYU= MIME-Version: 1.0 Received: by 10.150.170.9 with SMTP id s9mr2282660ybe.198.1265806745967; Wed, 10 Feb 2010 04:59:05 -0800 (PST) In-Reply-To: References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> Date: Wed, 10 Feb 2010 04:59:05 -0800 Message-ID: <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> Subject: Re: Questions on BFD for MPLS LSP From: Vishwas Manral To: Mach Chen Content-Type: multipart/alternative; boundary=000e0cd48dd672a6b0047f3e99d6 Cc: rtg-bfd@ietf.org, So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:58:02 -0000 --000e0cd48dd672a6b0047f3e99d6 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach, With BFD-MPLS a BFD session down means an FEC down and not an LSP down as a > different BFD session is established per FEC, do we want to change this > rule > instead. Your draft seems to have a BFD session per LSP and not per FEC. > > We just relax the "rule", means except for "one BFD session per FEC", we > could have a BFD session per LSP or per a group of LSPs(e.g., a pair of > LSPs, one for each direction). One BFD session per LSP(s) is very useful for > bidirectional LSP(e.g., GMPLS, MPLS-TP). I think this should be the first and the most important extension to the draft. Further comments below: >> >> 1. BFD-MPLS assumes that detection of failure is only in the forward >> direction. We are making a change in the assumption, so we must specify >> the >> same in the draft. This is particularly useful for GMPLS signalled LSP's >> which can be bidirectional (like MPLS-TP etc). >> > > OK, will clarify it in the next revision. > > And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP. This is one of the main changes to draft of making the detection from unidirectional to bidirectional and should be clarified. > >> 2. One thing I think we can add is that at the ingress BFD needs to be >> started in the passive mode. This is because packet send starts happening >> if >> the BFD session is added but is in default (active mode even though the >> BFD >> session at the other end is not established yet) >> > > With the extension defined in the draft, a BFD session will not be > established before the echo reply received, and if the echo the echo reply > received, the session at the other end should have been already established. > > Am not sure, may be you can clarify this in the draft. 3. It is not clear what needs to be done in case of BFD failure when unidirectional LSP's are there. Failure in one direction will lead to failure in the other which may not be the desired behavior of unidirectional LSP's. > > If you want each of the two unidirectional LSPs to be operated separately, > two seperate BFD sessions should be provisioned, just as is in current > BFD-MPLS. > > If you provision a single BFD session for a pair unidirectional LSPs, that > means you want the two LSPs to be operated as a single entity. So when one > direction failed, no matter what the other direction is OK or not, it should > switch to the protection path. > > We will add some text to clarify this in the next revision. Your explanation is correct. This is the reason this is an optional extension, however this reason has not been mentioned about why the extension is optional. > > > >> 4. You talk about Optical networks, what/ how are the FEC's in the case of >> Optical networks defined? >> > > Although the word "Optical" is mentioned in the draft, actually this draft > is mainly about packet switching network. Maybe we should remove the word to > avoid confusion. > > I agree you should just remove Optical etc. The term has been loosly used in the draft. > > >> 5. You mention >> "For each direction of a LSP, a separate BFD session is required >> to be established." >> >> However BFD-MPLS allows the return packet to be MPLS encapsulated. This >> however is a choice of the receiver and this point could be made clearer. >> > > OK. > > > >> 6. I think for bidirectional LSP there is no ingress or egress there is >> signalling initiator. >> > > Agree. > > > >> 7. I think point 3 section 3 needs to be further clarified. When we do not >> want an association between forward and reverse direction LSP's we should >> not use these extensions. As switchover in this case will happen as a >> unit. >> > > OK, will clarify it in the next revision. > > > >> 8. The FEC for the forward and backward direction of the LSP will be >> different. As a different BFD session is established per FEC (I would have >> prefered it was not) how do we map the forward and backward direction >> FEC's. >> > > In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims > that are defined in > http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor forward and backward direction FECs mapping. In short, the specific FEC > (or the FEC selection policy) of the reply path is explicitly specified in > the echo request message. > > PS: > RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying an > LSP as the return path of an echo reply. > Ok need to have a look at these extensions. > >> >> 10. What happens when the ingress supports this extension and egress does >> not and vice versa. >> > This draft is based on the RPS mechanisms, in RPS draft, it defines a new > reply mode: "Reply via specified return path". So when a node receive an > echo request with reply mode set to "Reply via specified return path" and it > does not know it, an echo reply with the return code set to "Malformed echo > request" should be sent back to the sender. This error prcessing is defined > in the RPS draft. > > And of cause, when this happen, the BFD session will not be estalished, we > will add some text to clarify this in the next revision. > > Great!!!. > > >> 12. How do we make sure of the case of larger IP address, especially >> because >> there are multiple addresses configured on a device. >> > > We could simply use the Router ID for comparison. But I have to think over > about it. > > Yes this sounds correct. > Thanks again for your valuable comments and suggesions! > > Best regards, > Mach > > Thanks, Vishwas > >> Thanks, >> Vishwas >> On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: >> >> Hi Vishwas, >>> >>> How are you doing? >>> >>> Remember that you promised to read and comment my draft, and I'm still >>> looking forward to receive your comments and suggestions. >>> >>> Here are the pointers of the draft and relevant sildes: >>> >>> Slides: >>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>> Draft: >>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>> >>> >>> Best regards, >>> Mach >>> >>> -------------------------------------------------- >>> From: "Mach Chen" >>> Sent: Thursday, November 19, 2009 8:51 AM >>> To: "Vishwas Manral" >>> Cc: "Sunil C Gutlapalli" ; "So Ning" < >>> ning.so@verizonbusiness.com>; >>> >>> Subject: Re: Questions on BFD for MPLS LSP >>> >>> Hi Vishwas, >>> >>>> >>>> Looking forward to receive you comments! >>>> >>>> Thanks, >>>> Mach >>>> >>>> -------------------------------------------------- >>>> From: "Vishwas Manral" >>>> Sent: Wednesday, November 18, 2009 1:59 AM >>>> To: "Mach Chen" >>>> Cc: "Sunil C Gutlapalli" ; ; >>>> "So >>>> Ning" >>>> Subject: Re: Questions on BFD for MPLS LSP >>>> >>>> Hi Mach, >>>> >>>>> >>>>> Though I have not yet read through the draft, it seems that the draft >>>>> could be of interest. LEt me read the draft and get back to you with >>>>> comments. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>>>> >>>>> Hi Sunil, >>>>>> >>>>>> Regarding to your questions, especially for the question 2 and 3, we >>>>>> also >>>>>> had the same doubts couple months ago. >>>>>> >>>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows >>>>>> routing and the return path is "randomly" detetermined by the egress >>>>>> LSR, >>>>>> the failures in return path may lead to false positives. >>>>>> >>>>>> In addition to that, for bidirectional LSP or a pair of unidirectional >>>>>> LSP, >>>>>> there will be two separate BFD sessions( one for each direction) >>>>>> established, and these two BFD sessions have no any inherent >>>>>> relationship, >>>>>> it will result in not double the BFD sessions over the LSP, but >>>>>> failing >>>>>> to >>>>>> perform protection and switching when the bidirectional LSP or the >>>>>> pair >>>>>> of >>>>>> undirectional LSPs are desired to operated as a single entity. >>>>>> >>>>>> We submitted a draft that is intended to reslove these >>>>>> issues/limitation. >>>>>> This draft was just presented at MPLS WG, Hiroshima. >>>>>> >>>>>> >>>>>> Any comments and sugguestions are appreciated! >>>>>> >>>>>> >>>>>> PS: >>>>>> >>>>>> The links: >>>>>> >>>>>> Slides: >>>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>>> >>>>>> Draft: >>>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Mach >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Sunil C Gutlapalli" >>>>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>>>> To: >>>>>> Subject: Questions on BFD for MPLS LSP >>>>>> >>>>>> Hi >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have some question on BFD for MPLS LSP's >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>>>> Bi-directional failure detection. If we have an LSP from Ingress to >>>>>>> Egress, >>>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop session >>>>>>> port) >>>>>>> from ingress to egress. Control packets from Egress to ingress are >>>>>>> sent >>>>>>> to >>>>>>> UDP port 4784 (multi hop session port). So does the session is single >>>>>>> hop >>>>>>> session or multi hop session? What is the session behavior in ingress >>>>>>> and >>>>>>> egress? >>>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path >>>>>>> from >>>>>>> egress to ingress is path2, control packets takes different paths, if >>>>>>> path2 >>>>>>> fails then BFD session goes down. But LSP path is still up. How this >>>>>>> case >>>>>>> will be handled? >>>>>>> 3. If we have LSP from Ingress to egress and another LSP from egress >>>>>>> to >>>>>>> ingress, do we need to create two BFD sessions or one session? >>>>>>> >>>>>>> If both LSP's take same path, then link failure causes both LSP's >>>>>>> down, >>>>>>> but >>>>>>> if they take different paths, one link failure causes both LSP's >>>>>>> down. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sunil >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >> --000e0cd48dd672a6b0047f3e99d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mach,

With BFD-MPLS a BFD session down means an FEC down and no= t an LSP down as a
different BFD session is established per FEC, do we w= ant to change this rule
instead. Your draft seems to have a BFD session = per LSP and not per FEC.

We just relax the "rule", means except for "one BF= D session per FEC", we could have a BFD session per LSP or per a group= of LSPs(e.g., a pair of LSPs, one for each direction). One BFD session per= LSP(s) is very useful for bidirectional LSP(e.g., GMPLS, MPLS-TP).
I think this should be the first and the most important extension to t= he draft.

Further comments below:

1= . BFD-MPLS assumes that detection of failure is only in the forward
dire= ction. We are making a change in the assumption, so we must specify the
same in the draft. This is particularly useful for GMPLS signalled LSP'= s
which can be bidirectional (like MPLS-TP etc).

OK, will clarify it in the next revision.

And agree that this is = particularly useful for GMPLS LSP and MPLS-TP LSP.
This is one of the main changes to draft of making the detection from = unidirectional to bidirectional and should be clarified.

2. One thing I think we can = add is that at the ingress BFD needs to be
started in the passive mode. = This is because packet send starts happening if
the BFD session is added but is in default (active mode even though the BFD=
session at the other end is not established yet)

With the extension defined in the draft, a BFD session will not be esta= blished before the echo reply received, and if the echo the echo reply rece= ived, the session at the other end should have been already established.
Am not sure, may be you can clarify this in the draft.

3. It is not clear what needs to be done in case of BFD failure wh= en
unidirectional LSP's are there. Failure in one direction will lea= d to
failure in the other which may not be the desired behavior of unidi= rectional
LSP's.

If you want each of the two = unidirectional LSPs to be operated separately, two seperate BFD sessions sh= ould be provisioned, just as is in current BFD-MPLS.

If you provision a single BFD session for a pair unidirectional LSPs, t= hat means you want the two LSPs to be operated as a single entity. So when = one direction failed, no matter what the other direction is OK or not, it s= hould switch to the protection path.

We will add some text to clarify this in the next revision.
Your explanation is correct. This is the reason this is an optional ex= tension, however this reason has not been mentioned about why the extension= is optional.
=A0



4. You talk about Optical ne= tworks, what/ how are the FEC's in the case of
Optical networks defi= ned?

Although the word "Optical" is mentioned i= n the draft, actually this draft is mainly about packet switching network. = Maybe we should remove the word to avoid confusion.=20

I agree you should just remove Optical etc. The term has been loosly u= sed in the draft.


5. You mention
"For = each direction of a LSP, a separate BFD session is required
=A0 =A0 =A0 = to be established."

However BFD-MPLS allows the return packet to be MPLS encapsulated. This=
however is a choice of the receiver and this point could be made cleare= r.

OK.=20



6. I think for bidirectional= LSP there is no ingress or egress there is
signalling initiator.

Agree.=20



7. I think point 3 section 3= needs to be further clarified. When we do not
want an association betwe= en forward and reverse direction LSP's we should
not use these extensions. As switchover in this case will happen as a unit.=

OK, will clarify it in the next revision.=20



8. The FEC for the forward a= nd backward direction of the LSP will be
different. As a different BFD s= ession is established per FEC (I would have
prefered it was not) how do we map the forward and backward direction FEC&#= 39;s.

In the draft, it uses the RPS(Return Path S= pecified) LSP Ping mechansims that are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp= -ping-01.txt for forward and backward direction FECs mapping. In short,= the specific FEC (or the FEC selection policy) of the reply path is explic= itly specified in the echo request message.

PS:
RPS Ping defines extensions to LSP Ping [RFC4379] that allows sp= ecifying an LSP as the return path of an echo reply.
Ok need to have a look at these extensions.


10. What happens when th= e ingress supports this extension and egress does
not and vice versa.
This draft is based on the RPS mechanisms, in RPS draft,= it defines a new reply mode: "Reply via specified return path". = So when a node receive an echo request with reply mode set to "Reply v= ia specified return path" and it does not know it, an echo reply with = the return code set to "Malformed echo request" should be sent ba= ck to the sender. This error prcessing is defined in the RPS draft.

And of cause, when this happen, the BFD session will not be estalished,= we will add some text to clarify this in the next revision.=20

Great!!!.
=A0

12. How do we make sure of t= he case of larger IP address, especially because
there are multiple addr= esses configured on a device.

We could simply use the Router ID for comparison. Bu= t I have to think over about it.

Yes this sounds correct.
=A0
Thanks again for your valuable c= omments and suggesions!

Best regards,
Mac= h=20
=A0
Thanks,
Vishwas
=A0

Thanks,
Vishwas
On Tue= , Feb 9, 2010 at 2:13 AM, Mach Chen <mach@huawei.com> wrote:

Hi Vishwas,

How are you d= oing?

Remember that you promised to read and comment my draft, and I= 'm still
looking forward to receive your comments and suggestions.

Here are t= he pointers of the draft and relevant sildes:

Slides:
http:/= /tools.ietf.org/agenda/76/slides/mpls-2.ppt
Draft:
http://tools.ietf.org/html?draft=3Ddraft= -chen-mpls-bfd-enhancement-00


Best regards,
Mach

-= -------------------------------------------------
From: "Mach Chen" <mach@huawei.com>
Sent: Thursday, November 19, 2009 8:= 51 AM
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
Cc: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>; "So Ning" &= lt;
nin= g.so@verizonbusiness.com>; <rtg-bfd@ietf.org>

Subject: Re: Questions on BFD for MPLS LSP

Hi Vishwas,

Looking forward to receive y= ou comments!

Thanks,
Mach

--------------------------------= ------------------
From: "Vishwas Manral" <vishwas.ietf@gmail.com>
Sent: Wednesday, No= vember 18, 2009 1:59 AM
To: "Mach Chen" <mach@huawei.com>
Cc: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>; <rtg-bfd@ietf.org>; "So
= Ning" <ning.so@verizonbusiness.com>
Subject: Re: Questions on BFD for MPLS LSP

Hi Mach,

Though I have not yet read t= hrough the draft, it seems that the draft
could be of interest. LEt me r= ead the draft and get back to you with
comments.

Thanks,
Vishwas

On Tue, Nov 17, 2009 at 1:06 AM,= Mach Chen <mach@hu= awei.com> wrote:

Hi Sunil,

Regarding to yo= ur questions, especially for the question 2 and 3, =A0we
also
had the= same doubts couple months ago.

Since the reverse direction of a "BFD for MPLS LSPs" sesssion= follows
routing and the return path is "randomly" detetermine= d by the egress
LSR,
the failures in return path may lead to false po= sitives.

In addition to that, for bidirectional LSP or a pair of unidirectional<= br>LSP,
there will be two separate BFD sessions( one for each direction)=
established, and these two BFD sessions have no any inherent
relatio= nship,
it will result in not double the BFD sessions over the LSP, but failing
= to
perform protection and switching when the bidirectional LSP or the pa= ir
of
undirectional LSPs are desired to operated as a single entity.<= br>
We submitted a draft that is intended to reslove these
issues/limita= tion.
This draft was just presented at MPLS WG, Hiroshima.


An= y comments and sugguestions are appreciated!


PS:

The link= s:

Slides:
http://tools.ietf.org/agenda/76/slides/mpls-2.ppt
Draft:
http://tools.ietf.org/html?draft= =3Ddraft-chen-mpls-bfd-enhancement-00


Best regards,
Mach

--------------------------------------= ------------
From: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>
S= ent: Tuesday, November 17, 2009 6:59 AM
To: <rtg-bfd@ietf.= org>
Subject: Questions on BFD for MPLS LSP

Hi



I have some question= on BFD for MPLS LSP's



1. MPLS LSP's are uni-directi= onal and BFD sessions are for
Bi-directional failure detection. If we have an LSP from Ingress to
Egre= ss,
BFD control packets are sent to UDP port 3784 (BFD single hop sessio= n
port)
from ingress to egress. Control packets from Egress to ingres= s are sent
to
UDP port 4784 (multi hop session port). So does the session is single=
hop
session or multi hop session? What is the session behavior in in= gress
and
egress?
2. If LSP takes path1 from ingress to egress and= the shortest path from
egress to ingress is path2, control packets takes different paths, if
pa= th2
fails then BFD session goes down. But LSP path is still up. How this=
case
will be handled?
3. If we have LSP from Ingress to egress an= d another LSP from egress to
ingress, do we need to create two BFD sessions or one session?

If bo= th LSP's take same path, then link failure causes both LSP's down,<= br>but
if they take different paths, one link failure causes both LSP= 9;s down.



Sunil










--000e0cd48dd672a6b0047f3e99d6-- From davari@broadcom.com Wed Feb 10 12:37:22 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA2628C28A for ; Wed, 10 Feb 2010 12:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTZVDUsMy-rA for ; Wed, 10 Feb 2010 12:37:20 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 26ED028C269 for ; Wed, 10 Feb 2010 12:37:20 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 10 Feb 2010 12:38:21 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 10 Feb 2010 12:38:21 -0800 From: "Shahram Davari" To: "Vishwas Manral" , "Mach Chen" Date: Wed, 10 Feb 2010 12:38:20 -0800 Subject: RE: Questions on BFD for MPLS LSP Thread-Topic: Questions on BFD for MPLS LSP Thread-Index: AcqqUN+Y0ggSalaNRTyOGLSNmHhVFAAP+9Zg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68167E4885F@SJEXCHCCR02.corp.ad.broadcom.com> References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> In-Reply-To: <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 676DC6B720S22938086-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD68167E4885FSJEXCHCCR02co_ Cc: "rtg-bfd@ietf.org" , So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:37:22 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E4885FSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I support extending BFD to monitor only LSP regardless of the FEC. This is = very useful for MPLS and MPLS-TP protection switching. Regards, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Vishwas Manral Sent: Wednesday, February 10, 2010 4:59 AM To: Mach Chen Cc: rtg-bfd@ietf.org; So Ning Subject: Re: Questions on BFD for MPLS LSP Hi Mach, With BFD-MPLS a BFD session down means an FEC down and not an LSP down as a different BFD session is established per FEC, do we want to change this rul= e instead. Your draft seems to have a BFD session per LSP and not per FEC. We just relax the "rule", means except for "one BFD session per FEC", we co= uld have a BFD session per LSP or per a group of LSPs(e.g., a pair of LSPs,= one for each direction). One BFD session per LSP(s) is very useful for bid= irectional LSP(e.g., GMPLS, MPLS-TP). I think this should be the first and the most important extension to the dr= aft. Further comments below: 1. BFD-MPLS assumes that detection of failure is only in the forward direction. We are making a change in the assumption, so we must specify the same in the draft. This is particularly useful for GMPLS signalled LSP's which can be bidirectional (like MPLS-TP etc). OK, will clarify it in the next revision. And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP. This is one of the main changes to draft of making the detection from unidi= rectional to bidirectional and should be clarified. 2. One thing I think we can add is that at the ingress BFD needs to be started in the passive mode. This is because packet send starts happening i= f the BFD session is added but is in default (active mode even though the BFD session at the other end is not established yet) With the extension defined in the draft, a BFD session will not be establis= hed before the echo reply received, and if the echo the echo reply received= , the session at the other end should have been already established. Am not sure, may be you can clarify this in the draft. 3. It is not clear what needs to be done in case of BFD failure when unidirectional LSP's are there. Failure in one direction will lead to failure in the other which may not be the desired behavior of unidirectiona= l LSP's. If you want each of the two unidirectional LSPs to be operated separately, = two seperate BFD sessions should be provisioned, just as is in current BFD-= MPLS. If you provision a single BFD session for a pair unidirectional LSPs, that = means you want the two LSPs to be operated as a single entity. So when one = direction failed, no matter what the other direction is OK or not, it shoul= d switch to the protection path. We will add some text to clarify this in the next revision. Your explanation is correct. This is the reason this is an optional extensi= on, however this reason has not been mentioned about why the extension is o= ptional. 4. You talk about Optical networks, what/ how are the FEC's in the case of Optical networks defined? Although the word "Optical" is mentioned in the draft, actually this draft = is mainly about packet switching network. Maybe we should remove the word t= o avoid confusion. I agree you should just remove Optical etc. The term has been loosly used i= n the draft. 5. You mention "For each direction of a LSP, a separate BFD session is required to be established." However BFD-MPLS allows the return packet to be MPLS encapsulated. This however is a choice of the receiver and this point could be made clearer. OK. 6. I think for bidirectional LSP there is no ingress or egress there is signalling initiator. Agree. 7. I think point 3 section 3 needs to be further clarified. When we do not want an association between forward and reverse direction LSP's we should not use these extensions. As switchover in this case will happen as a unit. OK, will clarify it in the next revision. 8. The FEC for the forward and backward direction of the LSP will be different. As a different BFD session is established per FEC (I would have prefered it was not) how do we map the forward and backward direction FEC's= . In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims th= at are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-spec= ified-lsp-ping-01.txt for forward and backward direction FECs mapping. In s= hort, the specific FEC (or the FEC selection policy) of the reply path is e= xplicitly specified in the echo request message. PS: RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying an= LSP as the return path of an echo reply. Ok need to have a look at these extensions. 10. What happens when the ingress supports this extension and egress does not and vice versa. This draft is based on the RPS mechanisms, in RPS draft, it defines a new r= eply mode: "Reply via specified return path". So when a node receive an ech= o request with reply mode set to "Reply via specified return path" and it d= oes not know it, an echo reply with the return code set to "Malformed echo = request" should be sent back to the sender. This error prcessing is defined= in the RPS draft. And of cause, when this happen, the BFD session will not be estalished, we = will add some text to clarify this in the next revision. Great!!!. 12. How do we make sure of the case of larger IP address, especially becaus= e there are multiple addresses configured on a device. We could simply use the Router ID for comparison. But I have to think over = about it. Yes this sounds correct. Thanks again for your valuable comments and suggesions! Best regards, Mach Thanks, Vishwas Thanks, Vishwas On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen > wrote: Hi Vishwas, How are you doing? Remember that you promised to read and comment my draft, and I'm still looking forward to receive your comments and suggestions. Here are the pointers of the draft and relevant sildes: Slides: http://tools.ietf.org/agenda/76/slides/mpls-2.ppt Draft: http://tools.ietf.org/html?draft=3Ddraft-chen-mpls-bfd-enhancement-00 Best regards, Mach -------------------------------------------------- From: "Mach Chen" > Sent: Thursday, November 19, 2009 8:51 AM To: "Vishwas Manral" = > Cc: "Sunil C Gutlapalli" >; "So Ning" < ning.so@verizonbusiness.com>; > Subject: Re: Questions on BFD for MPLS LSP Hi Vishwas, Looking forward to receive you comments! Thanks, Mach -------------------------------------------------- From: "Vishwas Manral" > Sent: Wednesday, November 18, 2009 1:59 AM To: "Mach Chen" > Cc: "Sunil C Gutlapalli" >; >; "So Ning" > Subject: Re: Questions on BFD for MPLS LSP Hi Mach, Though I have not yet read through the draft, it seems that the draft could be of interest. LEt me read the draft and get back to you with comments. Thanks, Vishwas On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen > wrote: Hi Sunil, Regarding to your questions, especially for the question 2 and 3, we also had the same doubts couple months ago. Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows routing and the return path is "randomly" detetermined by the egress LSR, the failures in return path may lead to false positives. In addition to that, for bidirectional LSP or a pair of unidirectional LSP, there will be two separate BFD sessions( one for each direction) established, and these two BFD sessions have no any inherent relationship, it will result in not double the BFD sessions over the LSP, but failing to perform protection and switching when the bidirectional LSP or the pair of undirectional LSPs are desired to operated as a single entity. We submitted a draft that is intended to reslove these issues/limitation. This draft was just presented at MPLS WG, Hiroshima. Any comments and sugguestions are appreciated! PS: The links: Slides: http://tools.ietf.org/agenda/76/slides/mpls-2.ppt Draft: http://tools.ietf.org/html?draft=3Ddraft-chen-mpls-bfd-enhancement-00 Best regards, Mach -------------------------------------------------- From: "Sunil C Gutlapalli" > Sent: Tuesday, November 17, 2009 6:59 AM To: > Subject: Questions on BFD for MPLS LSP Hi I have some question on BFD for MPLS LSP's 1. MPLS LSP's are uni-directional and BFD sessions are for Bi-directional failure detection. If we have an LSP from Ingress to Egress, BFD control packets are sent to UDP port 3784 (BFD single hop session port) from ingress to egress. Control packets from Egress to ingress are sent to UDP port 4784 (multi hop session port). So does the session is single hop session or multi hop session? What is the session behavior in ingress and egress? 2. If LSP takes path1 from ingress to egress and the shortest path from egress to ingress is path2, control packets takes different paths, if path2 fails then BFD session goes down. But LSP path is still up. How this case will be handled? 3. If we have LSP from Ingress to egress and another LSP from egress to ingress, do we need to create two BFD sessions or one session? If both LSP's take same path, then link failure causes both LSP's down, but if they take different paths, one link failure causes both LSP's down. Sunil --_000_2C2F1EBA8050E74EA81502D5740B4BD68167E4885FSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,
 
I=20 support extending BFD to monitor only LSP regardless of the FEC. This is ve= ry=20 useful for MPLS and MPLS-TP protection switching.
 
Regards,
Shahram

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas=20 Manral
Sent: Wednesday, February 10, 2010 4:59 AM
To: M= ach=20 Chen
Cc: rtg-bfd@ietf.org; So Ning
Subject: Re: Questio= ns on=20 BFD for MPLS LSP

Hi Mach,

With BFD-MPLS a BFD session down means an FEC down and no= t an=20 LSP down as a
different BFD session is established per FEC, do we want= to=20 change this rule
instead. Your draft seems to have a BFD session per L= SP=20 and not per FEC.

We just relax the "rule", means except for = "one=20 BFD session per FEC", we could have a BFD session per LSP or per a group = of=20 LSPs(e.g., a pair of LSPs, one for each direction). One BFD session per L= SP(s)=20 is very useful for bidirectional LSP(e.g., GMPLS, MPLS-TP).
I think this should be the first and the most important extension to t= he=20 draft.

Further=20 comments below:

1. BFD-MPLS assumes that detection of failure is= only=20 in the forward
direction. We are making a change in the assumption, = so we=20 must specify the
same in the draft. This is particularly useful for = GMPLS=20 signalled LSP's
which can be bidirectional (like MPLS-TP=20 etc).

OK, will clarify it in the next=20 revision.

And agree that this is particularly useful for GMPLS LSP= and=20 MPLS-TP LSP.
This is one of the main changes to draft of making the detection from= =20 unidirectional to bidirectional and should be clarified.

2.=20 One thing I think we can add is that at the ingress BFD needs to=20 be
started in the passive mode. This is because packet send starts=20 happening if
the BFD session is added but is in default (active mode= even=20 though the BFD
session at the other end is not established=20 yet)

With the extension defined in the draft, a= BFD=20 session will not be established before the echo reply received, and if th= e=20 echo the echo reply received, the session at the other end should have be= en=20 already established.
Am not sure, may be you can clarify this in the draft.

3. It is not clear what needs to be done in case of BFD failure=20 when
unidirectional LSP's are there. Failure in one direction will lead= =20 to
failure in the other which may not be the desired behavior of=20 unidirectional
LSP's.

If=20 you want each of the two unidirectional LSPs to be operated separately, t= wo=20 seperate BFD sessions should be provisioned, just as is in current=20 BFD-MPLS.

If you provision a single BFD session for a pair=20 unidirectional LSPs, that means you want the two LSPs to be operated as a= =20 single entity. So when one direction failed, no matter what the other=20 direction is OK or not, it should switch to the protection path.

W= e=20 will add some text to clarify this in the next revision.
Your explanation is correct. This is the reason this is an optional=20 extension, however this reason has not been mentioned about why the extensi= on is=20 optional.
 



4.=20 You talk about Optical networks, what/ how are the FEC's in the case=20 of
Optical networks defined?

Although the = word=20 "Optical" is mentioned in the draft, actually this draft is mainly about= =20 packet switching network. Maybe we should remove the word to avoid confus= ion.=20

I agree you should just remove Optical etc. The term has been loosly u= sed=20 in the draft.


5.=20 You mention
"For each direction of a LSP, a separate BFD session is= =20 required
      to be established."

However BFD= -MPLS=20 allows the return packet to be MPLS encapsulated. This
however is a= =20 choice of the receiver and this point could be made=20 clearer.

OK.=20



6.=20 I think for bidirectional LSP there is no ingress or egress there=20 is
signalling initiator.

Agree.=20



7.=20 I think point 3 section 3 needs to be further clarified. When we do=20 not
want an association between forward and reverse direction LSP's = we=20 should
not use these extensions. As switchover in this case will hap= pen=20 as a unit.

OK, will clarify it in the next re= vision.=20



8.=20 The FEC for the forward and backward direction of the LSP will=20 be
different. As a different BFD session is established per FEC (I w= ould=20 have
prefered it was not) how do we map the forward and backward=20 direction FEC's.

In the draft, it uses the=20 RPS(Return Path Specified) LSP Ping mechansims that are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-spec= ified-lsp-ping-01.txt=20 for forward and backward direction FECs mapping. In short, the specific F= EC=20 (or the FEC selection policy) of the reply path is explicitly specified i= n the=20 echo request message.

PS:
RPS Ping defines extensions to LSP Pi= ng=20 [RFC4379] that allows specifying an LSP as the return path of an echo rep= ly.=20
Ok need to have a look at these extensions.


10.=20 What happens when the ingress supports this extension and egress doesnot=20 and vice versa.
This draft is based on the RPS=20 mechanisms, in RPS draft, it defines a new reply mode: "Reply via specifi= ed=20 return path". So when a node receive an echo request with reply mode set = to=20 "Reply via specified return path" and it does not know it, an echo reply = with=20 the return code set to "Malformed echo request" should be sent back to th= e=20 sender. This error prcessing is defined in the RPS draft.

And of c= ause,=20 when this happen, the BFD session will not be estalished, we will add som= e=20 text to clarify this in the next revision.=20

Great!!!.
 

12.=20 How do we make sure of the case of larger IP address, especially=20 because
there are multiple addresses configured on a=20 device.

We could simply use the Router ID for=20 comparison. But I have to think over about it.

Yes this sounds correct.
 
Thanks=20 again for your valuable comments and suggesions!

Best regards,
= Mach=20
 
Thanks,
Vishwas
 

Thanks,
Vishwas
On=20 Tue, Feb 9, 2010 at 2:13 AM, Mach Chen <mach@huawei.com> wrote:

Hi=20 Vishwas,

How are you doing?

Remember that you promised = to=20 read and comment my draft, and I'm still
looking forward to receiv= e=20 your comments and suggestions.

Here are the pointers of the dr= aft=20 and relevant sildes:

Slides:
http://tools.ietf.org/agenda/76/slides/mpls-2.ppt=
Draft:
http://tools.ietf.org/html?draft=3Ddraft-chen-mpls-bf= d-enhancement-00


Best=20 regards,
Mach

---------------------------------------------= -----
From:=20 "Mach Chen" <mach@huawei.com>
Sent: Thursday, November 1= 9, 2009=20 8:51 AM
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
Cc: "Sunil C Gutlap= alli"=20 <sunilc@ipinfusion.com>; "So Ning" <
ning.so@verizonbusiness.com>; <rtg-bfd@ietf.org>

Subject: Re: Question= s on=20 BFD for MPLS LSP

Hi Vishwas,

Looking=20 forward to receive you=20 comments!

Thanks,
Mach

---------------------------= -----------------------
From:=20 "Vishwas Manral" <vishwas.ietf@gmail.com>
Sent: Wednesday,= =20 November 18, 2009 1:59 AM
To: "Mach Chen" <mach@huawei.com>
Cc: "Sunil C Gutlapalli"= <sunilc@ipinfusion.com>; <rtg-bfd@ietf.org>;=20 "So
Ning" <ning.so@verizonbusiness.com>
Subject: Re:= =20 Questions on BFD for MPLS LSP

Hi Mach,

Though=20 I have not yet read through the draft, it seems that the=20 draft
could be of interest. LEt me read the draft and get back= to=20 you with
comments.

Thanks,
Vishwas

On Tue, No= v 17,=20 2009 at 1:06 AM, Mach Chen <mach@huawei.com> wrote:

Hi=20 Sunil,

Regarding to your questions, especially for the=20 question 2 and 3,  we
also
had the same doubts coupl= e=20 months ago.

Since the reverse direction of a "BFD for MP= LS=20 LSPs" sesssion follows
routing and the return path is "rando= mly"=20 detetermined by the egress
LSR,
the failures in return pa= th=20 may lead to false positives.

In addition to that, for=20 bidirectional LSP or a pair of unidirectional
LSP,
there = will=20 be two separate BFD sessions( one for each=20 direction)
established, and these two BFD sessions have no a= ny=20 inherent
relationship,
it will result in not double the B= FD=20 sessions over the LSP, but failing
to
perform protection = and=20 switching when the bidirectional LSP or the=20 pair
of
undirectional LSPs are desired to operated as a s= ingle=20 entity.

We submitted a draft that is intended to reslove= =20 these
issues/limitation.
This draft was just presented at= MPLS=20 WG, Hiroshima.


Any comments and sugguestions are=20 appreciated!


PS:

The links:

Slides:http://tools.ietf.org/agenda/76/slides/mpls-2.p= pt

Draft:
http://tools.ietf.org/html?draft=3Ddraft-chen-m= pls-bfd-enhancement-00


Best=20 regards,
Mach

---------------------------------------= -----------
From:=20 "Sunil C Gutlapalli" <sunilc@ipinfusion.com>
Sent: Tuesday,= =20 November 17, 2009 6:59 AM
To: <rtg-bfd@ietf.org>
Subject: Questions = on BFD=20 for MPLS LSP

Hi



I=20 have some question on BFD for MPLS LSP's



1. MP= LS=20 LSP's are uni-directional and BFD sessions are=20 for
Bi-directional failure detection. If we have an LSP fr= om=20 Ingress to
Egress,
BFD control packets are sent to UDP = port=20 3784 (BFD single hop session
port)
from ingress to egre= ss.=20 Control packets from Egress to ingress are sent
to
UDP = port=20 4784 (multi hop session port). So does the session is=20 single
hop
session or multi hop session? What is the se= ssion=20 behavior in ingress
and
egress?
2. If LSP takes path= 1=20 from ingress to egress and the shortest path from
egress t= o=20 ingress is path2, control packets takes different paths,=20 if
path2
fails then BFD session goes down. But LSP path= is=20 still up. How this
case
will be handled?
3. If we ha= ve=20 LSP from Ingress to egress and another LSP from egress=20 to
ingress, do we need to create two BFD sessions or one=20 session?

If both LSP's take same path, then link failu= re=20 causes both LSP's down,
but
if they take different path= s,=20 one link failure causes both LSP's=20 down.



Sunil










--_000_2C2F1EBA8050E74EA81502D5740B4BD68167E4885FSJEXCHCCR02co_-- From vishwas.ietf@gmail.com Wed Feb 10 13:58:58 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592373A6CD5 for ; Wed, 10 Feb 2010 13:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8y0o1D32DiA for ; Wed, 10 Feb 2010 13:58:56 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id C59543A6919 for ; Wed, 10 Feb 2010 13:58:55 -0800 (PST) Received: by ywh1 with SMTP id 1so578582ywh.18 for ; Wed, 10 Feb 2010 13:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Yq/gKzY+HpD6Ab1THVc8BdrqNA0IHVOJTKwl339b0Ck=; b=L0WIlsqq+wTng/P1DWYyiFNUEY3iumm0jOY0j954Ni2xcGnY7LKa3pXSbXI5klUAQf T+ZIYoqbZLauANRa8k7yuJ31fbtXIFlbZFyCYWbs/xhBRpkJo4k8k2/cKSm0/3ezbsTJ 9DLLQCDxqjRzFvj2d7BHJaTAcSUPZ27txk+G0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OteszPavnqCYlRHrdhwfyNUKwEFOnM6dWvlCNolUuAtsDIP+vP+0Fxh2bOZoUpf6tZ /9z4v0s57sFPyiTZT0G85cMG7/UjYTQhL+/Ajw+SaV0UV0AJIXDDTnbo/rBgLqs3uGEB /G/OGfQAubOA2w/AfUnP6E9HHpXa05frHaezw= MIME-Version: 1.0 Received: by 10.151.88.17 with SMTP id q17mr3364242ybl.193.1265839199080; Wed, 10 Feb 2010 13:59:59 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68167E4885F@SJEXCHCCR02.corp.ad.broadcom.com> References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E4885F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 10 Feb 2010 13:59:59 -0800 Message-ID: <77ead0ec1002101359k7c2a3191o547bf9489c839355@mail.gmail.com> Subject: Re: Questions on BFD for MPLS LSP From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=000e0cd7040acdd337047f462792 Cc: "rtg-bfd@ietf.org" , So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:58:58 -0000 --000e0cd7040acdd337047f462792 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, It also helps with scalability of BFD sessions. Thanks, Vishwas On Wed, Feb 10, 2010 at 12:38 PM, Shahram Davari wrote: > Hi, > > I support extending BFD to monitor only LSP regardless of the FEC. This is > very useful for MPLS and MPLS-TP protection switching. > > Regards, > Shahram > > ------------------------------ > *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On > Behalf Of *Vishwas Manral > *Sent:* Wednesday, February 10, 2010 4:59 AM > *To:* Mach Chen > *Cc:* rtg-bfd@ietf.org; So Ning > > *Subject:* Re: Questions on BFD for MPLS LSP > > Hi Mach, > > With BFD-MPLS a BFD session down means an FEC down and not an LSP down as >> a >> different BFD session is established per FEC, do we want to change this >> rule >> instead. Your draft seems to have a BFD session per LSP and not per FEC. >> >> We just relax the "rule", means except for "one BFD session per FEC", we >> could have a BFD session per LSP or per a group of LSPs(e.g., a pair of >> LSPs, one for each direction). One BFD session per LSP(s) is very useful for >> bidirectional LSP(e.g., GMPLS, MPLS-TP). > > I think this should be the first and the most important extension to the > draft. > > Further comments below: >>> >>> 1. BFD-MPLS assumes that detection of failure is only in the forward >>> direction. We are making a change in the assumption, so we must specify >>> the >>> same in the draft. This is particularly useful for GMPLS signalled LSP's >>> which can be bidirectional (like MPLS-TP etc). >>> >> >> OK, will clarify it in the next revision. >> >> And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP. > > This is one of the main changes to draft of making the detection from > unidirectional to bidirectional and should be clarified. > >> >>> 2. One thing I think we can add is that at the ingress BFD needs to be >>> started in the passive mode. This is because packet send starts happening >>> if >>> the BFD session is added but is in default (active mode even though the >>> BFD >>> session at the other end is not established yet) >>> >> >> With the extension defined in the draft, a BFD session will not be >> established before the echo reply received, and if the echo the echo reply >> received, the session at the other end should have been already established. >> >> > Am not sure, may be you can clarify this in the draft. > > 3. It is not clear what needs to be done in case of BFD failure when > unidirectional LSP's are there. Failure in one direction will lead to > failure in the other which may not be the desired behavior of > unidirectional > LSP's. > >> >> If you want each of the two unidirectional LSPs to be operated separately, >> two seperate BFD sessions should be provisioned, just as is in current >> BFD-MPLS. >> >> If you provision a single BFD session for a pair unidirectional LSPs, that >> means you want the two LSPs to be operated as a single entity. So when one >> direction failed, no matter what the other direction is OK or not, it should >> switch to the protection path. >> >> We will add some text to clarify this in the next revision. > > Your explanation is correct. This is the reason this is an optional > extension, however this reason has not been mentioned about why the > extension is optional. > > >> >> >> >>> 4. You talk about Optical networks, what/ how are the FEC's in the case >>> of >>> Optical networks defined? >>> >> >> Although the word "Optical" is mentioned in the draft, actually this draft >> is mainly about packet switching network. Maybe we should remove the word to >> avoid confusion. >> >> I agree you should just remove Optical etc. The term has been loosly used > in the draft. > >> >> >>> 5. You mention >>> "For each direction of a LSP, a separate BFD session is required >>> to be established." >>> >>> However BFD-MPLS allows the return packet to be MPLS encapsulated. This >>> however is a choice of the receiver and this point could be made clearer. >>> >> >> OK. >> >> >> >>> 6. I think for bidirectional LSP there is no ingress or egress there is >>> signalling initiator. >>> >> >> Agree. >> >> >> >>> 7. I think point 3 section 3 needs to be further clarified. When we do >>> not >>> want an association between forward and reverse direction LSP's we should >>> not use these extensions. As switchover in this case will happen as a >>> unit. >>> >> >> OK, will clarify it in the next revision. >> >> >> >>> 8. The FEC for the forward and backward direction of the LSP will be >>> different. As a different BFD session is established per FEC (I would >>> have >>> prefered it was not) how do we map the forward and backward direction >>> FEC's. >>> >> >> In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims >> that are defined in >> http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor forward and backward direction FECs mapping. In short, the specific FEC >> (or the FEC selection policy) of the reply path is explicitly specified in >> the echo request message. >> >> PS: >> RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying >> an LSP as the return path of an echo reply. >> > Ok need to have a look at these extensions. > >> >>> >>> 10. What happens when the ingress supports this extension and egress does >>> not and vice versa. >>> >> This draft is based on the RPS mechanisms, in RPS draft, it defines a new >> reply mode: "Reply via specified return path". So when a node receive an >> echo request with reply mode set to "Reply via specified return path" and it >> does not know it, an echo reply with the return code set to "Malformed echo >> request" should be sent back to the sender. This error prcessing is defined >> in the RPS draft. >> >> And of cause, when this happen, the BFD session will not be estalished, we >> will add some text to clarify this in the next revision. >> >> Great!!!. >> > > >> >>> 12. How do we make sure of the case of larger IP address, especially >>> because >>> there are multiple addresses configured on a device. >>> >> >> We could simply use the Router ID for comparison. But I have to think over >> about it. >> >> Yes this sounds correct. > > >> Thanks again for your valuable comments and suggesions! >> >> Best regards, >> Mach >> >> > Thanks, > Vishwas > > >> >>> Thanks, >>> Vishwas >>> On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: >>> >>> Hi Vishwas, >>>> >>>> How are you doing? >>>> >>>> Remember that you promised to read and comment my draft, and I'm still >>>> looking forward to receive your comments and suggestions. >>>> >>>> Here are the pointers of the draft and relevant sildes: >>>> >>>> Slides: >>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>> Draft: >>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>> >>>> >>>> Best regards, >>>> Mach >>>> >>>> -------------------------------------------------- >>>> From: "Mach Chen" >>>> Sent: Thursday, November 19, 2009 8:51 AM >>>> To: "Vishwas Manral" >>>> Cc: "Sunil C Gutlapalli" ; "So Ning" < >>>> ning.so@verizonbusiness.com>; >>>> >>>> Subject: Re: Questions on BFD for MPLS LSP >>>> >>>> Hi Vishwas, >>>> >>>>> >>>>> Looking forward to receive you comments! >>>>> >>>>> Thanks, >>>>> Mach >>>>> >>>>> -------------------------------------------------- >>>>> From: "Vishwas Manral" >>>>> Sent: Wednesday, November 18, 2009 1:59 AM >>>>> To: "Mach Chen" >>>>> Cc: "Sunil C Gutlapalli" ; ; >>>>> "So >>>>> Ning" >>>>> Subject: Re: Questions on BFD for MPLS LSP >>>>> >>>>> Hi Mach, >>>>> >>>>>> >>>>>> Though I have not yet read through the draft, it seems that the draft >>>>>> could be of interest. LEt me read the draft and get back to you with >>>>>> comments. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> >>>>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>>>>> >>>>>> Hi Sunil, >>>>>>> >>>>>>> Regarding to your questions, especially for the question 2 and 3, we >>>>>>> also >>>>>>> had the same doubts couple months ago. >>>>>>> >>>>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows >>>>>>> routing and the return path is "randomly" detetermined by the egress >>>>>>> LSR, >>>>>>> the failures in return path may lead to false positives. >>>>>>> >>>>>>> In addition to that, for bidirectional LSP or a pair of >>>>>>> unidirectional >>>>>>> LSP, >>>>>>> there will be two separate BFD sessions( one for each direction) >>>>>>> established, and these two BFD sessions have no any inherent >>>>>>> relationship, >>>>>>> it will result in not double the BFD sessions over the LSP, but >>>>>>> failing >>>>>>> to >>>>>>> perform protection and switching when the bidirectional LSP or the >>>>>>> pair >>>>>>> of >>>>>>> undirectional LSPs are desired to operated as a single entity. >>>>>>> >>>>>>> We submitted a draft that is intended to reslove these >>>>>>> issues/limitation. >>>>>>> This draft was just presented at MPLS WG, Hiroshima. >>>>>>> >>>>>>> >>>>>>> Any comments and sugguestions are appreciated! >>>>>>> >>>>>>> >>>>>>> PS: >>>>>>> >>>>>>> The links: >>>>>>> >>>>>>> Slides: >>>>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>>>> >>>>>>> Draft: >>>>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Mach >>>>>>> >>>>>>> -------------------------------------------------- >>>>>>> From: "Sunil C Gutlapalli" >>>>>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>>>>> To: >>>>>>> Subject: Questions on BFD for MPLS LSP >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have some question on BFD for MPLS LSP's >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>>>>> Bi-directional failure detection. If we have an LSP from Ingress to >>>>>>>> Egress, >>>>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop >>>>>>>> session >>>>>>>> port) >>>>>>>> from ingress to egress. Control packets from Egress to ingress are >>>>>>>> sent >>>>>>>> to >>>>>>>> UDP port 4784 (multi hop session port). So does the session is >>>>>>>> single >>>>>>>> hop >>>>>>>> session or multi hop session? What is the session behavior in >>>>>>>> ingress >>>>>>>> and >>>>>>>> egress? >>>>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path >>>>>>>> from >>>>>>>> egress to ingress is path2, control packets takes different paths, >>>>>>>> if >>>>>>>> path2 >>>>>>>> fails then BFD session goes down. But LSP path is still up. How this >>>>>>>> case >>>>>>>> will be handled? >>>>>>>> 3. If we have LSP from Ingress to egress and another LSP from egress >>>>>>>> to >>>>>>>> ingress, do we need to create two BFD sessions or one session? >>>>>>>> >>>>>>>> If both LSP's take same path, then link failure causes both LSP's >>>>>>>> down, >>>>>>>> but >>>>>>>> if they take different paths, one link failure causes both LSP's >>>>>>>> down. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sunil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>> > --000e0cd7040acdd337047f462792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
It also helps with scalability of BFD sessions.
=A0
Thanks,
Vishwas
On Wed, Feb 10, 2010 at 12:38 PM, Shahram Davari= <davari@broadc= om.com> wrote:
Hi,
= =A0
I support exte= nding BFD to monitor only LSP regardless of the FEC. This is very useful fo= r MPLS and MPLS-TP protection switching.
= =A0
Regards,
Sh= ahram

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie= tf.org] On Behalf Of Vishwas Manral
Sent: Wednesday, February 10, 2010 4:59 AM
To: Mach ChenCc: rtg-bfd@= ietf.org; So Ning=20

Subject: Re: Questions on BFD for MPLS LSP
=

Hi Mach,

With BFD-MPLS a BFD session down means an FEC down and not an LSP down= as a
different BFD session is established per FEC, do we want to change= this rule
instead. Your draft seems to have a BFD session per LSP and n= ot per FEC.

We just relax the "rule", means except for "one BF= D session per FEC", we could have a BFD session per LSP or per a group= of LSPs(e.g., a pair of LSPs, one for each direction). One BFD session per= LSP(s) is very useful for bidirectional LSP(e.g., GMPLS, MPLS-TP).
I think this should be the first and the most important extension to t= he draft.

Further comments below:

1= . BFD-MPLS assumes that detection of failure is only in the forward
dire= ction. We are making a change in the assumption, so we must specify the
same in the draft. This is particularly useful for GMPLS signalled LSP'= s
which can be bidirectional (like MPLS-TP etc).

OK, will clarify it in the next revision.

And agree that this is = particularly useful for GMPLS LSP and MPLS-TP LSP.
This is one of the main changes to draft of making the detection from = unidirectional to bidirectional and should be clarified.

2. One thing I think we can = add is that at the ingress BFD needs to be
started in the passive mode. = This is because packet send starts happening if
the BFD session is added but is in default (active mode even though the BFD=
session at the other end is not established yet)

With the extension defined in the draft, a BFD session will not be esta= blished before the echo reply received, and if the echo the echo reply rece= ived, the session at the other end should have been already established.
Am not sure, may be you can clarify this in the draft.

3. It is not clear what needs to be done in case of BFD failure wh= en
unidirectional LSP's are there. Failure in one direction will lea= d to
failure in the other which may not be the desired behavior of unidi= rectional
LSP's.

If you want each of the two = unidirectional LSPs to be operated separately, two seperate BFD sessions sh= ould be provisioned, just as is in current BFD-MPLS.

If you provision a single BFD session for a pair unidirectional LSPs, t= hat means you want the two LSPs to be operated as a single entity. So when = one direction failed, no matter what the other direction is OK or not, it s= hould switch to the protection path.

We will add some text to clarify this in the next revision.
Your explanation is correct. This is the reason this is an optional ex= tension, however this reason has not been mentioned about why the extension= is optional.
=A0



4. You talk about Optical ne= tworks, what/ how are the FEC's in the case of
Optical networks defi= ned?

Although the word "Optical" is mentioned i= n the draft, actually this draft is mainly about packet switching network. = Maybe we should remove the word to avoid confusion.=20

I agree you should just remove Optical etc. The term has been loosly u= sed in the draft.


5. You mention
"For = each direction of a LSP, a separate BFD session is required
=A0 =A0 =A0 = to be established."

However BFD-MPLS allows the return packet to be MPLS encapsulated. This=
however is a choice of the receiver and this point could be made cleare= r.

OK.=20



6. I think for bidirectional= LSP there is no ingress or egress there is
signalling initiator.

Agree.=20



7. I think point 3 section 3= needs to be further clarified. When we do not
want an association betwe= en forward and reverse direction LSP's we should
not use these extensions. As switchover in this case will happen as a unit.=

OK, will clarify it in the next revision.=20



8. The FEC for the forward a= nd backward direction of the LSP will be
different. As a different BFD s= ession is established per FEC (I would have
prefered it was not) how do we map the forward and backward direction FEC&#= 39;s.

In the draft, it uses the RPS(Return Path S= pecified) LSP Ping mechansims that are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp= -ping-01.txt for forward and backward direction FECs mapping. In short,= the specific FEC (or the FEC selection policy) of the reply path is explic= itly specified in the echo request message.

PS:
RPS Ping defines extensions to LSP Ping [RFC4379] that allows sp= ecifying an LSP as the return path of an echo reply.
Ok need to have a look at these extensions.


10. What happens when th= e ingress supports this extension and egress does
not and vice versa.
This draft is based on the RPS mechanisms, in RPS draft,= it defines a new reply mode: "Reply via specified return path". = So when a node receive an echo request with reply mode set to "Reply v= ia specified return path" and it does not know it, an echo reply with = the return code set to "Malformed echo request" should be sent ba= ck to the sender. This error prcessing is defined in the RPS draft.

And of cause, when this happen, the BFD session will not be estalished,= we will add some text to clarify this in the next revision.=20

Great!!!.
=A0

12. How do we make sure of t= he case of larger IP address, especially because
there are multiple addr= esses configured on a device.

We could simply use the Router ID for comparison. Bu= t I have to think over about it.

Yes this sounds correct.
=A0
Thanks again for your valuable c= omments and suggesions!

Best regards,
Mac= h=20
=A0
Thanks,
Vishwas
=A0

Thanks,
Vishwas
On Tue= , Feb 9, 2010 at 2:13 AM, Mach Chen <mach@huawei.com> wrote:

Hi Vishwas,

How are you d= oing?

Remember that you promised to read and comment my draft, and I= 'm still
looking forward to receive your comments and suggestions.

Here are t= he pointers of the draft and relevant sildes:

Slides:
http:/= /tools.ietf.org/agenda/76/slides/mpls-2.ppt
Draft:
http://tools.ietf.org/html?draft=3Ddraft= -chen-mpls-bfd-enhancement-00


Best regards,
Mach

-= -------------------------------------------------
From: "Mach Chen" <mach@huawei.com>
Sent: Thursday, November 19, 2009 8:= 51 AM
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
Cc: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>; "So Ning" &= lt;
nin= g.so@verizonbusiness.com>; <rtg-bfd@ietf.org>

Subject: Re: Questions on BFD for MPLS LSP

Hi Vishwas,

Looking forward to receive y= ou comments!

Thanks,
Mach

--------------------------------= ------------------
From: "Vishwas Manral" <vishwas.ietf@gmail.com>
Sent: Wednesday, No= vember 18, 2009 1:59 AM
To: "Mach Chen" <mach@huawei.com>
Cc: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>; <rtg-bfd@ietf.org>; "So
= Ning" <ning.so@verizonbusiness.com>
Subject: Re: Questions on BFD for MPLS LSP

Hi Mach,

Though I have not yet read t= hrough the draft, it seems that the draft
could be of interest. LEt me r= ead the draft and get back to you with
comments.

Thanks,
Vishwas

On Tue, Nov 17, 2009 at 1:06 AM,= Mach Chen <mach@hu= awei.com> wrote:

Hi Sunil,

Regarding to yo= ur questions, especially for the question 2 and 3, =A0we
also
had the= same doubts couple months ago.

Since the reverse direction of a "BFD for MPLS LSPs" sesssion= follows
routing and the return path is "randomly" detetermine= d by the egress
LSR,
the failures in return path may lead to false po= sitives.

In addition to that, for bidirectional LSP or a pair of unidirectional<= br>LSP,
there will be two separate BFD sessions( one for each direction)=
established, and these two BFD sessions have no any inherent
relatio= nship,
it will result in not double the BFD sessions over the LSP, but failing
= to
perform protection and switching when the bidirectional LSP or the pa= ir
of
undirectional LSPs are desired to operated as a single entity.<= br>
We submitted a draft that is intended to reslove these
issues/limita= tion.
This draft was just presented at MPLS WG, Hiroshima.


An= y comments and sugguestions are appreciated!


PS:

The link= s:

Slides:
http://tools.ietf.org/agenda/76/slides/mpls-2.ppt
Draft:
http://tools.ietf.org/html?draft= =3Ddraft-chen-mpls-bfd-enhancement-00


Best regards,
Mach

--------------------------------------= ------------
From: "Sunil C Gutlapalli" <sunilc@ipinfusion.com>
S= ent: Tuesday, November 17, 2009 6:59 AM
To: <rtg-bfd@ietf.= org>
Subject: Questions on BFD for MPLS LSP

Hi



I have some question= on BFD for MPLS LSP's



1. MPLS LSP's are uni-directi= onal and BFD sessions are for
Bi-directional failure detection. If we have an LSP from Ingress to
Egre= ss,
BFD control packets are sent to UDP port 3784 (BFD single hop sessio= n
port)
from ingress to egress. Control packets from Egress to ingres= s are sent
to
UDP port 4784 (multi hop session port). So does the session is single=
hop
session or multi hop session? What is the session behavior in in= gress
and
egress?
2. If LSP takes path1 from ingress to egress and= the shortest path from
egress to ingress is path2, control packets takes different paths, if
pa= th2
fails then BFD session goes down. But LSP path is still up. How this=
case
will be handled?
3. If we have LSP from Ingress to egress an= d another LSP from egress to
ingress, do we need to create two BFD sessions or one session?

If bo= th LSP's take same path, then link failure causes both LSP's down,<= br>but
if they take different paths, one link failure causes both LSP= 9;s down.



Sunil











--000e0cd7040acdd337047f462792-- From mach@huawei.com Wed Feb 10 17:04:42 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD3728B56A for ; Wed, 10 Feb 2010 17:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m22KZRczwg5F for ; Wed, 10 Feb 2010 17:04:41 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C36B23A77F2 for ; Wed, 10 Feb 2010 17:04:40 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXN0098XKDFBE@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 09:05:39 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN00FSBKDE1D@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 09:05:39 +0800 (CST) Date: Thu, 11 Feb 2010 09:05:38 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <77ead0ec1002101359k7c2a3191o547bf9489c839355@mail.gmail.com> To: Vishwas Manral , Shahram Davari Message-id: <927F249D0DA34787BE02E9B40B925CC6@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E4885F@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002101359k7c2a3191o547bf9489c839355@mail.gmail.com> Cc: rtg-bfd@ietf.org, So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 01:04:42 -0000 Hi Vishwas and Shahram, Yes, that's one of the purposes of this draft. Thanks for your comments! Best regards, Mach -------------------------------------------------- From: "Vishwas Manral" Sent: Thursday, February 11, 2010 5:59 AM To: "Shahram Davari" Cc: "Mach Chen" ; ; "So Ning" Subject: Re: Questions on BFD for MPLS LSP > Hi Shahram, > > It also helps with scalability of BFD sessions. > > Thanks, > Vishwas > On Wed, Feb 10, 2010 at 12:38 PM, Shahram Davari > wrote: > >> Hi, >> >> I support extending BFD to monitor only LSP regardless of the FEC. This >> is >> very useful for MPLS and MPLS-TP protection switching. >> >> Regards, >> Shahram >> >> ------------------------------ >> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >> Behalf Of *Vishwas Manral >> *Sent:* Wednesday, February 10, 2010 4:59 AM >> *To:* Mach Chen >> *Cc:* rtg-bfd@ietf.org; So Ning >> >> *Subject:* Re: Questions on BFD for MPLS LSP >> >> Hi Mach, >> >> With BFD-MPLS a BFD session down means an FEC down and not an LSP down >> as >>> a >>> different BFD session is established per FEC, do we want to change this >>> rule >>> instead. Your draft seems to have a BFD session per LSP and not per FEC. >>> >>> We just relax the "rule", means except for "one BFD session per FEC", we >>> could have a BFD session per LSP or per a group of LSPs(e.g., a pair of >>> LSPs, one for each direction). One BFD session per LSP(s) is very useful >>> for >>> bidirectional LSP(e.g., GMPLS, MPLS-TP). >> >> I think this should be the first and the most important extension to the >> draft. >> >> Further comments below: >>>> >>>> 1. BFD-MPLS assumes that detection of failure is only in the forward >>>> direction. We are making a change in the assumption, so we must specify >>>> the >>>> same in the draft. This is particularly useful for GMPLS signalled >>>> LSP's >>>> which can be bidirectional (like MPLS-TP etc). >>>> >>> >>> OK, will clarify it in the next revision. >>> >>> And agree that this is particularly useful for GMPLS LSP and MPLS-TP >>> LSP. >> >> This is one of the main changes to draft of making the detection from >> unidirectional to bidirectional and should be clarified. >> >>> >>>> 2. One thing I think we can add is that at the ingress BFD needs to be >>>> started in the passive mode. This is because packet send starts >>>> happening >>>> if >>>> the BFD session is added but is in default (active mode even though the >>>> BFD >>>> session at the other end is not established yet) >>>> >>> >>> With the extension defined in the draft, a BFD session will not be >>> established before the echo reply received, and if the echo the echo >>> reply >>> received, the session at the other end should have been already >>> established. >>> >>> >> Am not sure, may be you can clarify this in the draft. >> >> 3. It is not clear what needs to be done in case of BFD failure when >> unidirectional LSP's are there. Failure in one direction will lead to >> failure in the other which may not be the desired behavior of >> unidirectional >> LSP's. >> >>> >>> If you want each of the two unidirectional LSPs to be operated >>> separately, >>> two seperate BFD sessions should be provisioned, just as is in current >>> BFD-MPLS. >>> >>> If you provision a single BFD session for a pair unidirectional LSPs, >>> that >>> means you want the two LSPs to be operated as a single entity. So when >>> one >>> direction failed, no matter what the other direction is OK or not, it >>> should >>> switch to the protection path. >>> >>> We will add some text to clarify this in the next revision. >> >> Your explanation is correct. This is the reason this is an optional >> extension, however this reason has not been mentioned about why the >> extension is optional. >> >> >>> >>> >>> >>>> 4. You talk about Optical networks, what/ how are the FEC's in the case >>>> of >>>> Optical networks defined? >>>> >>> >>> Although the word "Optical" is mentioned in the draft, actually this >>> draft >>> is mainly about packet switching network. Maybe we should remove the >>> word to >>> avoid confusion. >>> >>> I agree you should just remove Optical etc. The term has been loosly >>> used >> in the draft. >> >>> >>> >>>> 5. You mention >>>> "For each direction of a LSP, a separate BFD session is required >>>> to be established." >>>> >>>> However BFD-MPLS allows the return packet to be MPLS encapsulated. This >>>> however is a choice of the receiver and this point could be made >>>> clearer. >>>> >>> >>> OK. >>> >>> >>> >>>> 6. I think for bidirectional LSP there is no ingress or egress there is >>>> signalling initiator. >>>> >>> >>> Agree. >>> >>> >>> >>>> 7. I think point 3 section 3 needs to be further clarified. When we do >>>> not >>>> want an association between forward and reverse direction LSP's we >>>> should >>>> not use these extensions. As switchover in this case will happen as a >>>> unit. >>>> >>> >>> OK, will clarify it in the next revision. >>> >>> >>> >>>> 8. The FEC for the forward and backward direction of the LSP will be >>>> different. As a different BFD session is established per FEC (I would >>>> have >>>> prefered it was not) how do we map the forward and backward direction >>>> FEC's. >>>> >>> >>> In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims >>> that are defined in >>> http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor >>> forward and backward direction FECs mapping. In short, the specific FEC >>> (or the FEC selection policy) of the reply path is explicitly specified >>> in >>> the echo request message. >>> >>> PS: >>> RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying >>> an LSP as the return path of an echo reply. >>> >> Ok need to have a look at these extensions. >> >>> >>>> >>>> 10. What happens when the ingress supports this extension and egress >>>> does >>>> not and vice versa. >>>> >>> This draft is based on the RPS mechanisms, in RPS draft, it defines a >>> new >>> reply mode: "Reply via specified return path". So when a node receive an >>> echo request with reply mode set to "Reply via specified return path" >>> and it >>> does not know it, an echo reply with the return code set to "Malformed >>> echo >>> request" should be sent back to the sender. This error prcessing is >>> defined >>> in the RPS draft. >>> >>> And of cause, when this happen, the BFD session will not be estalished, >>> we >>> will add some text to clarify this in the next revision. >>> >>> Great!!!. >>> >> >> >>> >>>> 12. How do we make sure of the case of larger IP address, especially >>>> because >>>> there are multiple addresses configured on a device. >>>> >>> >>> We could simply use the Router ID for comparison. But I have to think >>> over >>> about it. >>> >>> Yes this sounds correct. >> >> >>> Thanks again for your valuable comments and suggesions! >>> >>> Best regards, >>> Mach >>> >>> >> Thanks, >> Vishwas >> >> >>> >>>> Thanks, >>>> Vishwas >>>> On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: >>>> >>>> Hi Vishwas, >>>>> >>>>> How are you doing? >>>>> >>>>> Remember that you promised to read and comment my draft, and I'm still >>>>> looking forward to receive your comments and suggestions. >>>>> >>>>> Here are the pointers of the draft and relevant sildes: >>>>> >>>>> Slides: >>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>> Draft: >>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>> >>>>> >>>>> Best regards, >>>>> Mach >>>>> >>>>> -------------------------------------------------- >>>>> From: "Mach Chen" >>>>> Sent: Thursday, November 19, 2009 8:51 AM >>>>> To: "Vishwas Manral" >>>>> Cc: "Sunil C Gutlapalli" ; "So Ning" < >>>>> ning.so@verizonbusiness.com>; >>>>> >>>>> Subject: Re: Questions on BFD for MPLS LSP >>>>> >>>>> Hi Vishwas, >>>>> >>>>>> >>>>>> Looking forward to receive you comments! >>>>>> >>>>>> Thanks, >>>>>> Mach >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Vishwas Manral" >>>>>> Sent: Wednesday, November 18, 2009 1:59 AM >>>>>> To: "Mach Chen" >>>>>> Cc: "Sunil C Gutlapalli" ; ; >>>>>> "So >>>>>> Ning" >>>>>> Subject: Re: Questions on BFD for MPLS LSP >>>>>> >>>>>> Hi Mach, >>>>>> >>>>>>> >>>>>>> Though I have not yet read through the draft, it seems that the >>>>>>> draft >>>>>>> could be of interest. LEt me read the draft and get back to you with >>>>>>> comments. >>>>>>> >>>>>>> Thanks, >>>>>>> Vishwas >>>>>>> >>>>>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>>>>>> >>>>>>> Hi Sunil, >>>>>>>> >>>>>>>> Regarding to your questions, especially for the question 2 and 3, >>>>>>>> we >>>>>>>> also >>>>>>>> had the same doubts couple months ago. >>>>>>>> >>>>>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion >>>>>>>> follows >>>>>>>> routing and the return path is "randomly" detetermined by the >>>>>>>> egress >>>>>>>> LSR, >>>>>>>> the failures in return path may lead to false positives. >>>>>>>> >>>>>>>> In addition to that, for bidirectional LSP or a pair of >>>>>>>> unidirectional >>>>>>>> LSP, >>>>>>>> there will be two separate BFD sessions( one for each direction) >>>>>>>> established, and these two BFD sessions have no any inherent >>>>>>>> relationship, >>>>>>>> it will result in not double the BFD sessions over the LSP, but >>>>>>>> failing >>>>>>>> to >>>>>>>> perform protection and switching when the bidirectional LSP or the >>>>>>>> pair >>>>>>>> of >>>>>>>> undirectional LSPs are desired to operated as a single entity. >>>>>>>> >>>>>>>> We submitted a draft that is intended to reslove these >>>>>>>> issues/limitation. >>>>>>>> This draft was just presented at MPLS WG, Hiroshima. >>>>>>>> >>>>>>>> >>>>>>>> Any comments and sugguestions are appreciated! >>>>>>>> >>>>>>>> >>>>>>>> PS: >>>>>>>> >>>>>>>> The links: >>>>>>>> >>>>>>>> Slides: >>>>>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>>>>> >>>>>>>> Draft: >>>>>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Sunil C Gutlapalli" >>>>>>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>>>>>> To: >>>>>>>> Subject: Questions on BFD for MPLS LSP >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have some question on BFD for MPLS LSP's >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>>>>>> Bi-directional failure detection. If we have an LSP from Ingress >>>>>>>>> to >>>>>>>>> Egress, >>>>>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop >>>>>>>>> session >>>>>>>>> port) >>>>>>>>> from ingress to egress. Control packets from Egress to ingress are >>>>>>>>> sent >>>>>>>>> to >>>>>>>>> UDP port 4784 (multi hop session port). So does the session is >>>>>>>>> single >>>>>>>>> hop >>>>>>>>> session or multi hop session? What is the session behavior in >>>>>>>>> ingress >>>>>>>>> and >>>>>>>>> egress? >>>>>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path >>>>>>>>> from >>>>>>>>> egress to ingress is path2, control packets takes different paths, >>>>>>>>> if >>>>>>>>> path2 >>>>>>>>> fails then BFD session goes down. But LSP path is still up. How >>>>>>>>> this >>>>>>>>> case >>>>>>>>> will be handled? >>>>>>>>> 3. If we have LSP from Ingress to egress and another LSP from >>>>>>>>> egress >>>>>>>>> to >>>>>>>>> ingress, do we need to create two BFD sessions or one session? >>>>>>>>> >>>>>>>>> If both LSP's take same path, then link failure causes both LSP's >>>>>>>>> down, >>>>>>>>> but >>>>>>>>> if they take different paths, one link failure causes both LSP's >>>>>>>>> down. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sunil >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >> > From mach@huawei.com Wed Feb 10 17:22:10 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6BC28C108 for ; Wed, 10 Feb 2010 17:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO7oRnBMrMpN for ; Wed, 10 Feb 2010 17:22:08 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2707F28C0E8 for ; Wed, 10 Feb 2010 17:22:08 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXN009ECL6LBE@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 09:23:10 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN00F4AL6L1D@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 09:23:09 +0800 (CST) Date: Thu, 11 Feb 2010 09:23:09 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <77ead0ec1002101359k7c2a3191o547bf9489c839355@mail.gmail.com> To: Vishwas Manral , Shahram Davari Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD68167E4885F@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec1002101359k7c2a3191o547bf9489c839355@mail.gmail.com> Cc: rtg-bfd@ietf.org, So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 01:22:10 -0000 Hi Vishwas and Shahram, Yes, scalability is one of the purposes of this draft! Thanks for you comments! Best regards, Mach -------------------------------------------------- From: "Vishwas Manral" Sent: Thursday, February 11, 2010 5:59 AM To: "Shahram Davari" Cc: "Mach Chen" ; ; "So Ning" Subject: Re: Questions on BFD for MPLS LSP > Hi Shahram, > > It also helps with scalability of BFD sessions. > > Thanks, > Vishwas > On Wed, Feb 10, 2010 at 12:38 PM, Shahram Davari > wrote: > >> Hi, >> >> I support extending BFD to monitor only LSP regardless of the FEC. This >> is >> very useful for MPLS and MPLS-TP protection switching. >> >> Regards, >> Shahram >> >> ------------------------------ >> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] *On >> Behalf Of *Vishwas Manral >> *Sent:* Wednesday, February 10, 2010 4:59 AM >> *To:* Mach Chen >> *Cc:* rtg-bfd@ietf.org; So Ning >> >> *Subject:* Re: Questions on BFD for MPLS LSP >> >> Hi Mach, >> >> With BFD-MPLS a BFD session down means an FEC down and not an LSP down >> as >>> a >>> different BFD session is established per FEC, do we want to change this >>> rule >>> instead. Your draft seems to have a BFD session per LSP and not per FEC. >>> >>> We just relax the "rule", means except for "one BFD session per FEC", we >>> could have a BFD session per LSP or per a group of LSPs(e.g., a pair of >>> LSPs, one for each direction). One BFD session per LSP(s) is very useful >>> for >>> bidirectional LSP(e.g., GMPLS, MPLS-TP). >> >> I think this should be the first and the most important extension to the >> draft. >> >> Further comments below: >>>> >>>> 1. BFD-MPLS assumes that detection of failure is only in the forward >>>> direction. We are making a change in the assumption, so we must specify >>>> the >>>> same in the draft. This is particularly useful for GMPLS signalled >>>> LSP's >>>> which can be bidirectional (like MPLS-TP etc). >>>> >>> >>> OK, will clarify it in the next revision. >>> >>> And agree that this is particularly useful for GMPLS LSP and MPLS-TP >>> LSP. >> >> This is one of the main changes to draft of making the detection from >> unidirectional to bidirectional and should be clarified. >> >>> >>>> 2. One thing I think we can add is that at the ingress BFD needs to be >>>> started in the passive mode. This is because packet send starts >>>> happening >>>> if >>>> the BFD session is added but is in default (active mode even though the >>>> BFD >>>> session at the other end is not established yet) >>>> >>> >>> With the extension defined in the draft, a BFD session will not be >>> established before the echo reply received, and if the echo the echo >>> reply >>> received, the session at the other end should have been already >>> established. >>> >>> >> Am not sure, may be you can clarify this in the draft. >> >> 3. It is not clear what needs to be done in case of BFD failure when >> unidirectional LSP's are there. Failure in one direction will lead to >> failure in the other which may not be the desired behavior of >> unidirectional >> LSP's. >> >>> >>> If you want each of the two unidirectional LSPs to be operated >>> separately, >>> two seperate BFD sessions should be provisioned, just as is in current >>> BFD-MPLS. >>> >>> If you provision a single BFD session for a pair unidirectional LSPs, >>> that >>> means you want the two LSPs to be operated as a single entity. So when >>> one >>> direction failed, no matter what the other direction is OK or not, it >>> should >>> switch to the protection path. >>> >>> We will add some text to clarify this in the next revision. >> >> Your explanation is correct. This is the reason this is an optional >> extension, however this reason has not been mentioned about why the >> extension is optional. >> >> >>> >>> >>> >>>> 4. You talk about Optical networks, what/ how are the FEC's in the case >>>> of >>>> Optical networks defined? >>>> >>> >>> Although the word "Optical" is mentioned in the draft, actually this >>> draft >>> is mainly about packet switching network. Maybe we should remove the >>> word to >>> avoid confusion. >>> >>> I agree you should just remove Optical etc. The term has been loosly >>> used >> in the draft. >> >>> >>> >>>> 5. You mention >>>> "For each direction of a LSP, a separate BFD session is required >>>> to be established." >>>> >>>> However BFD-MPLS allows the return packet to be MPLS encapsulated. This >>>> however is a choice of the receiver and this point could be made >>>> clearer. >>>> >>> >>> OK. >>> >>> >>> >>>> 6. I think for bidirectional LSP there is no ingress or egress there is >>>> signalling initiator. >>>> >>> >>> Agree. >>> >>> >>> >>>> 7. I think point 3 section 3 needs to be further clarified. When we do >>>> not >>>> want an association between forward and reverse direction LSP's we >>>> should >>>> not use these extensions. As switchover in this case will happen as a >>>> unit. >>>> >>> >>> OK, will clarify it in the next revision. >>> >>> >>> >>>> 8. The FEC for the forward and backward direction of the LSP will be >>>> different. As a different BFD session is established per FEC (I would >>>> have >>>> prefered it was not) how do we map the forward and backward direction >>>> FEC's. >>>> >>> >>> In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims >>> that are defined in >>> http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor >>> forward and backward direction FECs mapping. In short, the specific FEC >>> (or the FEC selection policy) of the reply path is explicitly specified >>> in >>> the echo request message. >>> >>> PS: >>> RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying >>> an LSP as the return path of an echo reply. >>> >> Ok need to have a look at these extensions. >> >>> >>>> >>>> 10. What happens when the ingress supports this extension and egress >>>> does >>>> not and vice versa. >>>> >>> This draft is based on the RPS mechanisms, in RPS draft, it defines a >>> new >>> reply mode: "Reply via specified return path". So when a node receive an >>> echo request with reply mode set to "Reply via specified return path" >>> and it >>> does not know it, an echo reply with the return code set to "Malformed >>> echo >>> request" should be sent back to the sender. This error prcessing is >>> defined >>> in the RPS draft. >>> >>> And of cause, when this happen, the BFD session will not be estalished, >>> we >>> will add some text to clarify this in the next revision. >>> >>> Great!!!. >>> >> >> >>> >>>> 12. How do we make sure of the case of larger IP address, especially >>>> because >>>> there are multiple addresses configured on a device. >>>> >>> >>> We could simply use the Router ID for comparison. But I have to think >>> over >>> about it. >>> >>> Yes this sounds correct. >> >> >>> Thanks again for your valuable comments and suggesions! >>> >>> Best regards, >>> Mach >>> >>> >> Thanks, >> Vishwas >> >> >>> >>>> Thanks, >>>> Vishwas >>>> On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen wrote: >>>> >>>> Hi Vishwas, >>>>> >>>>> How are you doing? >>>>> >>>>> Remember that you promised to read and comment my draft, and I'm still >>>>> looking forward to receive your comments and suggestions. >>>>> >>>>> Here are the pointers of the draft and relevant sildes: >>>>> >>>>> Slides: >>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>> Draft: >>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>> >>>>> >>>>> Best regards, >>>>> Mach >>>>> >>>>> -------------------------------------------------- >>>>> From: "Mach Chen" >>>>> Sent: Thursday, November 19, 2009 8:51 AM >>>>> To: "Vishwas Manral" >>>>> Cc: "Sunil C Gutlapalli" ; "So Ning" < >>>>> ning.so@verizonbusiness.com>; >>>>> >>>>> Subject: Re: Questions on BFD for MPLS LSP >>>>> >>>>> Hi Vishwas, >>>>> >>>>>> >>>>>> Looking forward to receive you comments! >>>>>> >>>>>> Thanks, >>>>>> Mach >>>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Vishwas Manral" >>>>>> Sent: Wednesday, November 18, 2009 1:59 AM >>>>>> To: "Mach Chen" >>>>>> Cc: "Sunil C Gutlapalli" ; ; >>>>>> "So >>>>>> Ning" >>>>>> Subject: Re: Questions on BFD for MPLS LSP >>>>>> >>>>>> Hi Mach, >>>>>> >>>>>>> >>>>>>> Though I have not yet read through the draft, it seems that the >>>>>>> draft >>>>>>> could be of interest. LEt me read the draft and get back to you with >>>>>>> comments. >>>>>>> >>>>>>> Thanks, >>>>>>> Vishwas >>>>>>> >>>>>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen wrote: >>>>>>> >>>>>>> Hi Sunil, >>>>>>>> >>>>>>>> Regarding to your questions, especially for the question 2 and 3, >>>>>>>> we >>>>>>>> also >>>>>>>> had the same doubts couple months ago. >>>>>>>> >>>>>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion >>>>>>>> follows >>>>>>>> routing and the return path is "randomly" detetermined by the >>>>>>>> egress >>>>>>>> LSR, >>>>>>>> the failures in return path may lead to false positives. >>>>>>>> >>>>>>>> In addition to that, for bidirectional LSP or a pair of >>>>>>>> unidirectional >>>>>>>> LSP, >>>>>>>> there will be two separate BFD sessions( one for each direction) >>>>>>>> established, and these two BFD sessions have no any inherent >>>>>>>> relationship, >>>>>>>> it will result in not double the BFD sessions over the LSP, but >>>>>>>> failing >>>>>>>> to >>>>>>>> perform protection and switching when the bidirectional LSP or the >>>>>>>> pair >>>>>>>> of >>>>>>>> undirectional LSPs are desired to operated as a single entity. >>>>>>>> >>>>>>>> We submitted a draft that is intended to reslove these >>>>>>>> issues/limitation. >>>>>>>> This draft was just presented at MPLS WG, Hiroshima. >>>>>>>> >>>>>>>> >>>>>>>> Any comments and sugguestions are appreciated! >>>>>>>> >>>>>>>> >>>>>>>> PS: >>>>>>>> >>>>>>>> The links: >>>>>>>> >>>>>>>> Slides: >>>>>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt >>>>>>>> >>>>>>>> Draft: >>>>>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00 >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>> -------------------------------------------------- >>>>>>>> From: "Sunil C Gutlapalli" >>>>>>>> Sent: Tuesday, November 17, 2009 6:59 AM >>>>>>>> To: >>>>>>>> Subject: Questions on BFD for MPLS LSP >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have some question on BFD for MPLS LSP's >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for >>>>>>>>> Bi-directional failure detection. If we have an LSP from Ingress >>>>>>>>> to >>>>>>>>> Egress, >>>>>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop >>>>>>>>> session >>>>>>>>> port) >>>>>>>>> from ingress to egress. Control packets from Egress to ingress are >>>>>>>>> sent >>>>>>>>> to >>>>>>>>> UDP port 4784 (multi hop session port). So does the session is >>>>>>>>> single >>>>>>>>> hop >>>>>>>>> session or multi hop session? What is the session behavior in >>>>>>>>> ingress >>>>>>>>> and >>>>>>>>> egress? >>>>>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path >>>>>>>>> from >>>>>>>>> egress to ingress is path2, control packets takes different paths, >>>>>>>>> if >>>>>>>>> path2 >>>>>>>>> fails then BFD session goes down. But LSP path is still up. How >>>>>>>>> this >>>>>>>>> case >>>>>>>>> will be handled? >>>>>>>>> 3. If we have LSP from Ingress to egress and another LSP from >>>>>>>>> egress >>>>>>>>> to >>>>>>>>> ingress, do we need to create two BFD sessions or one session? >>>>>>>>> >>>>>>>>> If both LSP's take same path, then link failure causes both LSP's >>>>>>>>> down, >>>>>>>>> but >>>>>>>>> if they take different paths, one link failure causes both LSP's >>>>>>>>> down. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sunil >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >> > From mach@huawei.com Wed Feb 10 19:09:31 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394DB3A7505 for ; Wed, 10 Feb 2010 19:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7jngpK3jgPa for ; Wed, 10 Feb 2010 19:09:30 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2549A3A6868 for ; Wed, 10 Feb 2010 19:09:30 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXN00G12Q5GKO@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 11:10:29 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN008PIQ5G9S@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 11 Feb 2010 11:10:28 +0800 (CST) Date: Thu, 11 Feb 2010 11:10:28 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> To: Vishwas Manral Message-id: <3E49EF84487B4802B91724825C5A8906@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> <4A96A57F47E848C58B8B3F4E4B8CFD64@m55527c> <2F879080DFC1405CBEBF665C3E7C9C52@m55527c> <77ead0ec1002090538u677456e3n75b21d7359cd01b1@mail.gmail.com> <77ead0ec1002100459p2a49d309n494cda317e5fe45@mail.gmail.com> Cc: rtg-bfd@ietf.org, So Ning X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 03:09:31 -0000 Hi Vishwas, Thanks for your prompt response! >>> 2. One thing I think we can add is that at the ingress BFD needs to be >>> started in the passive mode. This is because packet send starts >>> happening >>> if >>> the BFD session is added but is in default (active mode even though the >>> BFD >>> session at the other end is not established yet) >>> >> >> With the extension defined in the draft, a BFD session will not be >> established before the echo reply received, and if the echo the echo >> reply >> received, the session at the other end should have been already >> established. >> >> > Am not sure, may be you can clarify this in the draft. Sorry for that, let me try to explain it again. A sucessful BFD session establishment is at least based on one exchange of echo request and echo reply. When the initiator received the echo reply and everything is OK, the BFD session is sucessfully established. So it could begin to send BFD packets onto the session. For the receiver, it may send BFD packets onto the session after sending the echo reply, if the echo reply could pass the validation checking of the initiator, there is no problem. But there is possibility that the echo reply failed to pass the validation checking, that means the reverse direction of BFD is not OK, but the receiver will not aware of it. So in order to relsove this issue, the receiver MUST wait to send the BFD packets until received the first BFD packet from the initiator. We will clarify this in the next revision. > > 3. It is not clear what needs to be done in case of BFD failure when > unidirectional LSP's are there. Failure in one direction will lead to > failure in the other which may not be the desired behavior of > unidirectional > LSP's. > >> >> If you want each of the two unidirectional LSPs to be operated >> separately, >> two seperate BFD sessions should be provisioned, just as is in current >> BFD-MPLS. >> >> If you provision a single BFD session for a pair unidirectional LSPs, >> that >> means you want the two LSPs to be operated as a single entity. So when >> one >> direction failed, no matter what the other direction is OK or not, it >> should >> switch to the protection path. >> >> We will add some text to clarify this in the next revision. > > Your explanation is correct. This is the reason this is an optional > extension, however this reason has not been mentioned about why the > extension is optional. I am not sure what's your mean about "why the extension is optional" here. I think, since this extension is of course not fit for all scenarios, the choice of which solution is used belongs to the operators. Based on their application scenarios, they should determine whether to use this extension. >> RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying >> an >> LSP as the return path of an echo reply. >> > Ok need to have a look at these extensions. Thanks, hope to receive your comments and suggestions about the RPS Ping draft! Best regards, Mach From jmontdrop@comcast.net Tue Feb 16 07:58:44 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8783A7D4E for ; Tue, 16 Feb 2010 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5TfJzYcgoSr for ; Tue, 16 Feb 2010 07:58:43 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 67A223A7D4C for ; Tue, 16 Feb 2010 07:58:43 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id icyj1d0071ap0As59g0JPu; Tue, 16 Feb 2010 16:00:18 +0000 Received: from [127.0.0.1] ([24.62.93.130]) by omta22.westchester.pa.mail.comcast.net with comcast id ig1T1d00L2olhLQ3ig1Tkn; Tue, 16 Feb 2010 16:01:28 +0000 Message-ID: <4B7AC10F.5070009@comcast.net> Date: Tue, 16 Feb 2010 11:00:15 -0500 From: Jake Montgomery User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2 MIME-Version: 1.0 To: rtg-bfd@ietf.org Subject: When can unschdules packets be sent? Content-Type: multipart/alternative; boundary="------------070702030304070701000401" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 15:58:44 -0000 This is a multi-part message in MIME format. --------------070702030304070701000401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit BFD Folks, I have been working with draft-ietf-bfd-base-10.txt and have read all the recent threads in this group, and I am still a bit confused about when it is allowable to send control packets during the interval between the normal periodic packets when in asynchronous mode. The base of my confusion is my perception of a conflict between two sections: (6.8.7 10th paragraph:) "A BFD Control packet *SHOULD be transmitted during the interval between periodic Control packet transmissions* when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state." (6.5 3rd paragraph::) "If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; *additional packets MUST NOT be sent*." My confusion is about all the myriad circumstances where there would be a packet content change, and a Poll sequence is being initiated for whatever reason. For example I wish to change bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. Now the quandary is, MAY I send a control packet immediately, since the contents would be different, as described in 6.8.7, or MUST I wait until the next periodic control packet because this is a poll sequence and 6.5 comes into play? This is just one of many scenarios where I am having difficulty reconciling those two paragraphs. Any guidance would be appreciated. Thanks, Jake --------------070702030304070701000401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit BFD Folks,

I have been working with draft-ietf-bfd-base-10.txt and have read all the recent threads in this group, and I am still a bit confused about when it is allowable to send control packets during the interval between the normal periodic packets when in asynchronous mode.

The base of my confusion is my perception of a conflict between two sections:

(6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state."

(6.5 3rd paragraph::) "If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; additional packets MUST NOT be sent."

My confusion is about all the myriad circumstances where there would be a packet content change, and a Poll sequence is being initiated for whatever reason. For example I wish to change bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. Now the quandary is, MAY I send a control packet immediately, since the contents would be different, as described in 6.8.7, or MUST I wait until the next periodic control packet because this is a poll sequence and 6.5 comes into play?

This is just one of many scenarios where I am having difficulty reconciling those two paragraphs. Any guidance would be appreciated.

Thanks,
    Jake


--------------070702030304070701000401-- From dkatz@juniper.net Tue Feb 16 10:04:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B13828C188 for ; Tue, 16 Feb 2010 10:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywnD2l7Q0+vN for ; Tue, 16 Feb 2010 10:04:06 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 718F828C19C for ; Tue, 16 Feb 2010 10:04:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS3rec0b9ilGx5e4jzgFUTAEn65Qwy40f@postini.com; Tue, 16 Feb 2010 10:05:41 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 16 Feb 2010 10:03:11 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 10:03:10 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 10:03:10 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 10:03:10 -0800 Received: from [172.16.12.161] ([172.16.12.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o1GI39b32095; Tue, 16 Feb 2010 10:03:09 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Jake Montgomery In-Reply-To: <4B7AC10F.5070009@comcast.net> Content-Type: multipart/alternative; boundary="Apple-Mail-8-273380649" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: When can unschdules packets be sent? Date: Tue, 16 Feb 2010 11:03:09 -0700 References: <4B7AC10F.5070009@comcast.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Feb 2010 18:03:10.0449 (UTC) FILETIME=[4CC20610:01CAAF32] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 18:04:07 -0000 --Apple-Mail-8-273380649 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hm, I can see the confusion. The intent of the verbiage in 6.5 is to make sure that implementations don't send periodic Poll packets (since more than one may be sent prior to the receipt of Final) in *addition* to the regularly- scheduled periodic packets. 6.8.7 says that you should quickly announce a state change; in the case where the state change also happens to carry the P bit, it should still be sent immediately. Any subsequent Polls should piggyback on the scheduled control packet transmissions. --Dave On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote: > BFD Folks, > > I have been working with draft-ietf-bfd-base-10.txt and have read > all the recent threads in this group, and I am still a bit confused > about when it is allowable to send control packets during the > interval between the normal periodic packets when in asynchronous > mode. > > The base of my confusion is my perception of a conflict between two > sections: > > (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted > during the interval between periodic Control packet transmissions > when the contents of that packet would differ from that in the > previously transmitted packet (other than the Poll and Final bits) > in order to more rapidly communicate a change in state." > > (6.5 3rd paragraph::) "If periodic BFD Control packets are already > being sent (the remote system is not in Demand mode), the Poll > Sequence MUST be performed by setting the Poll (P) bit on those > scheduled periodic transmissions; additional packets MUST NOT be > sent." > > My confusion is about all the myriad circumstances where there would > be a packet content change, and a Poll sequence is being initiated > for whatever reason. For example I wish to change > bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). > According to 6.8.3 that should trigger a Poll Sequence. Now the > quandary is, MAY I send a control packet immediately, since the > contents would be different, as described in 6.8.7, or MUST I wait > until the next periodic control packet because this is a poll > sequence and 6.5 comes into play? > > This is just one of many scenarios where I am having difficulty > reconciling those two paragraphs. Any guidance would be appreciated. > > Thanks, > Jake > > --Apple-Mail-8-273380649 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hm, I can see the = confusion.

The intent of the verbiage in 6.5 is to = make sure that implementations don't send periodic Poll packets (since = more than one may be sent prior to the receipt of Final) in *addition* = to the regularly-scheduled periodic = packets.

6.8.7 says that you should quickly = announce a state change;  in the case where the state change also = happens to carry the P bit, it should still be sent immediately. =  Any subsequent Polls should piggyback on the scheduled control = packet = transmissions.

--Dave

On = Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote:

BFD Folks,

I have been = working with draft-ietf-bfd-base-10.txt and have read all the recent = threads in this group, and I am still a bit confused about when it is = allowable to send control packets during the interval between the normal = periodic packets when in asynchronous mode.

The base of my = confusion is my perception of a conflict between two sections:

= (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted = during the interval between periodic Control packet transmissions = when the contents of that packet would differ from that in the = previously transmitted packet (other than the Poll and Final bits) in = order to more rapidly communicate a change in state."

(6.5 3rd = paragraph::) "If periodic BFD Control packets are already being sent = (the remote system is not in Demand mode), the Poll Sequence MUST be = performed by setting the Poll (P) bit on those scheduled periodic = transmissions; additional packets MUST NOT be sent."

My = confusion is about all the myriad circumstances where there would be a = packet content change, and a Poll sequence is being initiated for = whatever reason. For example I wish to change bfd.DesiredMinTXInterval = (which can be changed at any time 6.8.11). According to 6.8.3 that = should trigger a Poll Sequence. Now the quandary is, MAY I send a = control packet immediately, since the contents would be different, as = described in 6.8.7, or MUST I wait until the next periodic control = packet because this is a poll sequence and 6.5 comes into play?

= This is just one of many scenarios where I am having difficulty = reconciling those two paragraphs. Any guidance would be appreciated.
=
Thanks,
    Jake


=

= --Apple-Mail-8-273380649-- From jmontdrop@comcast.net Tue Feb 16 11:13:34 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C793A7D8E for ; Tue, 16 Feb 2010 11:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL8TVoiFN6Qo for ; Tue, 16 Feb 2010 11:13:32 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 365553A7D8A for ; Tue, 16 Feb 2010 11:13:32 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id ihqf1d00u0bG4ec59jF85o; Tue, 16 Feb 2010 19:15:08 +0000 Received: from [127.0.0.1] ([24.62.93.130]) by omta03.westchester.pa.mail.comcast.net with comcast id ijF71d00L2olhLQ3PjF7Go; Tue, 16 Feb 2010 19:15:07 +0000 Message-ID: <4B7AEEB9.6040809@comcast.net> Date: Tue, 16 Feb 2010 14:15:05 -0500 From: Jake Montgomery User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2 MIME-Version: 1.0 To: Dave Katz Subject: Re: When can unschdules packets be sent? References: <4B7AC10F.5070009@comcast.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000603050503020509080209" Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:13:34 -0000 This is a multi-part message in MIME format. --------------000603050503020509080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave. Thanks. That was my guess, but I just could not find corroboration in reading draft-ietf-bfd-base-10.txt. Since section 6.5 uses the strong "MUST NOT", it might benefit from clarification that this refers to "additional" poll packets and not necessarily the initial poll packet if that packet falls under 6.8.7. Just a suggestion. For the most part the draft is pretty clear and comprehensible. Thanks, Jake. On 2/16/2010 1:03 PM, Dave Katz wrote: > Hm, I can see the confusion. > > The intent of the verbiage in 6.5 is to make sure that implementations > don't send periodic Poll packets (since more than one may be sent > prior to the receipt of Final) in *addition* to the > regularly-scheduled periodic packets. > > 6.8.7 says that you should quickly announce a state change; in the > case where the state change also happens to carry the P bit, it should > still be sent immediately. Any subsequent Polls should piggyback on > the scheduled control packet transmissions. > > --Dave > > On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote: > >> BFD Folks, >> >> I have been working with draft-ietf-bfd-base-10.txt and have read all >> the recent threads in this group, and I am still a bit confused about >> when it is allowable to send control packets during the interval >> between the normal periodic packets when in asynchronous mode. >> >> The base of my confusion is my perception of a conflict between two >> sections: >> >> (6.8.7 10th paragraph:) "A BFD Control packet *SHOULD be transmitted >> during the interval between periodic Control packet transmissions* >> when the contents of that packet would differ from that in the >> previously transmitted packet (other than the Poll and Final bits) in >> order to more rapidly communicate a change in state." >> >> (6.5 3rd paragraph::) "If periodic BFD Control packets are already >> being sent (the remote system is not in Demand mode), the Poll >> Sequence MUST be performed by setting the Poll (P) bit on those >> scheduled periodic transmissions; *additional packets MUST NOT be sent*." >> >> My confusion is about all the myriad circumstances where there would >> be a packet content change, and a Poll sequence is being initiated >> for whatever reason. For example I wish to change >> bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). >> According to 6.8.3 that should trigger a Poll Sequence. Now the >> quandary is, MAY I send a control packet immediately, since the >> contents would be different, as described in 6.8.7, or MUST I wait >> until the next periodic control packet because this is a poll >> sequence and 6.5 comes into play? >> >> This is just one of many scenarios where I am having difficulty >> reconciling those two paragraphs. Any guidance would be appreciated. >> >> Thanks, >> Jake >> >> > --------------000603050503020509080209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave.

Thanks. That was my guess, but I just could not find corroboration in reading draft-ietf-bfd-base-10.txt. Since section 6.5 uses the strong "MUST NOT", it might benefit from clarification that this refers to "additional" poll packets and not necessarily the initial poll packet if that packet falls under 6.8.7.  Just a suggestion. For the most part the draft is pretty clear and comprehensible.

Thanks,
    Jake.
   

On 2/16/2010 1:03 PM, Dave Katz wrote:
Hm, I can see the confusion.

The intent of the verbiage in 6.5 is to make sure that implementations don't send periodic Poll packets (since more than one may be sent prior to the receipt of Final) in *addition* to the regularly-scheduled periodic packets.

6.8.7 says that you should quickly announce a state change;  in the case where the state change also happens to carry the P bit, it should still be sent immediately.  Any subsequent Polls should piggyback on the scheduled control packet transmissions.

--Dave

On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote:

BFD Folks,

I have been working with draft-ietf-bfd-base-10.txt and have read all the recent threads in this group, and I am still a bit confused about when it is allowable to send control packets during the interval between the normal periodic packets when in asynchronous mode.

The base of my confusion is my perception of a conflict between two sections:

(6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state."

(6.5 3rd paragraph::) "If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; additional packets MUST NOT be sent."

My confusion is about all the myriad circumstances where there would be a packet content change, and a Poll sequence is being initiated for whatever reason. For example I wish to change bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. Now the quandary is, MAY I send a control packet immediately, since the contents would be different, as described in 6.8.7, or MUST I wait until the next periodic control packet because this is a poll sequence and 6.5 comes into play?

This is just one of many scenarios where I am having difficulty reconciling those two paragraphs. Any guidance would be appreciated.

Thanks,
    Jake




--------------000603050503020509080209-- From dkatz@juniper.net Tue Feb 16 17:54:13 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594F428C0E0 for ; Tue, 16 Feb 2010 17:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI6r7bXfILUk for ; Tue, 16 Feb 2010 17:54:10 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 679793A7BFD for ; Tue, 16 Feb 2010 17:54:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS3tMnb4BJlA7TvpsdqiFRwVBXhYrufPA@postini.com; Tue, 16 Feb 2010 17:55:47 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 16 Feb 2010 17:53:30 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 17:53:30 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 17:53:30 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 17:53:29 -0800 Received: from [172.16.12.161] ([172.16.12.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o1H1rSb75046; Tue, 16 Feb 2010 17:53:28 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Jake Montgomery In-Reply-To: <4B7AEEB9.6040809@comcast.net> Content-Type: multipart/alternative; boundary="Apple-Mail-11-301599639" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: When can unschdules packets be sent? Date: Tue, 16 Feb 2010 18:53:28 -0700 References: <4B7AC10F.5070009@comcast.net> <4B7AEEB9.6040809@comcast.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Feb 2010 01:53:29.0629 (UTC) FILETIME=[00B32CD0:01CAAF74] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 01:54:13 -0000 --Apple-Mail-11-301599639 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yep, it could be clearer. Right now the spec is in Really Really Really Last Call This Time For Sure so I'm loathe to make any changes, but this can enter the queue for some future revision. --Dave On Feb 16, 2010, at 12:15 PM, Jake Montgomery wrote: > Dave. > > Thanks. That was my guess, but I just could not find corroboration > in reading draft-ietf-bfd-base-10.txt. Since section 6.5 uses the > strong "MUST NOT", it might benefit from clarification that this > refers to "additional" poll packets and not necessarily the initial > poll packet if that packet falls under 6.8.7. Just a suggestion. > For the most part the draft is pretty clear and comprehensible. > > Thanks, > Jake. > > > On 2/16/2010 1:03 PM, Dave Katz wrote: >> >> Hm, I can see the confusion. >> >> The intent of the verbiage in 6.5 is to make sure that >> implementations don't send periodic Poll packets (since more than >> one may be sent prior to the receipt of Final) in *addition* to the >> regularly-scheduled periodic packets. >> >> 6.8.7 says that you should quickly announce a state change; in the >> case where the state change also happens to carry the P bit, it >> should still be sent immediately. Any subsequent Polls should >> piggyback on the scheduled control packet transmissions. >> >> --Dave >> >> On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote: >> >>> BFD Folks, >>> >>> I have been working with draft-ietf-bfd-base-10.txt and have read >>> all the recent threads in this group, and I am still a bit >>> confused about when it is allowable to send control packets during >>> the interval between the normal periodic packets when in >>> asynchronous mode. >>> >>> The base of my confusion is my perception of a conflict between >>> two sections: >>> >>> (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be >>> transmitted during the interval between periodic Control packet >>> transmissions when the contents of that packet would differ from >>> that in the previously transmitted packet (other than the Poll and >>> Final bits) in order to more rapidly communicate a change in state." >>> >>> (6.5 3rd paragraph::) "If periodic BFD Control packets are already >>> being sent (the remote system is not in Demand mode), the Poll >>> Sequence MUST be performed by setting the Poll (P) bit on those >>> scheduled periodic transmissions; additional packets MUST NOT be >>> sent." >>> >>> My confusion is about all the myriad circumstances where there >>> would be a packet content change, and a Poll sequence is being >>> initiated for whatever reason. For example I wish to change >>> bfd.DesiredMinTXInterval (which can be changed at any time >>> 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. >>> Now the quandary is, MAY I send a control packet immediately, >>> since the contents would be different, as described in 6.8.7, or >>> MUST I wait until the next periodic control packet because this is >>> a poll sequence and 6.5 comes into play? >>> >>> This is just one of many scenarios where I am having difficulty >>> reconciling those two paragraphs. Any guidance would be appreciated. >>> >>> Thanks, >>> Jake >>> >>> >> > --Apple-Mail-11-301599639 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yep, it could be clearer. =  Right now the spec is in Really Really Really Last Call This Time = For Sure so I'm loathe to make any changes, but this can enter the queue = for some future = revision.

--Dave

On Feb 16, = 2010, at 12:15 PM, Jake Montgomery wrote:

Dave.

Thanks. That was my = guess, but I just could not find corroboration in reading = draft-ietf-bfd-base-10.txt. Since section 6.5 uses the strong "MUST = NOT", it might benefit from clarification that this refers to = "additional" poll packets and not necessarily the initial poll packet if = that packet falls under 6.8.7.  Just a suggestion. For the most = part the draft is pretty clear and comprehensible.

Thanks,
=     Jake.
   

On 2/16/2010 = 1:03 PM, Dave Katz wrote:
Hm, I can see the confusion.

The = intent of the verbiage in 6.5 is to make sure that implementations don't = send periodic Poll packets (since more than one may be sent prior to the = receipt of Final) in *addition* to the regularly-scheduled periodic = packets.

6.8.7 says that you should = quickly announce a state change;  in the case where the state = change also happens to carry the P bit, it should still be sent = immediately.  Any subsequent Polls should piggyback on the = scheduled control packet transmissions.

=
--Dave

On Feb 16, 2010, at 9:00 AM, = Jake Montgomery wrote:

=
= BFD Folks,

I have been working with = draft-ietf-bfd-base-10.txt and have read all the recent threads in this = group, and I am still a bit confused about when it is allowable to send = control packets during the interval between the normal periodic packets = when in asynchronous mode.

The base of my confusion is my = perception of a conflict between two sections:

(6.8.7 10th = paragraph:) "A BFD Control packet SHOULD be transmitted during the = interval between periodic Control packet transmissions when the = contents of that packet would differ from that in the previously = transmitted packet (other than the Poll and Final bits) in order to more = rapidly communicate a change in state."

(6.5 3rd = paragraph::) "If periodic BFD Control packets are already being sent = (the remote system is not in Demand mode), the Poll Sequence MUST be = performed by setting the Poll (P) bit on those scheduled periodic = transmissions; additional packets MUST NOT be sent."

= My confusion is about all the myriad circumstances where there would be = a packet content change, and a Poll sequence is being initiated for = whatever reason. For example I wish to change bfd.DesiredMinTXInterval = (which can be changed at any time 6.8.11). According to 6.8.3 that = should trigger a Poll Sequence. Now the quandary is, MAY I send a = control packet immediately, since the contents would be different, as = described in 6.8.7, or MUST I wait until the next periodic control = packet because this is a poll sequence and 6.5 comes into play?
=
This is just one of many scenarios where I am having difficulty = reconciling those two paragraphs. Any guidance would be appreciated.
=
Thanks,
    Jake


=


=

= --Apple-Mail-11-301599639-- From jmontdrop@comcast.net Thu Feb 18 13:21:26 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F3C3A7AE0 for ; Thu, 18 Feb 2010 13:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0cSf5Uw9T09 for ; Thu, 18 Feb 2010 13:21:25 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id AA9893A6858 for ; Thu, 18 Feb 2010 13:21:24 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id jPAh1d0081GhbT851ZP81s; Thu, 18 Feb 2010 21:23:08 +0000 Received: from [127.0.0.1] ([24.62.93.130]) by omta07.westchester.pa.mail.comcast.net with comcast id jZP81d0022olhLQ3TZP81T; Thu, 18 Feb 2010 21:23:08 +0000 Message-ID: <4B7DAFBA.7020201@comcast.net> Date: Thu, 18 Feb 2010 16:23:06 -0500 From: Jake Montgomery User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Dave Katz Subject: Re: When can unschdules packets be sent? References: <4B7AC10F.5070009@comcast.net> <4B7AEEB9.6040809@comcast.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010706070501000404050807" Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:21:26 -0000 This is a multi-part message in MIME format. --------------010706070501000404050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One small follow up question. It appears that if bfd.RemoteMinRxInterval is 0 then the local session is not supposed "to send any periodic BFD Control packets" (6.8.1). If I understand correctly, the local session can still send immediate packets if there is a state change (6.8.7), including those requiring a poll sequence be initiated. Thats all well and good if that initial poll packet gets received by the remote system, in which case the remote session will send an 'F' packet, and we will go on not sending them any periodic BFD Control packets. However if that initial poll packet is lost, then the remote session will continue sending periodic control packets _without_ the Final bit set. So, unless the local system sends additional poll packets, the poll sequence will never complete. This means that changes that require a complete poll sequence, such as a bfd.DesiredMinTxInterval increase (6.8.3), would never be allowed to take effect, even in a system that was up and otherwise functioning (except for that one lost packet.) This could be the intention, that no additional poll packets are sent, though it seems problematic to me. If that is not the intention, then the local system needs to send multiple poll packets until it receives a packet with the Final bit set (or the local Detection time expires without any response.) If that is the case, then my question is - what is the rate at which additional poll packets should be sent when bfd.RemoteMinRxInterval is 0? (My guess is that the local system just keeps sending poll packets at bfd.DesiredMinTxInterval?) Any guidance would be appreciated, Jake. [... clip] >> On 2/16/2010 1:03 PM, Dave Katz wrote: >>> Hm, I can see the confusion. >>> >>> The intent of the verbiage in 6.5 is to make sure that >>> implementations don't send periodic Poll packets (since more than >>> one may be sent prior to the receipt of Final) in *addition* to the >>> regularly-scheduled periodic packets. >>> >>> 6.8.7 says that you should quickly announce a state change; in the >>> case where the state change also happens to carry the P bit, it >>> should still be sent immediately. Any subsequent Polls should >>> piggyback on the scheduled control packet transmissions. >>> >>> --Dave >>> >>> On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote: >>> >>>> BFD Folks, >>>> >>>> I have been working with draft-ietf-bfd-base-10.txt and have read >>>> all the recent threads in this group, and I am still a bit confused >>>> about when it is allowable to send control packets during the >>>> interval between the normal periodic packets when in asynchronous >>>> mode. >>>> >>>> The base of my confusion is my perception of a conflict between two >>>> sections: >>>> >>>> (6.8.7 10th paragraph:) "A BFD Control packet *SHOULD be >>>> transmitted during the interval between periodic Control packet >>>> transmissions* when the contents of that packet would differ from >>>> that in the previously transmitted packet (other than the Poll and >>>> Final bits) in order to more rapidly communicate a change in state." >>>> >>>> (6.5 3rd paragraph::) "If periodic BFD Control packets are already >>>> being sent (the remote system is not in Demand mode), the Poll >>>> Sequence MUST be performed by setting the Poll (P) bit on those >>>> scheduled periodic transmissions; *additional packets MUST NOT be >>>> sent*." >>>> >>>> My confusion is about all the myriad circumstances where there >>>> would be a packet content change, and a Poll sequence is being >>>> initiated for whatever reason. For example I wish to change >>>> bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). >>>> According to 6.8.3 that should trigger a Poll Sequence. Now the >>>> quandary is, MAY I send a control packet immediately, since the >>>> contents would be different, as described in 6.8.7, or MUST I wait >>>> until the next periodic control packet because this is a poll >>>> sequence and 6.5 comes into play? >>>> >>>> This is just one of many scenarios where I am having difficulty >>>> reconciling those two paragraphs. Any guidance would be appreciated. >>>> >>>> Thanks, >>>> Jake >>>> >>>> >>> >> > --------------010706070501000404050807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One small follow up question.

It appears that if bfd.RemoteMinRxInterval is 0 then the local session is not supposed "to send any periodic BFD Control packets" (6.8.1).  If I understand correctly, the local session can still send immediate packets if there is a state change (6.8.7), including those requiring a poll sequence be initiated. Thats all well and good if that initial poll packet gets received by the remote system, in which case the remote session will send an 'F' packet, and we will go on not sending them any periodic BFD Control packets. However if that initial poll packet is lost, then the remote session will continue sending periodic control packets _without_ the Final bit set.  So, unless the local system sends additional poll packets, the poll sequence will never complete. This means that changes that require a complete poll sequence, such as a bfd.DesiredMinTxInterval increase (6.8.3), would never be allowed to take effect, even in a system that was up and otherwise functioning (except for that one lost packet.)

This could be the intention,  that no additional poll packets are sent, though it seems problematic to me. If that is not the intention, then the local system needs to send multiple poll packets until it receives a packet with the Final bit set (or the local Detection time expires without any response.) If that is the case, then my question is - what is the rate at which additional poll packets should be sent when bfd.RemoteMinRxInterval is 0?  (My guess is that the local system just keeps sending poll packets at bfd.DesiredMinTxInterval?)

Any guidance would be appreciated,
  Jake.


[... clip]   
On 2/16/2010 1:03 PM, Dave Katz wrote:
Hm, I can see the confusion.

The intent of the verbiage in 6.5 is to make sure that implementations don't send periodic Poll packets (since more than one may be sent prior to the receipt of Final) in *addition* to the regularly-scheduled periodic packets.

6.8.7 says that you should quickly announce a state change;  in the case where the state change also happens to carry the P bit, it should still be sent immediately.  Any subsequent Polls should piggyback on the scheduled control packet transmissions.

--Dave

On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote:

BFD Folks,

I have been working with draft-ietf-bfd-base-10.txt and have read all the recent threads in this group, and I am still a bit confused about when it is allowable to send control packets during the interval between the normal periodic packets when in asynchronous mode.

The base of my confusion is my perception of a conflict between two sections:

(6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state."

(6.5 3rd paragraph::) "If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; additional packets MUST NOT be sent."

My confusion is about all the myriad circumstances where there would be a packet content change, and a Poll sequence is being initiated for whatever reason. For example I wish to change bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. Now the quandary is, MAY I send a control packet immediately, since the contents would be different, as described in 6.8.7, or MUST I wait until the next periodic control packet because this is a poll sequence and 6.5 comes into play?

This is just one of many scenarios where I am having difficulty reconciling those two paragraphs. Any guidance would be appreciated.

Thanks,
    Jake






--------------010706070501000404050807-- From dkatz@juniper.net Thu Feb 18 15:13:54 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2FF3A7248 for ; Thu, 18 Feb 2010 15:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5baHnZ6TUe7 for ; Thu, 18 Feb 2010 15:13:51 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 519F928C0EF for ; Thu, 18 Feb 2010 15:13:50 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS33KFt6IpWM0bFHOq5hbBbigbA2Qgw6I@postini.com; Thu, 18 Feb 2010 15:15:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 18 Feb 2010 15:13:11 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 15:13:10 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 15:13:10 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 15:13:10 -0800 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o1IND9b06001; Thu, 18 Feb 2010 15:13:09 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Jake Montgomery In-Reply-To: <4B7DAFBA.7020201@comcast.net> Content-Type: multipart/alternative; boundary="Apple-Mail-11-464780137" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: When can unschdules packets be sent? Date: Thu, 18 Feb 2010 16:13:08 -0700 References: <4B7AC10F.5070009@comcast.net> <4B7AEEB9.6040809@comcast.net> <4B7DAFBA.7020201@comcast.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Feb 2010 23:13:10.0105 (UTC) FILETIME=[EFD7CC90:01CAB0EF] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 23:13:55 -0000 --Apple-Mail-11-464780137 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In this case, though it is a little confusing, it turns out to be pretty much a non-issue, because a system receiving a zero value in Min RX Interval ought not ever be in a position to send a poll sequence in the first place (or any other kind of poll.) A zero value is sent in two circumstances--when trying to keep a session from coming up (the sender really doesn't care what the receiver has to say about *anything*) and in the Multipoint Head role in the multipoint spec (soon to be dusted off). When there are potentially a jillion tails, you really don't want them *ever* sending *anything* that the head didn't ask for directly. It would probably disambiguate a bit to say that the state-change mechanism doesn't apply if the system is receiving MinRXIvl==0, though the spec as is won't hurt much (sending the single Poll on a state change in the multipoint scenario is undesirable but not as fatal as pumping packets repeatedly.) Once the dust settles on the last call and the RFC gets issued, we could always move forward with an errata document as the multipoint stuff progresses. Thanks for the very close reading and analysis. --Dave On Feb 18, 2010, at 2:23 PM, Jake Montgomery wrote: > One small follow up question. > > It appears that if bfd.RemoteMinRxInterval is 0 then the local > session is not supposed "to send any periodic BFD Control > packets" (6.8.1). If I understand correctly, the local session can > still send immediate packets if there is a state change (6.8.7), > including those requiring a poll sequence be initiated. Thats all > well and good if that initial poll packet gets received by the > remote system, in which case the remote session will send an 'F' > packet, and we will go on not sending them any periodic BFD Control > packets. However if that initial poll packet is lost, then the > remote session will continue sending periodic control packets > _without_ the Final bit set. So, unless the local system sends > additional poll packets, the poll sequence will never complete. This > means that changes that require a complete poll sequence, such as a > bfd.DesiredMinTxInterval increase (6.8.3), would never be allowed to > take effect, even in a system that was up and otherwise functioning > (except for that one lost packet.) > > This could be the intention, that no additional poll packets are > sent, though it seems problematic to me. If that is not the > intention, then the local system needs to send multiple poll packets > until it receives a packet with the Final bit set (or the local > Detection time expires without any response.) If that is the case, > then my question is - what is the rate at which additional poll > packets should be sent when bfd.RemoteMinRxInterval is 0? (My guess > is that the local system just keeps sending poll packets at > bfd.DesiredMinTxInterval?) > > Any guidance would be appreciated, > Jake. > > > [... clip] >>> On 2/16/2010 1:03 PM, Dave Katz wrote: >>>> >>>> Hm, I can see the confusion. >>>> >>>> The intent of the verbiage in 6.5 is to make sure that >>>> implementations don't send periodic Poll packets (since more than >>>> one may be sent prior to the receipt of Final) in *addition* to >>>> the regularly-scheduled periodic packets. >>>> >>>> 6.8.7 says that you should quickly announce a state change; in >>>> the case where the state change also happens to carry the P bit, >>>> it should still be sent immediately. Any subsequent Polls should >>>> piggyback on the scheduled control packet transmissions. >>>> >>>> --Dave >>>> >>>> On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote: >>>> >>>>> BFD Folks, >>>>> >>>>> I have been working with draft-ietf-bfd-base-10.txt and have >>>>> read all the recent threads in this group, and I am still a bit >>>>> confused about when it is allowable to send control packets >>>>> during the interval between the normal periodic packets when in >>>>> asynchronous mode. >>>>> >>>>> The base of my confusion is my perception of a conflict between >>>>> two sections: >>>>> >>>>> (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be >>>>> transmitted during the interval between periodic Control packet >>>>> transmissions when the contents of that packet would differ from >>>>> that in the previously transmitted packet (other than the Poll >>>>> and Final bits) in order to more rapidly communicate a change in >>>>> state." >>>>> >>>>> (6.5 3rd paragraph::) "If periodic BFD Control packets are >>>>> already being sent (the remote system is not in Demand mode), >>>>> the Poll Sequence MUST be performed by setting the Poll (P) bit >>>>> on those scheduled periodic transmissions; additional packets >>>>> MUST NOT be sent." >>>>> >>>>> My confusion is about all the myriad circumstances where there >>>>> would be a packet content change, and a Poll sequence is being >>>>> initiated for whatever reason. For example I wish to change >>>>> bfd.DesiredMinTXInterval (which can be changed at any time >>>>> 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. >>>>> Now the quandary is, MAY I send a control packet immediately, >>>>> since the contents would be different, as described in 6.8.7, or >>>>> MUST I wait until the next periodic control packet because this >>>>> is a poll sequence and 6.5 comes into play? >>>>> >>>>> This is just one of many scenarios where I am having difficulty >>>>> reconciling those two paragraphs. Any guidance would be >>>>> appreciated. >>>>> >>>>> Thanks, >>>>> Jake >>>>> >>>>> >>>> >>> >> > --Apple-Mail-11-464780137 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In this case, though it is a = little confusing, it turns out to be pretty much a non-issue, because a = system receiving a zero value in Min RX Interval ought not ever be in a = position to send a poll sequence in the first place (or any other kind = of poll.)

A zero value is sent in two = circumstances--when trying to keep a session from coming up (the sender = really doesn't care what the receiver has to say about *anything*) and = in the Multipoint Head role in the multipoint spec (soon to be dusted = off).  When there are potentially a jillion tails, you really don't = want them *ever* sending *anything* that the head didn't ask for = directly.

It would probably disambiguate a bit = to say that the state-change mechanism doesn't apply if the system is = receiving MinRXIvl=3D=3D0, though the spec as is won't hurt much = (sending the single Poll on a state change in the multipoint scenario is = undesirable but not as fatal as pumping packets repeatedly.)  Once = the dust settles on the last call and the RFC gets issued, we could = always move forward with an errata document as the multipoint stuff = progresses.

Thanks for the very close reading = and = analysis.

--Dave

On Feb 18, 2010, at 2:23 PM, Jake Montgomery wrote:

One small follow up question.
=
It appears that if bfd.RemoteMinRxInterval is 0 then the local = session is not supposed "to send any periodic BFD Control packets" = (6.8.1).  If I understand correctly, the local session can still = send immediate packets if there is a state change (6.8.7), including = those requiring a poll sequence be initiated. Thats all well and good if = that initial poll packet gets received by the remote system, in which = case the remote session will send an 'F' packet, and we will go on not = sending them any periodic BFD Control packets. However if that initial = poll packet is lost, then the remote session will continue sending = periodic control packets _without_ the Final bit set.  So, unless = the local system sends additional poll packets, the poll sequence will = never complete. This means that changes that require a complete poll = sequence, such as a bfd.DesiredMinTxInterval increase (6.8.3), would = never be allowed to take effect, even in a system that was up and = otherwise functioning (except for that one lost packet.)

This = could be the intention,  that no additional poll packets are sent, = though it seems problematic to me. If that is not the intention, then = the local system needs to send multiple poll packets until it receives a = packet with the Final bit set (or the local Detection time expires = without any response.) If that is the case, then my question is - what = is the rate at which additional poll packets should be sent when = bfd.RemoteMinRxInterval is 0?  (My guess is that the local system = just keeps sending poll packets at bfd.DesiredMinTxInterval?)

= Any guidance would be appreciated,
  Jake.


[... = clip]   
On 2/16/2010 1:03 PM, Dave Katz = wrote:
Hm, I can see the confusion.

=
The intent of the verbiage in 6.5 is to make sure that = implementations don't send periodic Poll packets (since more than one = may be sent prior to the receipt of Final) in *addition* to the = regularly-scheduled periodic packets.

=
6.8.7 says that you should quickly announce a state change; =  in the case where the state change also happens to carry the P = bit, it should still be sent immediately.  Any subsequent Polls = should piggyback on the scheduled control packet transmissions.
=

--Dave

=
On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote:
=
=
BFD Folks,
=
I have been working with draft-ietf-bfd-base-10.txt and have read = all the recent threads in this group, and I am still a bit confused = about when it is allowable to send control packets during the interval = between the normal periodic packets when in asynchronous mode.
=
The base of my confusion is my perception of a conflict between = two sections:

(6.8.7 10th paragraph:) "A BFD Control = packet SHOULD be transmitted during the interval between periodic = Control packet transmissions when the contents of that packet would = differ from that in the previously transmitted packet (other than the = Poll and Final bits) in order to more rapidly communicate a change in = state."

(6.5 3rd paragraph::) "If periodic BFD Control = packets are already being sent (the remote system is not in Demand = mode), the Poll Sequence MUST be performed by setting the Poll (P) bit = on those scheduled periodic transmissions; additional packets MUST = NOT be sent."

My confusion is about all the myriad = circumstances where there would be a packet content change, and a Poll = sequence is being initiated for whatever reason. For example I wish to = change bfd.DesiredMinTXInterval (which can be changed at any time = 6.8.11). According to 6.8.3 that should trigger a Poll Sequence. Now the = quandary is, MAY I send a control packet immediately, since the contents = would be different, as described in 6.8.7, or MUST I wait until the next = periodic control packet because this is a poll sequence and 6.5 comes = into play?

This is just one of many scenarios where I am = having difficulty reconciling those two paragraphs. Any guidance would = be appreciated.

Thanks,
    Jake
=

=

=


=

= --Apple-Mail-11-464780137-- From apvelan@cisco.com Tue Feb 23 08:42:27 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B455228C1F3 for ; Tue, 23 Feb 2010 08:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOY7uvBQINBx for ; Tue, 23 Feb 2010 08:42:27 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F416728C0F4 for ; Tue, 23 Feb 2010 08:42:26 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGOUg0urRN+J/2dsb2JhbACbDHOlA5hfhGwEgxM X-IronPort-AV: E=Sophos;i="4.49,527,1262563200"; d="scan'208";a="155498827" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 23 Feb 2010 16:44:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1NGiRLn003000 for ; Tue, 23 Feb 2010 16:44:29 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 22:14:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: BFD at IETF 77 Anaheim Date: Tue, 23 Feb 2010 22:14:27 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD at IETF 77 Anaheim Thread-Index: AcqbnbOTdiC3NbIrQ+q/3D8eN4W6FgZCVbxw References: From: "Palanivelan A (apvelan)" To: X-OriginalArrivalTime: 23 Feb 2010 16:44:27.0525 (UTC) FILETIME=[76914350:01CAB4A7] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:42:27 -0000 Hi, I may have missed some mails in this topic. I am attending IETF-77 and am interested to know the planned activities for this working group. Appreciate your response. Thanks and Regards, A.Palanivelan From dward@juniper.net Wed Feb 24 10:47:28 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23183A84B8 for ; Wed, 24 Feb 2010 10:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7CZgN7yGmHO for ; Wed, 24 Feb 2010 10:47:27 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 53E003A84B3 for ; Wed, 24 Feb 2010 10:47:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS4V0s8uQNCsdZ9nX0LS7JSOurYHUqoB+@postini.com; Wed, 24 Feb 2010 10:49:35 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 24 Feb 2010 10:48:31 -0800 From: David Ward To: "rtg-bfd@ietf.org" Date: Wed, 24 Feb 2010 10:48:30 -0800 Subject: WG Last Last Call on BFD-Base Thread-Topic: WG Last Last Call on BFD-Base Thread-Index: Acq1gfWknGBcVXyJRRCxw3mXHPFp3g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , Farrel , David Ward , Adrian X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 18:47:28 -0000 All - To fulfill the necessary process for publishing the BFD specs, we need to h= ave a WG LC on bfd base due to the IPR disclosures. We are going to end the= LC 2010.03.10 at 1200 PST.=20 Please take note of these IPR statements that are in the IETF's IPR disclos= ure tracker: "Nortel Networks Statement about IPR claimed in draft-ietf-bfd-base" https= ://datatracker.ietf.org/ipr/516/ "Juniper's Statement of IPR related to draft-ietf-bfd-base-08" https://data= tracker.ietf.org/ipr/1143/ "Cisco's Statement of IPR relating to draft-ietf-bfd-base-11" https://data= tracker.ietf.org/ipr/1263/ "Juniper's Statement of IPR related to draft-ietf-bfd-base-11" https://dat= atracker.ietf.org/ipr/1258/ Please reply with any concerns. Thanks -DWard, Jeff From dai.xuehui@zte.com.cn Sun Feb 28 19:47:39 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C51E3A8B12 for ; Sun, 28 Feb 2010 19:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W329uKkmD3nw for ; Sun, 28 Feb 2010 19:47:38 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 1F4553A8B11 for ; Sun, 28 Feb 2010 19:47:37 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469076853516; Mon, 1 Mar 2010 11:18:47 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.6853516; Mon, 1 Mar 2010 11:46:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o213lY6j060827 for ; Mon, 1 Mar 2010 11:47:34 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) To: rtg-bfd@ietf.org Subject: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Mon, 1 Mar 2010 11:46:00 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-01 11:51:03, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-01 11:51:03, Serialize complete at 2010-03-01 11:51:03, S/MIME Sign failed at 2010-03-01 11:51:03: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-01 11:47:28, Serialize complete at 2010-03-01 11:47:28 Content-Type: multipart/alternative; boundary="=_alternative 00152790482576D9_=" X-MAIL: mse1.zte.com.cn o213lY6j060827 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 03:47:39 -0000 This is a multipart message in MIME format. --=_alternative 00152790482576D9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLCANCg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBvbiBCRkQgZXh0ZW5zaW9u cywgdGhlIGRyYWZ0J3MgbGluayBpczogDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt ZHotYmZkLWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDAudHh0DQoNClRoaXMgZG9jdW1lbnQg ZXh0ZW5kcyBCRkQgbWVjaGFuaXNtIHRvIHN1cHBvcnQgZGV0ZWN0aW9uIGZ1bmN0aW9uIGZvciAN CnBhY2tldHMgd2l0aCB2YXJpYWJsZSBsZW5ndGhzLiAgVGhyb3VnaCBkeW5hbWljYWxseSBjaGFu Z2luZyB0aGUgbGVuZ3RoIG9mIA0KQkZEIHBhY2tldHMsIA0KaXQgY2FuIGRldGVjdCBib3RoIHRy YWRpdGlvbmFsIGZhdWx0cyBzdWNoIGFzIGxpbmsgZmFpbHVyZSBvciByb3V0ZSBmYXVsdCwgDQph cyB3ZWxsIGFzIG5vbi1mb3J3YXJkaW5nIHByb2JsZW0gZm9yIHBhY2tldHMgd2l0aCBhIGxlbmd0 aCBpbiBhIHNwZWNpYWwgDQpyYW5nZSwgDQp3aGljaCBtYXliZSBjYXVzZWQgYnkgZXF1aXBtZW50 J3MgaW50ZXJuYWwgZGVmZWN0cy4NCiANCkFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJl IHdlbGNvbWVkISANCg0KUmVnYXJkcyANCkRhaQ0KDQoNCg0KQmVzdCBSZWdhcmRzLg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K16PE+tDCtLrT5L/so6y5pNf3 y7PA+6Osye3M5b2hv7WjrOPYvNK7tsDWo6ENCg== --=_alternative 00152790482576D9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+PGZvbnQg c2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgb24gQkZEIGV4dGVuc2lvbnM8L2ZvbnQ+PGZv bnQgc2l6ZT0zPiwgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUNCmRy YWZ0J3MgbGluayBpczogPC9mb250Pjxmb250IHNpemU9NCBjb2xvcj1ibHVlIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWR6LWJmZC1leHRl bnNpb25zLWZvci12bC1wYWNrZXRzLTAwLnR4dDwvdT48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250 IHNpemU9Mj48dHQ+VGhpcyBkb2N1bWVudCBleHRlbmRzIEJGRCBtZWNoYW5pc20gdG8gc3VwcG9y dA0KZGV0ZWN0aW9uIGZ1bmN0aW9uIGZvciAmbmJzcDtwYWNrZXRzIHdpdGggdmFyaWFibGUgbGVu Z3Rocy4gJm5ic3A7VGhyb3VnaA0KZHluYW1pY2FsbHkgY2hhbmdpbmcgdGhlIGxlbmd0aCBvZiBC RkQgcGFja2V0cywgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5pdCBjYW4gZGV0 ZWN0IGJvdGggdHJhZGl0aW9uYWwgZmF1bHRzIHN1Y2ggYXMgbGluaw0KZmFpbHVyZSBvciByb3V0 ZSBmYXVsdCwgYXMgd2VsbCBhcyBub24tZm9yd2FyZGluZyBwcm9ibGVtIGZvciBwYWNrZXRzIHdp dGgNCmEgbGVuZ3RoIGluIGEgc3BlY2lhbCByYW5nZSwgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD53aGljaCBtYXliZSBjYXVzZWQgYnkgZXF1aXBtZW50J3MgaW50ZXJuYWwgZGVm ZWN0cy48L3R0PjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCjwvdHQ+PC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KQW55IGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZWQhPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0PlJlZ2FyZHM8 L3R0PjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkRh aTwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCtejxPrQwrS60+S/7KOsuaTX98uzwPujrMntzOW9ob+1o6zj 2LzSu7bA1qOhPC9mb250Pg0K --=_alternative 00152790482576D9_=--