From ldunbar@huawei.com Sun Nov 8 05:10:43 2009 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 685633A6981 for ; Sun, 8 Nov 2009 05:10:43 -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 iCkRr3gWKVfi for ; Sun, 8 Nov 2009 05:10:38 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 843E93A68B5 for ; Sun, 8 Nov 2009 05:10:38 -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 <0KSS00IT3KMFNC@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sun, 08 Nov 2009 05:11:03 -0800 (PST) Received: from L735042 (host-128-155.meeting.ietf.org [133.93.128.155]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSS00FOJKLKHK@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sun, 08 Nov 2009 05:11:03 -0800 (PST) Date: Sun, 08 Nov 2009 07:10:34 -0600 From: Linda Dunbar Subject: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths? To: 'Dave Katz' , dward@cisco.com Message-id: <000b01ca6074$edf3a140$9b805d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_XTIgvNsHQAfJUe7doZ7JDw)" Thread-index: Acpf8+ourbcmLnwLT8WX3FhhZi7row== 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: Sun, 08 Nov 2009 13:10:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XTIgvNsHQAfJUe7doZ7JDw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave and David, Hope you can help me to figure out the following issues with regard to "draft-ietf-bfd-multihop-8": * Multiple BFD sessions between one pair of system was mentioned several times in the document. Is the purpose of having multiple BFD sessions between the same pair for traversing different alternative routes between the same pair? If yes, the document didn't say how to enforce it. Even the different Destination/Source addresses being used can't guarantee that those BFD sessions will traverse different paths. Is it out of the scope of this document? * What are the benefits of enforcing BFD sessions between a pair of nodes to traverse alternative paths between them? I guess by doing so, the two nodes get to know how many different paths are between them. Who will use this information? * Your BFD base draft (draft-ietf-bfd-base-09) does state that one of the goals of BFD is to traverse all possible paths between two nodes. Does it include the alternative paths between specific Ingress and Egress? * Suggestion if you do think it is necessary to traverse all the alternative paths between two nodes as indicated in the BFD base document: * Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them. Hope to have more discussion in Hiroshima. Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_XTIgvNsHQAfJUe7doZ7JDw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave and David,

 

Hope you can help me to figure out the following issues with regard to “draft-ietf-bfd-multihop-8”:

 

  • Multiple BFD sessions between one pair of system was mentioned several times in the document. Is the purpose of having multiple BFD sessions between the same pair for traversing different alternative routes between the same pair? If yes, the document didn’t say how to enforce it. Even the different Destination/Source addresses being used can’t guarantee that those BFD sessions will traverse different paths. Is it out of the scope of this document?
  • What are the benefits of enforcing BFD sessions between a pair of nodes to traverse alternative paths between them? I guess by doing so, the two nodes get to know how many different paths are between them. Who will use this information?
  • Your BFD base draft (draft-ietf-bfd-base-09) does state that one of the goals of BFD is to traverse all possible paths between two nodes. Does it include the alternative paths between specific Ingress and Egress?
  • Suggestion if you do think it is necessary to traverse all the alternative paths between two nodes as indicated in the BFD base document:
    • Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them.

 

Hope to have more discussion in Hiroshima.

 

Linda Dunbar

 

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_XTIgvNsHQAfJUe7doZ7JDw)-- From ldunbar@huawei.com Sun Nov 8 05:10:43 2009 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 89D0F3A68B5 for ; Sun, 8 Nov 2009 05:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 DxK0Gvj-Ix2y for ; Sun, 8 Nov 2009 05:10:40 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 19B073A684A for ; Sun, 8 Nov 2009 05:10:40 -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 <0KSS00ITFKMHNC@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sun, 08 Nov 2009 05:11:05 -0800 (PST) Received: from L735042 (host-128-155.meeting.ietf.org [133.93.128.155]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSS00FOJKLKHK@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Sun, 08 Nov 2009 05:11:05 -0800 (PST) Date: Sun, 08 Nov 2009 07:10:34 -0600 From: Linda Dunbar Subject: Why need single hop BFD? Does single Hop BFD requires to travese all possoble links beween the two neighbors? To: 'Dave Katz' , dward@cisco.com Message-id: <001001ca6074$ef084590$9b805d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_pE0TtUEMAUx0oh0C0T6eyg)" Thread-index: Acpf6bt91lV0hlfDT6Gq94XiiKQf+g== 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: Sun, 08 Nov 2009 13:10:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pE0TtUEMAUx0oh0C0T6eyg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave and David, Forgive me for not aware of the history of the BFD development. Reading through the "BFD for IPv4 and IPv6 (Single Hop)" (draft-ietf-bfd-v4v6-1hop-10.txt), I am not clear why single hop BFD is needed, especially for two immediately connected neighbors. There is Hello message between two immediate neighbors. If two immediate neighbors need logical layer to detect any failure between the two immediate neighbors, they can use the Hello message to achieve this purpose. Even though Hello message is from control Plane, it would be much less work for routers/LSRs to monitor the Hello messages than creating a new BFD session. Any physical media, like 802.3, SONET, DWDM wavelength all have physical failure indication. Each neighbor can also use the physical failure indication to declare the connectivity between two immediate neighbors, which is much faster than a BFD session, isn't it? It also needs less processing on the router/LSR, there won't be any proactive periodical sending BFD over the link anymore. Can you explain (or add to the document) what is the reason for having single hop BFD? Is single Hop BFD only for the Tunnel scenario? In Section 2 (Application and Limitation), the last paragraph does indicate that the transmitted packets are immediately routed back towards the sender on the interface over which they where sent if BFD Echo function is used. But when Link Aggregation is used to bundle the multiple parallel links between two neighbors, how does the network layer enforce which link to send back the "echo" message? Even if BFD ECHO can be enforced to be sent back on the same interface port so that the individual link's failure can be detected, what can this fault do when this fault can't affect the connectivity between the two immediate neighbors in control plane's view? All the links are bundled and two immediate neighbors are still connected? Thank you very much, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_pE0TtUEMAUx0oh0C0T6eyg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave and David,

 

Forgive me for not aware of the history of the BFD development. Reading through the “BFD for IPv4 and IPv6 (Single Hop)” (draft-ietf-bfd-v4v6-1hop-10.txt), I am not clear why single hop BFD is needed, especially for two immediately connected neighbors. There is Hello message between two immediate neighbors. If two immediate neighbors need logical layer to detect any failure between the two immediate neighbors, they can use the Hello message to achieve this purpose. Even though Hello message is from control Plane, it would be much less work for routers/LSRs to monitor the Hello messages than creating a new BFD session.

 

Any physical media, like 802.3, SONET, DWDM wavelength all have physical failure indication. Each neighbor can also use the physical failure indication to declare the connectivity between two immediate neighbors, which is much faster than a BFD session, isn’t it? It also needs less processing on the router/LSR, there won’t be any proactive periodical sending BFD over the link anymore.  

 

Can you explain (or add to the document) what is the reason for having single hop BFD?

Is single Hop BFD only for the Tunnel scenario?

 

In Section 2 (Application and Limitation), the last paragraph does indicate that the transmitted packets are immediately routed back towards the sender on the interface over which they where sent if BFD Echo function is used. But when Link Aggregation is used to bundle the multiple parallel links between two neighbors, how does the network layer enforce which link to send back the “echo” message?

 

Even if BFD ECHO can be enforced to be sent back on the same interface port so that the individual link’s failure can be detected, what can this fault do when this fault can’t affect the connectivity between the two immediate neighbors in control plane’s view?  All the links are bundled and two immediate neighbors are still connected?

 

Thank you very much,

 

Linda Dunbar

 

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_pE0TtUEMAUx0oh0C0T6eyg)-- From sadasgup@cisco.com Sun Nov 8 05:21:07 2009 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 4C3383A684A for ; Sun, 8 Nov 2009 05:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 fOY9VkvtS-2d for ; Sun, 8 Nov 2009 05:21:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0EFE53A681C for ; Sun, 8 Nov 2009 05:21:01 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,703,1249257600"; d="scan'208,217";a="48469979" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2009 13:21:24 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA8DLOq6015767; Sun, 8 Nov 2009 13:21:24 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 18:51:24 +0530 Received: from 10.65.74.128 ([10.65.74.128]) by XMB-BGL-414.cisco.com ([72.163.129.210]) with Microsoft Exchange Server HTTP-DAV ; Sun, 8 Nov 2009 13:21:23 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 08 Nov 2009 18:51:22 +0530 Subject: Re: Why need single hop BFD? Does single Hop BFD requires to travese all possoble links beween the two neighbors? From: sadasgup To: Linda Dunbar , "'Dave Katz'" , Message-ID: Thread-Topic: Why need single hop BFD? Does single Hop BFD requires to travese all possoble links beween the two neighbors? Thread-Index: Acpf6bt91lV0hlfDT6Gq94XiiKQf+gAjKG84 In-Reply-To: <001001ca6074$ef084590$9b805d85@china.huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340551082_39172681" X-OriginalArrivalTime: 08 Nov 2009 13:21:24.0069 (UTC) FILETIME=[5E762950:01CA6076] 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: Sun, 08 Nov 2009 13:21:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340551082_39172681 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >>Any physical media, like 802.3, SONET, DWDM wavelength all have physical failure indication. Each neighbor can also use the physical failure indicat= ion to declare the >>connectivity between two immediate neighbors, which is muc= h faster than a BFD session, isn=B9t it? It also needs less processing on the router/LSR, there won=B9t be any >>proactive periodical sending BFD over the = link anymore. =20 =20 >>Can you explain (or add to the document) what is the reason for having si= ngle hop BFD?=20 >>Is single Hop BFD only for the Tunnel scenario? Linda, Have you considered scenarios where two routers are connected via a Etherne= t switch or equivalent? Something like this - Router A -------L2 Switch-------Router B If there is a problem on one side of the connectivity (e.g. Router A to L2 Switch), the switch will hide this failure from Router B. This will impact the IGP convergence, since Router B has no indicatation of failure at the physical layer. Regards, Santanu On 08/11/09 6:40 PM, "Linda Dunbar" wrote: > Dave and David, > =20 > Forgive me for not aware of the history of the BFD development. Reading > through the =B3BFD for IPv4 and IPv6 (Single Hop)=B2 > (draft-ietf-bfd-v4v6-1hop-10.txt), I am not clear why single hop BFD is > needed, especially for two immediately connected neighbors. There is Hell= o > message between two immediate neighbors. If two immediate neighbors need > logical layer to detect any failure between the two immediate neighbors, = they > can use the Hello message to achieve this purpose. Even though Hello mess= age > is from control Plane, it would be much less work for routers/LSRs to mon= itor > the Hello messages than creating a new BFD session. > =20 > Any physical media, like 802.3, SONET, DWDM wavelength all have physical > failure indication. Each neighbor can also use the physical failure indic= ation > to declare the connectivity between two immediate neighbors, which is muc= h > faster than a BFD session, isn=B9t it? It also needs less processing on the > router/LSR, there won=B9t be any proactive periodical sending BFD over the = link > anymore. =20 > =20 > Can you explain (or add to the document) what is the reason for having si= ngle > hop BFD?=20 > Is single Hop BFD only for the Tunnel scenario? > =20 > In Section 2 (Application and Limitation), the last paragraph does indica= te > that the transmitted packets are immediately routed back towards the send= er on > the interface over which they where sent if BFD Echo function is used. Bu= t > when Link Aggregation is used to bundle the multiple parallel links betwe= en > two neighbors, how does the network layer enforce which link to send back= the > =B3echo=B2 message? > =20 > Even if BFD ECHO can be enforced to be sent back on the same interface po= rt so > that the individual link=B9s failure can be detected, what can this fault d= o > when this fault can=B9t affect the connectivity between the two immediate > neighbors in control plane=B9s view? All the links are bundled and two > immediate neighbors are still connected? > =20 > Thank you very much, > =20 > Linda Dunbar > =20 > Advanced Technology Dept, Wireline Networks, > Huawei Technologies, Inc. > =20 >=20 --B_3340551082_39172681 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Why need single hop BFD? Does single Hop BFD requires to travese= all possoble links beween the two neighbors? >>Any = physical media, like 802.3, SONET, DWDM wavelength all have physical failure= indication. Each neighbor can also use the physical failure indication to d= eclare the >>connectivity between two immediate neighbors, which is mu= ch faster than a BFD session, isn’t it? It also needs less processing = on the router/LSR, there won’t be any >>proactive periodical sen= ding BFD over the link anymore.  
 
>= ;>Can you explain (or add to the document) what= is the reason for having single hop BFD?
>>Is si= ngle Hop BFD only for the Tunnel scenario?

Linda,

Have you considered scenarios where two routers are connected via a Etherne= t switch or equivalent? Something like this -

Router A -------L2 Switch-------Router B

If there is a problem on one side of the connectivity (e.g. Router A to L2 = Switch), the switch will hide this failure from Router B. This will impact t= he IGP convergence, since  Router B has no indicatation of failure at t= he physical layer.

Regards,
Santanu



On 08/11/09 6:40 PM, "Linda Dunbar" <ldunbar@huawei.com> wrote:

Dave and David,
 
Forgive me for not aware of the history of the BFD development. Reading thr= ough the “BFD for IPv4 and IPv6 (Single Hop)” (draft-ietf-bfd-v4= v6-1hop-10.txt), I am not clear why single hop BFD is needed, especially for= two immediately connected neighbors. There is Hello message between two imm= ediate neighbors. If two immediate neighbors need logical layer to detect an= y failure between the two immediate neighbors, they can use the Hello messag= e to achieve this purpose. Even though Hello message is from control Plane, = it would be much less work for routers/LSRs to monitor the Hello messages th= an creating a new BFD session.
 
Any physical media, like 802.3, SONET, DWDM wavelength all have physical fa= ilure indication. Each neighbor can also use the physical failure indication= to declare the connectivity between two immediate neighbors, which is much = faster than a BFD session, isn’t it? It also needs less processing on = the router/LSR, there won’t be any proactive periodical sending BFD ov= er the link anymore.  
 
Can you explain (or add to the document) what is the reason for having sing= le hop BFD?
Is single Hop BFD only for the Tunnel scenario?
 
In Section 2 (Application and Limitation), the last paragraph does indicate= that the transmitted packets are immediately routed back towards the sender= on the interface over which they where sent if BFD Echo function is used. B= ut when Link Aggregation is used to bundle the multiple parallel links betwe= en two neighbors, how does the network layer enforce which link to send back= the “echo” message?
 
Even if BFD ECHO can be enforced to be sent back on the same interface port= so that the individual link’s failure can be detected, what can this = fault do when this fault can’t affect the connectivity between the two= immediate neighbors in control plane’s view?  All the links are = bundled and two immediate neighbors are still connected?
 
Thank you very much,
 
Linda Dunbar
 
Advanced Technology Dept, Wireline Networks,
Huawei Technologies, Inc.
--B_3340551082_39172681-- From dkatz@juniper.net Sun Nov 8 12:21:31 2009 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 3C6EF3A683A for ; Sun, 8 Nov 2009 12:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.378, 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 kmk+ozln-jEB for ; Sun, 8 Nov 2009 12:21:30 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id B37F63A6768 for ; Sun, 8 Nov 2009 12:21:29 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSvcoX/BbYDrkCRwEdyes+JBOa6uhlPpd@postini.com; Sun, 08 Nov 2009 12:21:55 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.375.2; Sun, 8 Nov 2009 12:18:41 -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); Sun, 8 Nov 2009 12:18:41 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 12:18:40 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 12:18:40 -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 nA8KIeM26606; Sun, 8 Nov 2009 12:18:40 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <9AF37197-30FA-421D-82D8-D3F238B74DA6@juniper.net> From: Dave Katz To: Linda Dunbar In-Reply-To: <000b01ca6074$edf3a140$9b805d85@china.huawei.com> Content-Type: multipart/alternative; boundary="Apple-Mail-11-231445448" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths? Date: Sun, 8 Nov 2009 13:18:39 -0700 References: <000b01ca6074$edf3a140$9b805d85@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Nov 2009 20:18:40.0943 (UTC) FILETIME=[A999F3F0:01CA60B0] Cc: rtg-bfd@ietf.org, dward@cisco.com 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: Sun, 08 Nov 2009 20:21:31 -0000 --Apple-Mail-11-231445448 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote: > Dave and David, > > Hope you can help me to figure out the following issues with regard =20= > to =93draft-ietf-bfd-multihop-8=94: > > Multiple BFD sessions between one pair of system was mentioned =20 > several times in the document. Is the purpose of having multiple BFD =20= > sessions between the same pair for traversing different alternative =20= > routes between the same pair? If yes, the document didn=92t say how to = =20 > enforce it. Even the different Destination/Source addresses being =20 > used can=92t guarantee that those BFD sessions will traverse different = =20 > paths. Is it out of the scope of this document? The mention of multiple BFD sessions is primarily for discussion about =20= how to demultiplex such sessions, rather than to attempt to deal with =20= the liveness of alternate paths. As you point out, there is no =20 mechanism for binding a BFD session to a path, only to its endpoints, =20= and even that is somewhat fraught with subtlety (which is why the =20 multipoint spec spends most of its time talking about how to demux BFD =20= packets.) As the whole point of BFD is to follow the same paths that data is =20 following, sharing fate as much as possible, trying to run BFD over =20 inactive alternate paths would be extremely difficult. Multiple *active* paths may exist (such as an LSP and a routed path) =20 and most of the verbiage is to provide a palette of mechanisms that =20 can be used to sort the BFD sessions out. > > What are the benefits of enforcing BFD sessions between a pair of =20 > nodes to traverse alternative paths between them? I guess by doing =20 > so, the two nodes get to know how many different paths are between =20 > them. Who will use this information? See above. > > Your BFD base draft (draft-ietf-bfd-base-09) does state that one of =20= > the goals of BFD is to traverse all possible paths between two =20 > nodes. Does it include the alternative paths between specific =20 > Ingress and Egress? I don't believe that it ever says such a thing, and it isn't possible =20= in any case. Can you point at the text that gave you this impression? > > Suggestion if you do think it is necessary to traverse all the =20 > alternative paths between two nodes as indicated in the BFD base =20 > document: > Is it possible to create a special BFD session that all intermediate =20= > nodes will forward the BFD to all the paths in the ECMP group? =20 > Whenever it happens, the node will mark a bit to the Discriminator =20 > field. By receiving all the BFD frames with different Discriminator =20= > value, the egress node can figure out how many alternative paths are =20= > between them. See above. > > > Hope to have more discussion in Hiroshima. > > Linda Dunbar > > Advanced Technology Dept, Wireline Networks, > Huawei Technologies, Inc. > --Apple-Mail-11-231445448 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable
On Nov 8, 2009, = at 6:10 AM, Linda Dunbar wrote:

 
  • Multiple BFD sessions = between one pair of system was mentioned several times in the document. = Is the purpose of having multiple BFD sessions between the same pair for = traversing different alternative routes between the same pair? If yes, = the document didn=92t say how to enforce it. Even the different = Destination/Source addresses being used can=92t guarantee that those BFD = sessions will traverse different paths. Is it out of the scope of this = document?
<= /div>

The mention of multiple BFD = sessions is primarily for discussion about how to demultiplex such = sessions, rather than to attempt to deal with the liveness of alternate = paths.  As you point out, there is no mechanism for binding a BFD = session to a path, only to its endpoints, and even that is somewhat = fraught with subtlety (which is why the multipoint spec spends most of = its time talking about how to demux BFD = packets.)

As the whole point of BFD is to = follow the same paths that data is following, sharing fate as much as = possible, trying to run BFD over inactive alternate paths would be = extremely difficult.

Multiple *active* paths = may exist (such as an LSP and a routed path) and most of the verbiage is = to provide a palette of mechanisms that can be used to sort the BFD = sessions out.

  • What are the benefits of = enforcing BFD sessions between a pair of nodes to traverse alternative = paths between them? I guess by doing so, the two nodes get to know how = many different paths are between them. Who will use this = information?

See = above.

  • Your BFD base draft = (draft-ietf-bfd-base-09) does state that one of the goals of BFD is to = traverse all possible paths between two nodes. Does it include the = alternative paths between specific Ingress and = Egress?

I don't believe that it ever says = such a thing, and it isn't possible in any case.  Can you point at = the text that gave you this = impression?


  • Suggestion if you do = think it is necessary to traverse all the alternative paths between two = nodes as indicated in the BFD base = document:
    • Is it possible to create a special BFD session = that all intermediate nodes will forward the BFD to all the paths in the = ECMP group? Whenever it happens, the node will mark a bit to the = Discriminator field. By receiving all the BFD frames with different = Discriminator value, the egress node can figure out how many alternative = paths are between = them.
=

See = above.

 
Hope to have more discussion in Hiroshima.
 
Linda Dunbar
 
Advanced = Technology Dept, Wireline Networks,
Huawei Technologies, Inc.
X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Nov 2009 22:32:45.0777 (UTC) FILETIME=[64B23410:01CA60C3] Cc: rtg-bfd@ietf.org, dward@cisco.com 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: Sun, 08 Nov 2009 22:36:42 -0000 --Apple-Mail-12-239490069 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote: > Dave and David, > > Forgive me for not aware of the history of the BFD development. =20 > Reading through the =93BFD for IPv4 and IPv6 (Single Hop)=94 = (draft-ietf-=20 > bfd-v4v6-1hop-10.txt), I am not clear why single hop BFD is needed, =20= > especially for two immediately connected neighbors. There is Hello =20 > message between two immediate neighbors. Of course, the entire point of 1hop is to run on immediately connected =20= neighbors. > If two immediate neighbors need logical layer to detect any failure =20= > between the two immediate neighbors, they can use the Hello message =20= > to achieve this purpose. Even though Hello message is from control =20 > Plane, it would be much less work for routers/LSRs to monitor the =20 > Hello messages than creating a new BFD session. (a) There may not be any Hello protocol running between adjacent =20 nodes. (A number of folks are using BFD to protect static routes.) (b) The existing Hello protocols in IGPs have a number of failings, =20 which are spelled out elsewhere. (c) BFD is modeled to run in the data plane (though of course =20 implementors can put it wherever they want.) In particular, it's a =20 goal to make it possible to continue to forward traffic (and thus to =20 protect the forwarding path with BFD) even when the control plane is =20 resetting or having other issues. > > Any physical media, like 802.3, SONET, DWDM wavelength all have =20 > physical failure indication. Each neighbor can also use the physical =20= > failure indication to declare the connectivity between two immediate =20= > neighbors, which is much faster than a BFD session, isn=92t it? It =20 > also needs less processing on the router/LSR, there won=92t be any =20 > proactive periodical sending BFD over the link anymore. There is no system-to-system failure indication in Ethernet, =20 particularly when switches are involved (which is *always* at this =20 point, unless you know someone still using yellow hose and vampire =20 taps) which was a driving reason for doing BFD in the first place. =20 Those of us in the Big Iron business saw lots of Ethernet showing up =20 in POP interconnects, and waiting for IGPs to time out was causing =20 huge traffic losses. > > Can you explain (or add to the document) what is the reason for =20 > having single hop BFD? > Is single Hop BFD only for the Tunnel scenario? =46rom the spec: One very desirable application for BFD [BFD] is to track IPv4 and IPv6 connectivity between directly-connected systems. This could be used to supplement the detection mechanisms in routing protocols, or to monitor router-host connectivity, among other applications. ... This application of BFD can be used by any pair of systems communicating via IPv4 and/or IPv6 across a single IP hop that is associated with an incoming interface. This includes, but is not limited to, physical media, virtual circuits, and tunnels. It's primarily for router interconnection, which given the authors' =20 employers makes sense. But it can be used in any single-hop scenario =20= that fits the deployment requirements. > > In Section 2 (Application and Limitation), the last paragraph does =20 > indicate that the transmitted packets are immediately routed back =20 > towards the sender on the interface over which they where sent if =20 > BFD Echo function is used. But when Link Aggregation is used to =20 > bundle the multiple parallel links between two neighbors, how does =20 > the network layer enforce which link to send back the =93echo=94 = message? It can't, obviously. There's no magic. One could argue that it =20 shouldn't, as it is monitoring the liveness of the L3 path, not the =20 individual links. The theory at the time was that BFD could be used =20 at L2 across the individual links if someone wanted to do that, but =20 the Ethernet folks wanted to roll their own OAM or somesuch. > > Even if BFD ECHO can be enforced to be sent back on the same =20 > interface port so that the individual link=92s failure can be =20 > detected, what can this fault do when this fault can=92t affect the =20= > connectivity between the two immediate neighbors in control plane=92s =20= > view? All the links are bundled and two immediate neighbors are =20 > still connected? See above. The 1hop spec is explicitly an L3 play; aggregate links =20 are just single links in that case, so from BFD's standpoint the =20 failure of an individual link will be invisible. --Dave > --Apple-Mail-12-239490069 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable
On Nov 8, 2009, = at 6:10 AM, Linda Dunbar wrote:

If = two immediate neighbors need logical layer to detect any failure between = the two immediate neighbors, they can use the Hello message to achieve = this purpose. Even though Hello message is from control Plane, it would = be much less work for routers/LSRs to monitor the Hello messages than = creating a new BFD = session.

(a)  There may not be any Hello protocol running between adjacent = nodes.  (A number of folks are using BFD to protect static = routes.)
(b)  The existing Hello protocols in IGPs have a = number of failings, which are spelled out elsewhere.
(c) =  BFD is modeled to run in the data plane (though of course = implementors can put it wherever they want.)  In particular, it's a = goal to make it possible to continue to forward traffic (and thus to = protect the forwarding path with BFD) even when the control plane is = resetting or having other issues.

Any = physical media, like 802.3, SONET, DWDM wavelength all have physical = failure indication. Each neighbor can also use the physical failure = indication to declare the connectivity between two immediate neighbors, = which is much faster than a BFD session, isn=92t it? It also needs less = processing on the router/LSR, there won=92t be any proactive periodical = sending BFD over the link anymore. =  

T= here is no system-to-system failure indication in Ethernet, particularly = when switches are involved (which is *always* at this point, unless you = know someone still using yellow hose and vampire taps) which was a = driving reason for doing BFD in the first place.  Those of us in = the Big Iron business saw lots of Ethernet showing up in POP = interconnects, and waiting for IGPs to time out was causing huge traffic = losses.

Can = you explain (or add to the document) what is the reason for having = single hop BFD?
Is = single Hop BFD only for the Tunnel = scenario?

=46rom the spec:

   One very = desirable application for BFD [BFD] is to track IPv4 = and
   IPv6 connectivity between directly-connected = systems.  This could be
   used to supplement = the detection mechanisms in routing protocols, or
   = to monitor router-host connectivity, among other = applications.
...
   This application = of BFD can be used by any pair of systems
   = communicating via IPv4 and/or IPv6 across a single IP hop that = is
   associated with an incoming interface. =  This includes, but is not
   limited to, = physical media, virtual circuits, and = tunnels.

It's primarily for router = interconnection, which given the authors' employers makes sense. =  But it can be used in any single-hop scenario that fits the = deployment requirements.

In = Section 2 (Application and Limitation), the last paragraph does indicate = that the transmitted packets are immediately routed back towards the = sender on the interface over which they where sent if BFD Echo function = is used. But when Link Aggregation is used to bundle the multiple = parallel links between two neighbors, how does the network layer enforce = which link to send back the =93echo=94 = message?

It = can't, obviously.  There's no magic.  One could argue that it = shouldn't, as it is monitoring the liveness of the L3 path, not the = individual links.  The theory at the time was that BFD could be = used at L2 across the individual links if someone wanted to do that, but = the Ethernet folks wanted to roll their own OAM or = somesuch.

 
Even if BFD ECHO can be enforced to be sent back = on the same interface port so that the individual link=92s failure can = be detected, what can this fault do when this fault can=92t affect the = connectivity between the two immediate neighbors in control plane=92s = view?  All the links are bundled and two immediate neighbors are = still = connected?

See = above.  The 1hop spec is explicitly an L3 play;  aggregate = links are just single links in that case, so from BFD's standpoint the = failure of an individual link will be = invisible.

--Dave

To: 'Dave Katz' Message-id: <009201ca60d6$64caa370$9b805d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_m8uzxzdFNTUQ5mu2RMhGPg)" Thread-index: AcpgsR+ntsvC6JhBQb+zDQ9h+GkFCwAJSafg References: <000b01ca6074$edf3a140$9b805d85@china.huawei.com> <9AF37197-30FA-421D-82D8-D3F238B74DA6@juniper.net> Cc: rtg-bfd@ietf.org, dward@cisco.com 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, 09 Nov 2009 00:48:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_m8uzxzdFNTUQ5mu2RMhGPg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave, Thank you very much for the reply. What do you think of my suggestion? o Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them. Linda Dunbar _____ From: Dave Katz [mailto:dkatz@juniper.net] Sent: Sunday, November 08, 2009 2:19 PM To: Linda Dunbar Cc: dward@cisco.com; rtg-bfd@ietf.org Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths? On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote: Dave and David, Hope you can help me to figure out the following issues with regard to "draft-ietf-bfd-multihop-8": * Multiple BFD sessions between one pair of system was mentioned several times in the document. Is the purpose of having multiple BFD sessions between the same pair for traversing different alternative routes between the same pair? If yes, the document didn't say how to enforce it. Even the different Destination/Source addresses being used can't guarantee that those BFD sessions will traverse different paths. Is it out of the scope of this document? The mention of multiple BFD sessions is primarily for discussion about how to demultiplex such sessions, rather than to attempt to deal with the liveness of alternate paths. As you point out, there is no mechanism for binding a BFD session to a path, only to its endpoints, and even that is somewhat fraught with subtlety (which is why the multipoint spec spends most of its time talking about how to demux BFD packets.) As the whole point of BFD is to follow the same paths that data is following, sharing fate as much as possible, trying to run BFD over inactive alternate paths would be extremely difficult. Multiple *active* paths may exist (such as an LSP and a routed path) and most of the verbiage is to provide a palette of mechanisms that can be used to sort the BFD sessions out. * * What are the benefits of enforcing BFD sessions between a pair of nodes to traverse alternative paths between them? I guess by doing so, the two nodes get to know how many different paths are between them. Who will use this information? See above. * * Your BFD base draft (draft-ietf-bfd-base-09) does state that one of the goals of BFD is to traverse all possible paths between two nodes. Does it include the alternative paths between specific Ingress and Egress? I don't believe that it ever says such a thing, and it isn't possible in any case. Can you point at the text that gave you this impression? * * Suggestion if you do think it is necessary to traverse all the alternative paths between two nodes as indicated in the BFD base document: o Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them. See above. o Hope to have more discussion in Hiroshima. Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_m8uzxzdFNTUQ5mu2RMhGPg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave,

 

Thank you very much for the reply.

 

What do you think of my suggestion?

o        Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them.

 

Linda Dunbar

From: Dave Katz [mailto:dkatz@juniper.net]
Sent: Sunday, November 08, 2009 2:19 PM
To: Linda Dunbar
Cc: dward@cisco.com; rtg-bfd@ietf.org
Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths?

 

 

On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote:



Dave and David,

 

Hope you can help me to figure out the following issues with regard to “draft-ietf-bfd-multihop-8”:

 

·         Multiple BFD sessions between one pair of system was mentioned several times in the document. Is the purpose of having multiple BFD sessions between the same pair for traversing different alternative routes between the same pair? If yes, the document didn’t say how to enforce it. Even the different Destination/Source addresses being used can’t guarantee that those BFD sessions will traverse different paths. Is it out of the scope of this document?

 

The mention of multiple BFD sessions is primarily for discussion about how to demultiplex such sessions, rather than to attempt to deal with the liveness of alternate paths.  As you point out, there is no mechanism for binding a BFD session to a path, only to its endpoints, and even that is somewhat fraught with subtlety (which is why the multipoint spec spends most of its time talking about how to demux BFD packets.)

 

As the whole point of BFD is to follow the same paths that data is following, sharing fate as much as possible, trying to run BFD over inactive alternate paths would be extremely difficult.

 

Multiple *active* paths may exist (such as an LSP and a routed path) and most of the verbiage is to provide a palette of mechanisms that can be used to sort the BFD sessions out.



·          

·         What are the benefits of enforcing BFD sessions between a pair of nodes to traverse alternative paths between them? I guess by doing so, the two nodes get to know how many different paths are between them. Who will use this information?

 

See above.



·          

·         Your BFD base draft (draft-ietf-bfd-base-09) does state that one of the goals of BFD is to traverse all possible paths between two nodes. Does it include the alternative paths between specific Ingress and Egress?

 

I don't believe that it ever says such a thing, and it isn't possible in any case.  Can you point at the text that gave you this impression?

 



·          

·         Suggestion if you do think it is necessary to traverse all the alternative paths between two nodes as indicated in the BFD base document:

o        Is it possible to create a special BFD session that all intermediate nodes will forward the BFD to all the paths in the ECMP group? Whenever it happens, the node will mark a bit to the Discriminator field. By receiving all the BFD frames with different Discriminator value, the egress node can figure out how many alternative paths are between them.

 

See above.



o         

 

Hope to have more discussion in Hiroshima.

 

Linda Dunbar

 

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

 

--Boundary_(ID_m8uzxzdFNTUQ5mu2RMhGPg)-- From dkatz@juniper.net Sun Nov 8 19:42:51 2009 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 10E3E28C129 for ; Sun, 8 Nov 2009 19:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 DOrnWK7DwO6W for ; Sun, 8 Nov 2009 19:42:49 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 436A828C126 for ; Sun, 8 Nov 2009 19:42:49 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSveP0SvqWmSUHuvFE0Sa3O6Sbkp590wt@postini.com; Sun, 08 Nov 2009 19:43:15 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.375.2; Sun, 8 Nov 2009 19:41:47 -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); Sun, 8 Nov 2009 19:41:47 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 19:41:47 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 19:41:46 -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 nA93fjM35367; Sun, 8 Nov 2009 19:41:45 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Linda Dunbar In-Reply-To: <009201ca60d6$64caa370$9b805d85@china.huawei.com> Content-Type: multipart/alternative; boundary="Apple-Mail-14-258030732" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths? Date: Sun, 8 Nov 2009 20:41:44 -0700 References: <000b01ca6074$edf3a140$9b805d85@china.huawei.com> <9AF37197-30FA-421D-82D8-D3F238B74DA6@juniper.net> <009201ca60d6$64caa370$9b805d85@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 03:41:46.0195 (UTC) FILETIME=[8FA57A30:01CA60EE] Cc: rtg-bfd@ietf.org, dward@cisco.com 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, 09 Nov 2009 03:42:51 -0000 --Apple-Mail-14-258030732 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 8, 2009, at 5:48 PM, Linda Dunbar wrote: > Dave, > > Thank you very much for the reply. > > What do you think of my suggestion? > o Is it possible to create a special BFD session that all =20 > intermediate nodes will forward the BFD to all the paths in the ECMP =20= > group? Whenever it happens, the node will mark a bit to the =20 > Discriminator field. By receiving all the BFD frames with different =20= > Discriminator value, the egress node can figure out how many =20 > alternative paths are between them. Doing so would probably require reprogramming forwarding hardware, and =20= by its nature would stop being BFD as we know it. Mapping out all possible network paths is well outside the scope of =20 the specification, and it doesn't seem as though BFD is particularly =20 suited for this task. It sounds a bit like Token Ring Explorer packets (showing my age) but =20= a mechanism to discover topology by brute force would require =20 forwarding changes or some other games to be played. Within a routing domain, such things can be determined analytically =20 from link state databases, but this doesn't help in the larger picture. In any case, it doesn't sound like anything BFD ought to be involved in. --Dave > > Linda Dunbar > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Sunday, November 08, 2009 2:19 PM > To: Linda Dunbar > Cc: dward@cisco.com; rtg-bfd@ietf.org > Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme =20 > to enforce BFD sessions traversing different alternative paths? > > > On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote: > > > Dave and David, > > Hope you can help me to figure out the following issues with regard =20= > to =93draft-ietf-bfd-multihop-8=94: > > =B7 Multiple BFD sessions between one pair of system was =20 > mentioned several times in the document. Is the purpose of having =20 > multiple BFD sessions between the same pair for traversing different =20= > alternative routes between the same pair? If yes, the document =20 > didn=92t say how to enforce it. Even the different Destination/Source =20= > addresses being used can=92t guarantee that those BFD sessions will =20= > traverse different paths. Is it out of the scope of this document? > > The mention of multiple BFD sessions is primarily for discussion =20 > about how to demultiplex such sessions, rather than to attempt to =20 > deal with the liveness of alternate paths. As you point out, there =20= > is no mechanism for binding a BFD session to a path, only to its =20 > endpoints, and even that is somewhat fraught with subtlety (which is =20= > why the multipoint spec spends most of its time talking about how to =20= > demux BFD packets.) > > As the whole point of BFD is to follow the same paths that data is =20 > following, sharing fate as much as possible, trying to run BFD over =20= > inactive alternate paths would be extremely difficult. > > Multiple *active* paths may exist (such as an LSP and a routed path) =20= > and most of the verbiage is to provide a palette of mechanisms that =20= > can be used to sort the BFD sessions out. > > > =B7 > =B7 What are the benefits of enforcing BFD sessions between a =20= > pair of nodes to traverse alternative paths between them? I guess by =20= > doing so, the two nodes get to know how many different paths are =20 > between them. Who will use this information? > > See above. > > > =B7 > =B7 Your BFD base draft (draft-ietf-bfd-base-09) does state =20= > that one of the goals of BFD is to traverse all possible paths =20 > between two nodes. Does it include the alternative paths between =20 > specific Ingress and Egress? > > I don't believe that it ever says such a thing, and it isn't =20 > possible in any case. Can you point at the text that gave you this =20= > impression? > > > > =B7 > =B7 Suggestion if you do think it is necessary to traverse all = =20 > the alternative paths between two nodes as indicated in the BFD base =20= > document: > o Is it possible to create a special BFD session that all =20 > intermediate nodes will forward the BFD to all the paths in the ECMP =20= > group? Whenever it happens, the node will mark a bit to the =20 > Discriminator field. By receiving all the BFD frames with different =20= > Discriminator value, the egress node can figure out how many =20 > alternative paths are between them. > > See above. > > > o > > Hope to have more discussion in Hiroshima. > > Linda Dunbar > > Advanced Technology Dept, Wireline Networks, > Huawei Technologies, Inc. > > --Apple-Mail-14-258030732 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable
On Nov 8, 2009, = at 5:48 PM, Linda Dunbar wrote:

Dave,
Thank you very much for the = reply.
 
What do you think of my = suggestion?
 <= /font>Is it possible to create a special BFD session = that all intermediate nodes will forward the BFD to all the paths in the = ECMP group? Whenever it happens, the node will mark a bit to the = Discriminator field. By receiving all the BFD frames with different = Discriminator value, the egress node can figure out how many alternative = paths are between them.

Doing so would probably require = reprogramming forwarding hardware, and by its nature would stop being = BFD as we know it.

Mapping out all possible = network paths is well outside the scope of the specification, and it = doesn't seem as though BFD is particularly suited for this = task.

It sounds a bit like Token Ring Explorer = packets (showing my age) but a mechanism to discover topology by brute = force would require forwarding changes or some other games to be = played.

Within a routing domain, such things = can be determined analytically from link state databases, but this = doesn't help in the larger picture.

In any = case, it doesn't sound like anything BFD ought to be involved = in.

--Dave

 
Linda = Dunbar
From: Dave Katz = [mailto:dkatz@juniper.net] 
Sent: Sunday, November 08, 2009 = 2:19 PM
To: Linda Dunbar
Cc: dward@cisco.com; rtg-bfd@ietf.org
Subject: Re: Should the = "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions = traversing different alternative = paths?
On Nov 8, = 2009, at 6:10 AM, Linda Dunbar = wrote:
Dave and = David,
Hope you = can help me to figure out the following issues with regard to = =93draft-ietf-bfd-multihop-8=94:
=B7 <= /font>Multiple BFD sessions between one pair of system = was mentioned several times in the document. Is the purpose of having = multiple BFD sessions between the same pair for traversing different = alternative routes between the same pair? If yes, the document didn=92t = say how to enforce it. Even the different Destination/Source addresses = being used can=92t guarantee that those BFD sessions will traverse = different paths. Is it out of the scope of this = document?The mention = of multiple BFD sessions is primarily for discussion about how to = demultiplex such sessions, rather than to attempt to deal with the = liveness of alternate paths.  As you point out, there is no = mechanism for binding a BFD session to a path, only to its endpoints, = and even that is somewhat fraught with subtlety (which is why the = multipoint spec spends most of its time talking about how to demux BFD = packets.)
 
As the whole point of BFD is to follow the same paths that data = is following, sharing fate as much as possible, trying to run BFD over = inactive alternate paths would be extremely = difficult.
 
Multiple *active* paths may exist (such as an LSP and a routed = path) and most of the verbiage is to provide a palette of mechanisms = that can be used to sort the BFD sessions = out.
=B7 <= /font>=B7 <= /font>What are the benefits of enforcing BFD sessions = between a pair of nodes to traverse alternative paths between them? I = guess by doing so, the two nodes get to know how many different paths = are between them. Who will use this information?See = above.
=B7 <= /font>=B7 <= /font>Your BFD base draft (draft-ietf-bfd-base-09) does = state that one of the goals of BFD is to traverse all possible paths = between two nodes. Does it include the alternative paths between = specific Ingress and Egress?I don't = believe that it ever says such a thing, and it isn't possible in any = case.  Can you point at the text that gave you this = impression?
 


=B7 <= /font>=B7 <= /font>Suggestion if you do think it is necessary to = traverse all the alternative paths between two nodes as indicated in the = BFD base document:
o <= /font>Is it possible to create a special BFD session = that all intermediate nodes will forward the BFD to all the paths in the = ECMP group? Whenever it happens, the node will mark a bit to the = Discriminator field. By receiving all the BFD frames with different = Discriminator value, the egress node can figure out how many alternative = paths are between them.See = above.
o <= /font>
Hope to = have more discussion in Hiroshima.
Linda = Dunbar
Advanced = Technology Dept, Wireline Networks,Huawei = Technologies, Inc. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:19:37 -0000 Hi, This is regarding the BFD MIB version 07. I noticed that the sessions table has the objects bfdSessDesiredMinTxInterval and other session related parameters. The issue with this is that because the sessions in BFD are actually triggered by protocols outside BFD and in BFD we are unaware of which sessions will be created, changing the values of the objects when the row create is triggered dynamically from other protocols is not possible. The way to solve the issue is to use some entity tables/ structures just like we have it in LDP. So we could have entities for each interface as well as each multihop session. We could seperatly create the entity structures and any session belonging to an entity would inherit the property configured for the entity. Looking at the Cisco CLI it seems to take the parameters on the interface basis too. Why is the MIB not aligned to the CLI (even though the authors themselves are from the company)? Can the authors please comment on it? Thanks, Vishwas From nitinb@juniper.net Tue Nov 10 13:28:31 2009 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 2410F3A682D for ; Tue, 10 Nov 2009 13:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3OwbNCZxpLeD for ; Tue, 10 Nov 2009 13:28:30 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 390283A67C2 for ; Tue, 10 Nov 2009 13:28:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSvnbF8AXl5X44pTw8maKKpT2CbZ7LJ/V@postini.com; Tue, 10 Nov 2009 13:28:58 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Nov 2009 13:24:28 -0800 From: Nitin Bahadur To: Vishwas Manral , "rtg-bfd@ietf.org" Date: Tue, 10 Nov 2009 13:22:54 -0800 Subject: Re: BFD MIB Thread-Topic: BFD MIB Thread-Index: AcpiOtH25qUk/y8QSzqALAV/n5jRWAAESUSN Message-ID: In-Reply-To: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 10 Nov 2009 21:28:31 -0000 > Looking at the Cisco CLI it seems to take the parameters on the > interface basis too. Why is the MIB not aligned to the CLI (even > though the authors themselves are from the company)? > Can the authors please comment on it? Please take this discussion offline. This is not appropriate for the list. Thanks Nitin From vishwas.ietf@gmail.com Tue Nov 10 13:30:52 2009 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 C14CC3A6A44 for ; Tue, 10 Nov 2009 13:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 AKWOF1hcuGxC for ; Tue, 10 Nov 2009 13:30:51 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id AB8DD3A682D for ; Tue, 10 Nov 2009 13:30:51 -0800 (PST) Received: by yxe30 with SMTP id 30so472821yxe.29 for ; Tue, 10 Nov 2009 13:31:16 -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=KQdDmMWDawZO1SfDSGS/mwJbJjWxt/nh5UDTP6K/02A=; b=vWgvcSbmlUoVhOdJLHXqWUi9OMxmGOlD24RvoZQl2KW9Cj+FJSLViDrO5IfAtdX7hS 3NKgoQ11/qqK6ujTdwGCzHLY0CklROThf9eT+NMPjtPP2baCcgzRv9d5oKTeOhvYP6M2 ztbZ4CCpnw/0nZi1OBaixuAoTRYnmLvjH5HFg= 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=mLXHszvqXnkAXhCBYb5wHUozTO64f99O56wHuA8KDJcoB9p5BKcclE8HagzYmgoG95 YU1Mz6Iac15pmzV3rW9Rlu3eVtf4P4gPAygzjvKCsJtZZ9WihE0YZCPmdHH0S2fzxGQP yi+BorJI5CScIU15vo+Ex99qSEOTZoXXKeWrk= MIME-Version: 1.0 Received: by 10.150.76.4 with SMTP id y4mr1174644yba.166.1257888676219; Tue, 10 Nov 2009 13:31:16 -0800 (PST) In-Reply-To: References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> Date: Tue, 10 Nov 2009 13:31:16 -0800 Message-ID: <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Nitin Bahadur Content-Type: text/plain; charset=ISO-8859-1 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, 10 Nov 2009 21:30:52 -0000 Hi Nitin, Thanks for the comment. My point is the difference in the MIB and the way to realize the functionality. As an example I have taken the Cisco CLI. I am sure you are not against a discussion on the MIB. Thanks, Vishwas On Tue, Nov 10, 2009 at 1:22 PM, Nitin Bahadur wrote: > >> Looking at the Cisco CLI it seems to take the parameters on the >> interface basis too. Why is the MIB not aligned to the CLI (even >> though the authors themselves are from the company)? > >> Can the authors please comment on it? > > Please take this discussion offline. This is not appropriate for the list. > > Thanks > Nitin > From vishwas.ietf@gmail.com Tue Nov 10 13:44:08 2009 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 696703A6B8A for ; Tue, 10 Nov 2009 13:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 WsJGg52vV2fZ for ; Tue, 10 Nov 2009 13:44:07 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 930D63A6B83 for ; Tue, 10 Nov 2009 13:44:07 -0800 (PST) Received: by gxk28 with SMTP id 28so430836gxk.9 for ; Tue, 10 Nov 2009 13:44:31 -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=bFFVusxZwmy8SO+1UxchIgfPnPGLMg/Wpcpk+Tk28yA=; b=g4fRhU3XmNTe/Z+HBMIk3KUHwGsF3qb2ETmhAhaIXSz3sM2DNx70AMeCgFiLVerkQF s+osfCfpAPVG1gCAoeu0atgvmd9aqf1gN3zn8ygEjuCX/PsgIerdUUH4vMfiGqgYA0bN ItSqS+AHa/ndvWtC9uy3xHT4YniSym3mXTB3M= 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=lJIp+61sjBFk/6jhQgTyR2f1ZgbHMtNr8YYNrVh/I4fwYNDicxBkEKbJx8tHLYP/9T iTAWQU2nPGz7Pw0UrgLZhXpd0NPvffHmrnyFmhDbGez88+8LHUZCO8u8/T0D6d3LvSlr 1aMMrrxn5r9J/oEbausnG6IJjAqlF6iklaG4A= MIME-Version: 1.0 Received: by 10.151.25.6 with SMTP id c6mr1171974ybj.243.1257889471289; Tue, 10 Nov 2009 13:44:31 -0800 (PST) In-Reply-To: <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> Date: Tue, 10 Nov 2009 13:44:31 -0800 Message-ID: <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Nitin Bahadur Content-Type: text/plain; charset=ISO-8859-1 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, 10 Nov 2009 21:44:08 -0000 Hi Nitin, I was eager to know your view about how to configure parameters in sessions through SNMP and if you agreed having an Entity based LDP like approach may be better. Thanks, Vishwas On Tue, Nov 10, 2009 at 1:31 PM, Vishwas Manral wrote: > Hi Nitin, > > Thanks for the comment. > > My point is the difference in the MIB and the way to realize the > functionality. As an example I have taken the Cisco CLI. I am sure you > are not against a discussion on the MIB. > > Thanks, > Vishwas > > On Tue, Nov 10, 2009 at 1:22 PM, Nitin Bahadur wrote: >> >>> Looking at the Cisco CLI it seems to take the parameters on the >>> interface basis too. Why is the MIB not aligned to the CLI (even >>> though the authors themselves are from the company)? >> >>> Can the authors please comment on it? >> >> Please take this discussion offline. This is not appropriate for the list. >> >> Thanks >> Nitin >> > From dward@cisco.com Tue Nov 10 16:53:18 2009 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 72DE028C22C for ; Tue, 10 Nov 2009 16:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 69NQ2k-Z+TJ7 for ; Tue, 10 Nov 2009 16:53:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D9A6028C20C for ; Tue, 10 Nov 2009 16:53:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208";a="429548260" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 00:53:45 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB0riK6016304; Wed, 11 Nov 2009 00:53:45 GMT Subject: Re: BFD MIB Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: David Ward In-Reply-To: <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> Date: Tue, 10 Nov 2009 18:53:44 -0600 Content-Transfer-Encoding: 7bit Message-Id: <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> To: Vishwas Manral X-Mailer: Apple Mail (2.1076) Cc: "rtg-bfd@ietf.org" , David Ward 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, 11 Nov 2009 00:53:18 -0000 Leaving aside the questions specific to a vendor, the MIB is out of date after the changes to the specs following IESG review/comments and needs another revision. -DWard From vishwas.ietf@gmail.com Tue Nov 10 18:45:10 2009 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 D428F3A68A9 for ; Tue, 10 Nov 2009 18:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 svazHdd3-L5b for ; Tue, 10 Nov 2009 18:45:10 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 1574E3A684C for ; Tue, 10 Nov 2009 18:45:10 -0800 (PST) Received: by yxe30 with SMTP id 30so713450yxe.29 for ; Tue, 10 Nov 2009 18:45:35 -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=s94rR6gUjp+/44jimYkGUn6zOWGB3o7vDZ9juunoizo=; b=h5iG1Q+UCiM/ThHDZoXkxQfpUC1S/r72hBZcmOZpX7d0UM/LnynGIknlXWTXqjefgt iwgS3kQ18Sk+k5cs0A5U9ML+l1qGzQNEjZP/idOdV9trVoHcmjhFBmpr1WGFNvW+QPes sVPbBxU+LmVTEgwTT2dxtKrLHmP5MZI9l8fA4= 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=FtNd5x9nPlfM59SwbVWEcuK/oWTFwwglknPaEikcS8ec+/dCA59yiUdW2IiHfFbmH6 5WejXzFUy7Wsw/yGCfgj22B3ytPYL/Qggq3wyLY4JbmkvGlZGxV7spYCdmN7kZkl+k1x Dj2wifmLUIIvy45ACe4bD+FlNbhplLbjrJ40Q= MIME-Version: 1.0 Received: by 10.150.28.4 with SMTP id b4mr1701742ybb.124.1257907534967; Tue, 10 Nov 2009 18:45:34 -0800 (PST) In-Reply-To: <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> Date: Tue, 10 Nov 2009 18:45:34 -0800 Message-ID: <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: David Ward Content-Type: text/plain; charset=ISO-8859-1 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, 11 Nov 2009 02:45:10 -0000 Hi David, Thanks. I think some of the comments on the list earlier have also not been incorporated either. As the MIB has expired I am not sure if the authors need help closing the MIB. Do let me know if you need help closing the document? Thanks again, Vishwas On Tue, Nov 10, 2009 at 4:53 PM, David Ward wrote: > Leaving aside the questions specific to a vendor, the MIB is out of date > after the changes to the specs following IESG review/comments and needs > another revision. > > -DWard > > > From manav.bhatia@alcatel-lucent.com Wed Nov 11 02:52:12 2009 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 2D8A028C16A for ; Wed, 11 Nov 2009 02:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 Y26JsTOaizU5 for ; Wed, 11 Nov 2009 02:52:11 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 60EA028C14A for ; Wed, 11 Nov 2009 02:52:11 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nABAqdsG020214 for ; Wed, 11 Nov 2009 04:52:39 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nABAqbD1011285 for ; Wed, 11 Nov 2009 04:52:38 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nABAtHvB013194 for ; Wed, 11 Nov 2009 18:55:17 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 11 Nov 2009 16:22:36 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Wed, 11 Nov 2009 16:22:35 +0530 Subject: BFD Generic Cryptographic Authentication Thread-Topic: BFD Generic Cryptographic Authentication Thread-Index: AcpivROc5phjD2sfTvSczRxHdHkynA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350A681DDAAC@INBANSXCHMBSA1.in.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 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, 11 Nov 2009 10:54:50 -0000 Hi, We have posted the updated version of "BFD Generic Cryptographic Authentica= tion" and its available online. http://www.ietf.org/id/draft-bhatia-bfd-crypto-auth-01.txt Abstract=20 =20 This document proposes an extension for Bidirectional Forwarding Detection = (BFD) to allow the use of any cryptographic authentication algorithm in add= ition to the already documented authentication schemes, described in the ba= se specification. =20 =20 Although this document has been written specifically to introduce two new A= uthentication types it describes how BFD can use National Institute of Stan= dards and Technology (NIST) Secure Hash Standard family of algorithms (SHS)= to authenticate the control packets, the method described in this document= is generic and can be used to extend BFD to support any cryptographic hash= function in the future.=20 Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From tnadeau@lucidvision.com Wed Nov 11 04:06:17 2009 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 589EF3A6A98 for ; Wed, 11 Nov 2009 04:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 LgmmPVn8sXaH for ; Wed, 11 Nov 2009 04:06:16 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 7308A3A6A9F for ; Wed, 11 Nov 2009 04:06:16 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id E9A2141C2255; Wed, 11 Nov 2009 07:06:41 -0500 (EST) Subject: Re: BFD MIB Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> Date: Wed, 11 Nov 2009 07:06:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> To: Vishwas Manral X-Mailer: Apple Mail (2.1077) Cc: "rtg-bfd@ietf.org" , David Ward 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, 11 Nov 2009 12:06:17 -0000 Thanks for the offer, but we have updated the document but = missed the update deadline.=20 --Tom > Hi David, >=20 > Thanks. I think some of the comments on the list earlier have also not > been incorporated either. As the MIB has expired I am not sure if the > authors need help closing the MIB. Do let me know if you need help > closing the document? >=20 > Thanks again, > Vishwas >=20 > On Tue, Nov 10, 2009 at 4:53 PM, David Ward wrote: >> Leaving aside the questions specific to a vendor, the MIB is out of = date >> after the changes to the specs following IESG review/comments and = needs >> another revision. >>=20 >> -DWard >>=20 >>=20 >>=20 >=20 From vishwas.ietf@gmail.com Wed Nov 11 08:29:15 2009 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 8D2E33A69E0 for ; Wed, 11 Nov 2009 08:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XWti-uQycYBb for ; Wed, 11 Nov 2009 08:29:14 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 96D8F3A69A1 for ; Wed, 11 Nov 2009 08:29:14 -0800 (PST) Received: by ywh13 with SMTP id 13so1288881ywh.29 for ; Wed, 11 Nov 2009 08:29:39 -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 :content-transfer-encoding; bh=QLBH4TUPtNj2IwN98ZMOYHIglFw5Ab63T4uEFKmlpso=; b=QueN8UMLhqgSEpZNXjd4ZO4vagJrZws3xQa2Ahwgjo+Y7RQgYysmx/SXl7srw2/CFG 9VPtsHCcZaFP1csym73/ZvvQhRS5N3CBD9FvVgt8yi4tAKw18r63gXdsBJgINzncsfBy CqfQPi1YpEWVKyrAIy97k2MA3SxDrBD727GK4= 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:content-transfer-encoding; b=QAaBz90WcP9m2N3MUhCpjLsDXd4eK76fd0kFYwRuHvQC0PLLLr+AoEwnE+92BVKUxY DeYJ29giM9cX/Upo6G4pblf2NJ0A3O8xzPgEc4ingIrJST0lD4zti5L3njP0Qq+WTg3e X7shi8hiUdqlN4jCYbLF90mEWCsqnZHScUlZM= MIME-Version: 1.0 Received: by 10.150.173.37 with SMTP id v37mr3046111ybe.298.1257956977310; Wed, 11 Nov 2009 08:29:37 -0800 (PST) In-Reply-To: References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> Date: Wed, 11 Nov 2009 08:29:37 -0800 Message-ID: <77ead0ec0911110829s27419995hd6032b8e00a8dfd7@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , David Ward 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, 11 Nov 2009 16:29:15 -0000 Hi Tom, Thats great. Do you have any comments on the questions I have raised? What about the other comments discussed on the list, have they been looked into? Thanks, Vishwas On Wed, Nov 11, 2009 at 4:06 AM, Thomas Nadeau wr= ote: > > =A0 =A0 =A0 =A0Thanks for the offer, but we have updated the document but= missed the update deadline. > > =A0 =A0 =A0 =A0--Tom > > >> Hi David, >> >> Thanks. I think some of the comments on the list earlier have also not >> been incorporated either. As the MIB has expired I am not sure if the >> authors need help closing the MIB. Do let me know if you need help >> closing the document? >> >> Thanks again, >> Vishwas >> >> On Tue, Nov 10, 2009 at 4:53 PM, David Ward wrote: >>> Leaving aside the questions specific to a vendor, the MIB is out of dat= e >>> after the changes to the specs following IESG review/comments and needs >>> another revision. >>> >>> -DWard >>> >>> >>> >> > > From pekkas@netcore.fi Wed Nov 11 23:26:14 2009 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 4CFDA28C12A for ; Wed, 11 Nov 2009 23:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 r5cxykWMXWH8 for ; Wed, 11 Nov 2009 23:26:13 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 4706828C0D7 for ; Wed, 11 Nov 2009 23:26:13 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id nAC7Q8Go028427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 09:26:08 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id nAC7Q8fg028424; Thu, 12 Nov 2009 09:26:08 +0200 Date: Thu, 12 Nov 2009 09:26:08 +0200 (EET) From: Pekka Savola To: Thomas Nadeau Subject: Re: BFD MIB In-Reply-To: Message-ID: References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi X-Virus-Status: Clean Cc: "rtg-bfd@ietf.org" , David Ward 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, 12 Nov 2009 07:26:14 -0000 On Wed, 11 Nov 2009, Thomas Nadeau wrote: > Thanks for the offer, but we have updated the document but > missed the update deadline. I bet you'll be glad to hear that the floodgates are already open! :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gauravh278@yahoo.co.in Thu Nov 12 23:29:53 2009 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 193193A6977 for ; Thu, 12 Nov 2009 23:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.745 X-Spam-Level: ** X-Spam-Status: No, score=2.745 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 umJWPQpNP4V2 for ; Thu, 12 Nov 2009 23:29:52 -0800 (PST) Received: from web95310.mail.in2.yahoo.com (web95310.mail.in2.yahoo.com [203.104.18.210]) by core3.amsl.com (Postfix) with SMTP id A17333A6904 for ; Thu, 12 Nov 2009 23:29:51 -0800 (PST) Received: (qmail 80054 invoked by uid 60001); 13 Nov 2009 07:30:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1258097416; bh=rZCAnU2PrIH/CU7WPqVpxQFokfht53QQjhHNv8KvFC4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=CtctiRL6CA5mFxaKg+QCKuo3+gdtDQciVVxrChNPCt3EjjLUB7LRKyJoex0A70AjUSgy7oqPaRNfevbrBedZQoHWUBLb3ELpnfhEJGtRGKkJ1IXhwOcS6VbXP8x/hEyHNyRaHMC3BGjqZ2d3xlusuDC+PpTFkEynFCXTkd3NeYk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=gM8rEuHmqe2GRs82Y3oyKapTnlRi5W3jwbE2/Mt1YvutV3kDXU9AOEDG9c1OxG+N/p3rzMUzlP4uS4x+NVTczo4NmgzECZX1aeHLLmfOQSYkVnoinXLhEv8bVmBaL8yxMsKXvM8vwXo43yMtBZIeF8e/bleyc5/1Vpf7hzZUz7k=; Message-ID: <859396.77361.qm@web95310.mail.in2.yahoo.com> X-YMail-OSG: OM.lv2sVM1nLg0FVht6Lo0ssNozEz1acOo74eZxyopoJO.860tetQvaqrvjJsoPn4q_PvIjwKpLbjVokLocUR3W9seIC.Q1.5LZMC_fRKFMRYsyG37dLWh3zvUqAKN6QbIawNMNwQ_eQPgpBZEj8ygTKkmSroHPlnh27SeYhaIKL8xVSvZshfkq8yihdgDvrwHIv6f5Y5AXKGdYCaEIiyDnavB8mkFRIh6MbMVEFr4x3BxW2Zp5ntUCGE2SRv6YdTNtrWdNijDWWe6NQwA6eSkueDAY- Received: from [125.21.164.251] by web95310.mail.in2.yahoo.com via HTTP; Fri, 13 Nov 2009 13:00:16 IST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Fri, 13 Nov 2009 13:00:16 +0530 (IST) From: GAURAV HALWASIA Subject: Few Queries regarding BFD To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1589491236-1258097416=:77361" 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: Fri, 13 Nov 2009 07:29:53 -0000 --0-1589491236-1258097416=:77361 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Experts,=0A=0AI will be working on implemmenting BFD in out protocol = stack and due to that trying to understand the in/out of this protocol. I h= ave couple of doubts regarding this protocol and need the help of you guys = to help me out.=0A=0A1. Should we (as BFD application) be getting the sessi= on parameters like Neighbour address (either Ipv4 and Ipv6),=A0Timers (Desi= red Min TX Interval, Required Min RX Interval and Required Min Echo RX Inte= rval in case Echo mode is supported), Ipv4/IPv6 encapsulation information, = Active/Passive information etc from the BFD client/application like OSPF/BG= P etc. Any clarity would be helpful.=0A=0A2. I am not very much clear that = how BFD application will decide whether this going to be session will be si= ngle hop or multi hop. Will the BFD application/client provide this informa= tion to BFD or will the BFD application should be able to find out the same= consulting the routing module.=0A=0A3. In BFD base draft I read the follow= ing =0A=A0 " Since multiple BFD sessions may be running between two systems= , there=0A=A0=A0 needs to be a mechanism for demultiplexing received BFD pa= ckets to the proper session. "=0A=A0=A0 =0A=A0=A0 I am really not clear how= the multiple BFD session can exist in between the two boxes.? I am really = getting =A0for this point. Please help me to understand this clearly. =0A= =A0=A0=A0 =0AYour inputs and help will be highly appreciated. A big thanks = in advance.=0A=0ARegards,=0AGaurav Halwasia=0A=0A=0A The INTERNET now = has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ --0-1589491236-1258097416=:77361 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Experts,
=0A
 
=0A
I will be working= on implemmenting BFD in out protocol stack and due to that trying to under= stand the in/out of this protocol. I have couple of doubts regarding this p= rotocol and need the help of you guys to help me out.
=0A
 =0A
1. Should we (as BFD application) be getting the session parame= ters like Neighbour address (either Ipv4 and Ipv6), Timers (Desired Mi= n TX Interval, Required Min RX Interval and Required Min Echo RX Interval i= n case Echo mode is supported), Ipv4/IPv6 encapsulation information, Active= /Passive information etc from the BFD client/application like OSPF/BGP etc.= Any clarity would be helpful.
=0A
 
=0A
2. I am not= very much clear that how BFD application will decide whether this going to= be session will be single hop or multi hop. Will the BFD application/clien= t provide this information to BFD or will the BFD application should be abl= e to find out the same consulting the routing module.
=0A
 =0A
3. In BFD base draft I read the following
  " Since mu= ltiple BFD sessions may be running between two systems, there
 &nbs= p; needs to be a mechanism for demultiplexing received BFD packets to the p= roper session. "
  
   I am really not clear how= the multiple BFD session can exist in between the two boxes.? I am really = getting  for this point. Please help me to understand this clearly.    
=0A
Your inputs and help will be highly appr= eciated. A big thanks in advance.
=0A
 
=0A
Regards,=
Gaurav Halwasia

=0A=0A=0A=0A
<= /hr> =0AThe INTERNET now has a personality. YOURS! See your Y= ahoo! Homepage. --0-1589491236-1258097416=:77361-- From vishwas.ietf@gmail.com Fri Nov 13 09:35:49 2009 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 76C143A6900 for ; Fri, 13 Nov 2009 09:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 IJ1Bympw3s3M for ; Fri, 13 Nov 2009 09:35:48 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 75F6C3A67A1 for ; Fri, 13 Nov 2009 09:35:48 -0800 (PST) Received: by yxe30 with SMTP id 30so3743073yxe.29 for ; Fri, 13 Nov 2009 09:36:15 -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 :content-transfer-encoding; bh=LeTsCQ+xkbLxv2IYOShhiZKKx+EhAtqgVbHdMpNr8dk=; b=W/9npcdLU/tayki/x73jt3zRdiEB7QAUs+w2+9xXZ5Kgy6g8yuuVZc9cMTx4lctt22 M3fBo79QW1a8aGJ5I/AgwB3EVoh8fyY1cg9tLedNM0PDAKYCKByz6UCBO5RcThuFauzN 2Hj5CDZafZItt4YX/Y5/aRoToWP6XflXQ5nrA= 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:content-transfer-encoding; b=P4s4fEMPcyaWLRpAM7f5RebBkSkI8k4OunjZ0MkCYMlIVLs70607ySKHKh/8a8L4pc iRYJZLbEnxwa76Ogp7e+OzrmFbgeGZdy//7l7WbQj8lIdjLVw7ddb/t0VRR4tVDrGhP4 ioldjNnpqHo0Ucux8srPTyxDaoAOs2FfPftHo= MIME-Version: 1.0 Received: by 10.150.3.31 with SMTP id 31mr8310396ybc.313.1258133774821; Fri, 13 Nov 2009 09:36:14 -0800 (PST) In-Reply-To: <859396.77361.qm@web95310.mail.in2.yahoo.com> References: <859396.77361.qm@web95310.mail.in2.yahoo.com> Date: Fri, 13 Nov 2009 09:36:14 -0800 Message-ID: <77ead0ec0911130936p3c97282as59355cd4a4ef94e1@mail.gmail.com> Subject: Re: Few Queries regarding BFD From: Vishwas Manral To: GAURAV HALWASIA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Fri, 13 Nov 2009 17:35:49 -0000 Hi Gaurav, > I will be working on implemmenting BFD in out protocol stack and due to t= hat > trying to understand the in/out of this protocol. I have couple of doubts > regarding this protocol and need the help of you guys to help me out. > > 1. Should we (as BFD application) be getting the session parameters like > Neighbour address (either Ipv4 and Ipv6),=A0Timers (Desired Min TX Interv= al, > Required Min RX Interval and Required Min Echo RX Interval in case Echo m= ode > is supported), Ipv4/IPv6 encapsulation information, Active/Passive > information etc from the BFD client/application like OSPF/BGP etc. Any > clarity would be helpful. It is dependent on the implementation. > 2. I am not very much clear that how BFD application will decide whether > this going to be session will be single hop or multi hop. Will the BFD > application/client provide this information to BFD or will the BFD > application should be able to find out the same consulting the routing > module. The application should know this. > 3. In BFD base draft I read the following > =A0 " Since multiple BFD sessions may be running between two systems, the= re > =A0=A0 needs to be a mechanism for demultiplexing received BFD packets to= the > proper session. " > > =A0=A0 I am really not clear how the multiple BFD session can exist in be= tween > the two boxes.? I am really getting =A0for this point. Please help me to > understand this clearly. If for example you have multiple parallel links between a set of routers you can have multiple parallel links and in turn sessions. Thanks, Vishwas > Your inputs and help will be highly appreciated. A big thanks in advance. > > Regards, > Gaurav Halwasia > ________________________________ > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. From gauravh278@yahoo.co.in Fri Nov 13 21:35:13 2009 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 B106D3A6929 for ; Fri, 13 Nov 2009 21:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 gheFH61ymIJh for ; Fri, 13 Nov 2009 21:35:12 -0800 (PST) Received: from web95301.mail.in2.yahoo.com (web95301.mail.in2.yahoo.com [203.104.18.201]) by core3.amsl.com (Postfix) with SMTP id 030143A67F2 for ; Fri, 13 Nov 2009 21:35:11 -0800 (PST) Received: (qmail 48334 invoked by uid 60001); 14 Nov 2009 05:35:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1258176941; bh=DkN1Gx8XiTGMeqYsGhmGjmCkaWrEw5+0jI+op6U58YU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=xt6L6I1Fb9oo58zmejRbVD71FFfcTiUKp9YE9HSuHm3UuRanTGttQa+FI8r9yNBLoAivxs+86KmXB7ndoFWSgsmfMskhq8DCKFqnQyf9QnHVwfHuT+aM5k238gcnLaUQE0F4bopIVSInb7ppsUOqkPlIZ4iPx7tZMrvLixomG7M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=1/LXb0wjyOrN3Zlx7VQcNqgRsThi7skScTgZEXraCmokIdoZqqcPbgK3TRZgJ6kx2DvDB8e/4UpEe46ZeXfGb2zdvhOM+417Xlinv22VGU9G4Zk/a3t1kuVC5akyx8oxxXJaDUf1jNdkX3auT6B+tZfqYtqlnElkgTj/0QsawV8=; Message-ID: <732672.48324.qm@web95301.mail.in2.yahoo.com> X-YMail-OSG: FK_ekP8VM1lRWiq.Ss.ArzcquzfVoCNJIk0Cn9.yEVpUEuzXT8OjBMpugDKOqk3Yg59tGPp7gXMHQmI9fHckWUHPU0nejET9OkZFLhrQ6mdhD9wmaAp0r8Uoo2B1_6zJ.TnW4SI8HyGgBNCKarZidYMnd_TmFAk6Lk4lwKLJcXCGeeSDrZLFcj85QyL1fLFPU4dQ32bHVzCZGCkspNusiO5MIkmHDMox91udANwpUc9eZEl47sdTcuXIpanKca4- Received: from [59.177.43.47] by web95301.mail.in2.yahoo.com via HTTP; Sat, 14 Nov 2009 11:05:41 IST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 Date: Sat, 14 Nov 2009 11:05:41 +0530 (IST) From: GAURAV HALWASIA Subject: Re: Few Queries regarding BFD To: Vishwas Manral MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-410331277-1258176941=:48324" 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: Sat, 14 Nov 2009 05:35:13 -0000 --0-410331277-1258176941=:48324 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vishwas,=0A=0AThanks a lot for your inputs in this. Please see inline @ = GAURAV=0A=0ARegards,=0AGaurav=0A=0A=0A=0A________________________________= =0A=0AFrom: Vishwas Manral =0ATo: GAURAV HALWASIA <= gauravh278@yahoo.co.in>=0ACc: rtg-bfd@ietf.org=0ASent: Fri, 13 November, 20= 09 9:36:14 AM=0ASubject: Re: Few Queries regarding BFD=0A=0A=0A[GAURAV] Ok.= Makes sense.=0A=0A> 2. I am not very much clear that how BFD application w= ill decide whether=0A> this going to be session will be single hop or multi= hop. Will the BFD=0A> application/client provide this information to BFD o= r will the BFD=0A> application should be able to find out the same consulti= ng the routing=0A> module.=0AThe application should know this.=0A=0A[GAURAV= ] So the application (for ex OSPF) will be in position to know before hand = itself that it's neighbour is directly connected (single hop) or multi hop.= ?? Because I think for BFD it will not be trivial to find the same(i.e sing= le/multi hop) other than interfacing with the routing module. Further consi= dering the short detection time which is required in this application, I al= so personally think that if the BFD client/application can give this ready = to use information to us, it will be good. Any thoughts ..??=0A=0A> 3. In B= FD base draft I read the following=0A> =A0 " Since multiple BFD sessions ma= y be running between two systems, there=0A> =A0=A0 needs to be a mechanism = for demultiplexing received BFD packets to the=0A> proper session. "=0A>=0A= > =A0=A0 I am really not clear how the multiple BFD session can exist in be= tween=0A> the two boxes.? I am really getting =A0for this point. Please hel= p me to=0A> understand this clearly.=0AIf for example you have multiple par= allel links between a set of=0Arouters you can have multiple parallel links= and in turn sessions.=0A=0A[GAURAV] Ok. But Are you referring to this scen= ario for single hop or multi hop..? is it something like we also need to ta= ke into account the interface on the box which is getting used for the sess= ion. Do you know any document/link which clearly explains in detail this sc= enario..? This will be very helpful.=0A=0AOnce again. Thanks a lot for your= inputs and help.=0A=0AThanks,=0AVishwas=0A> Your inputs and help will be h= ighly appreciated. A big thanks in advance.=0A>=0A> Regards,=0A> Gaurav Hal= wasia=0A> ________________________________=0A> The INTERNET now has a perso= nality. YOURS! See your Yahoo! Homepage.=0A=0AHi Gaurav,=0A=0A> I will be w= orking on implemmenting BFD in out protocol stack and due to that=0A> tryin= g to understand the in/out of this protocol. I have couple of doubts=0A> re= garding this protocol and need the help of you guys to help me out.=0A>=0A>= 1. Should we (as BFD application) be getting the session parameters like= =0A> Neighbour address (either Ipv4 and Ipv6),=A0Timers (Desired Min TX Int= erval,=0A> Required Min RX Interval and Required Min Echo RX Interval in ca= se Echo mode=0A> is supported), Ipv4/IPv6 encapsulation information, Active= /Passive=0A> information etc from the BFD client/application like OSPF/BGP = etc. Any=0A> clarity would be helpful.=0AIt is dependent on the implementat= ion.=0A=0A=0A The INTERNET now has a personality. YOURS! See your Yaho= o! Homepage. http://in.yahoo.com/ --0-410331277-1258176941=:48324 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vishwas,
=0A
 
=0A
Thanks a lot for you= r inputs in this. Please see inline @ GAURAV
=0A
 
=0ARegards,
=0A
Gaurav
=0A

=0A
=0A
=0A
=0A
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: GAURAV HALWASIA <gauravh278@yahoo.co.= in>
Cc: rtg-bfd@ietf.= org
Sent: Fri, 13 Novemb= er, 2009 9:36:14 AM
Subject:= Re: Few Queries regarding BFD

Hi Gaurav,

> I w= ill be working on implemmenting BFD in out protocol stack and due to that> trying to understand the in/out of this protocol. I have couple of d= oubts
> regarding this protocol and need the help of you guys to help= me out.
>
> 1. Should we (as BFD application) be getting the s= ession parameters like
> Neighbour address (either Ipv4 and Ipv6),&nb= sp;Timers (Desired Min TX Interval,
> Required Min RX Interval and Required Min Echo RX Interv= al in case Echo mode
> is supported), Ipv4/IPv6 encapsulation informa= tion, Active/Passive
> information etc from the BFD client/applicatio= n like OSPF/BGP etc. Any
> clarity would be helpful.
It is depende= nt on the implementation.
=0A
 
=0A
[GAURAV] Ok. Makes sense.
> 2. I am not very much clear that how BFD application will decide = whether
> this going to be session will be single hop or multi hop. W= ill the BFD
> application/client provide this information to BFD or w= ill the BFD
> application should be able to find out the same consult= ing the routing
> module.
The application should know this.
= =0A
[GAURAV] So the application (for ex OSPF) will be in positi= on to know before hand itself that it's neighbour is directly connected (si= ngle hop) or multi hop.?? Because I think for BFD it will not be trivial to= find the same(i.e single/multi hop) other than interfacing with the routin= g module. Further considering the short detection time which is required in= this application, I also personally think that if the BFD client/applicati= on can give this ready to use information to us, it will be good. Any thoug= hts ..??

> 3. In BFD base draft I read the following
> &nbs= p; " Since multiple BFD sessions may be running between two systems, there<= BR>>    needs to be a mechanism for demultiplexing received BF= D packets to the
> proper session. "
>
>    I a= m really not clear how the multiple BFD session can exist in between
>= ; the two boxes.? I am really getting  for this point. Please help me to
>= ; understand this clearly.
If for example you have multiple parallel lin= ks between a set of
routers you can have multiple parallel links and in = turn sessions.
=0A
 
=0A
[GAURAV] Ok. But Are you referring to t= his scenario for single hop or multi hop..? is it something like we also ne= ed to take into account the interface on the box which is getting used for = the session. Do you know any document/link which clearly explains in detail= this scenario..? This will be very helpful.
=0A
Once again. Thanks = a lot for your inputs and help.
=0A

Thanks,
Vishwas
> Your = inputs and help will be highly appreciated. A big thanks in advance.
>= ;
> Regards,
> Gaurav Halwasia
> ________________________= ________
> The INTERNET now has a personality. YOURS! See your Yahoo!= Homepage.

=0A=0A=0A=0A
=0AThe INTERNET now has a personality. YOURS! Se= e your Yahoo! Homepage. --0-410331277-1258176941=:48324-- From vishwas.ietf@gmail.com Sat Nov 14 07:33:24 2009 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 0E8C63A694E for ; Sat, 14 Nov 2009 07:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8YRSIQ8dfwS6 for ; Sat, 14 Nov 2009 07:33:23 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 316473A67F6 for ; Sat, 14 Nov 2009 07:33:23 -0800 (PST) Received: by ywh13 with SMTP id 13so4721967ywh.29 for ; Sat, 14 Nov 2009 07:33:51 -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 :content-transfer-encoding; bh=Fdy4kzpmtzgy8MF11x9zC8/0okosa1Sm9GfJuZg+JDY=; b=ThUbpN63p0dpYMuA+XQuZPVe276HAKiTAvSS/8TV7WB5LVPb1L2pH3NNJcRyD95JCM t3Oq/izsSrjGYktmoSd7cnNP3/GVZYu2WO8KtHJazp9c2z0iUcBpR00EenB51DuePh4e B5u+9Ad3RNWFCZp2yVBicFDQlmG4CRjTlKwU4= 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:content-transfer-encoding; b=CTw+WVyANXRQ51tnwpl6LhhbX26Tb+mxmtxbQHNH0V+skHrVGMC3mqy6JqfhkFEIp3 3LaKHFxLHsAxFB7EW/p5+izQdRUS3GyEI6uH0C1oaWPFYWS8BZpsfhyr1swADpQhIWdd wptWBPnLjvDaozRcqtpm0fUKp7TIfLB5hz06s= MIME-Version: 1.0 Received: by 10.150.251.28 with SMTP id y28mr10058488ybh.185.1258212831329; Sat, 14 Nov 2009 07:33:51 -0800 (PST) In-Reply-To: <732672.48324.qm@web95301.mail.in2.yahoo.com> References: <732672.48324.qm@web95301.mail.in2.yahoo.com> Date: Sat, 14 Nov 2009 07:33:51 -0800 Message-ID: <77ead0ec0911140733xc1924f8m5a9b9003b2a8c1f2@mail.gmail.com> Subject: Re: Few Queries regarding BFD From: Vishwas Manral To: GAURAV HALWASIA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sat, 14 Nov 2009 15:33:24 -0000 Hi Gaurav, >> 2. I am not very much clear that how BFD application will decide whether >> this going to be session will be single hop or multi hop. Will the BFD >> application/client provide this information to BFD or will the BFD >> application should be able to find out the same consulting the routing >> module. > The application should know this. > > [GAURAV] So the application (for ex OSPF) will be in position to know bef= ore > hand itself that it's neighbour is directly connected (single hop) or mul= ti > hop.?? Because I think for BFD it will not be trivial to find the same(i.= e > single/multi hop) other than interfacing with the routing module. Further > considering the short detection time which is required in this applicatio= n, > I also personally think that if the BFD client/application can give this > ready to use information to us, it will be good. Any thoughts ..?? So if you are having a BFD session for directly connected OSPF neighbors it will be single hop. The virtual links can always be modelled as multihop. If the application does not know it could as well ask the user input the information. >> 3. In BFD base draft I read the following >> =A0 " Since multiple BFD sessions may be running between two systems, th= ere >> =A0=A0 needs to be a mechanism for demultiplexing received BFD packets t= o the >> proper session. " >> >> =A0=A0 I am really not clear how the multiple BFD session can exist in b= etween >> the two boxes.? I am really getting =A0for this point. Please help me to >> understand this clearly. > If for example you have multiple parallel links between a set of > routers you can have multiple parallel links and in turn sessions. > > [GAURAV] Ok. But Are you referring to this scenario for single hop or mul= ti > hop..? is it something like we also need to take into account the interfa= ce > on the box which is getting used for the session. Do you know any > document/link which clearly explains in detail this scenario..? This will= be > very helpful. Though I am referring to a single hop case the same can occur in the multi-hop case too. Thanks, Vishwas From sunilc@ipinfusion.com Mon Nov 16 14:57:53 2009 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 5474D3A6A36 for ; Mon, 16 Nov 2009 14:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_50=0.001, 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 LCF79LlAK1rv for ; Mon, 16 Nov 2009 14:57:50 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id C7DDF3A6A32 for ; Mon, 16 Nov 2009 14:57:49 -0800 (PST) Received: by ywh13 with SMTP id 13so6798204ywh.29 for ; Mon, 16 Nov 2009 14:57:47 -0800 (PST) Received: by 10.150.171.4 with SMTP id t4mr743065ybe.346.1258412266849; Mon, 16 Nov 2009 14:57:46 -0800 (PST) Received: from sunilcgx620 ([65.223.109.250]) by mx.google.com with ESMTPS id 8sm159307ywg.4.2009.11.16.14.57.45 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 14:57:46 -0800 (PST) From: "Sunil C Gutlapalli" To: Subject: Questions on BFD for MPLS LSP Date: Mon, 16 Nov 2009 14:59:09 -0800 Message-ID: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA66CD.5B2D3A60" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpXaPdJWpjR+AxYTL2ELJoKwiYz4gPp1G+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 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, 16 Nov 2009 22:57:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA66CD.5B2D3A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0007_01CA66CD.5B2D3A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

 

------=_NextPart_000_0007_01CA66CD.5B2D3A60-- From vishwas.ietf@gmail.com Mon Nov 16 15:38:28 2009 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 E72FF3A6A41 for ; Mon, 16 Nov 2009 15:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LmR5U0bwErHe for ; Mon, 16 Nov 2009 15:38:28 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 133593A67A7 for ; Mon, 16 Nov 2009 15:38:27 -0800 (PST) Received: by ywh13 with SMTP id 13so6831390ywh.29 for ; Mon, 16 Nov 2009 15:38:22 -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 :content-transfer-encoding; bh=A+0tpEz7aSu8r3Jxfrc82y1o+qt2nh3As2mbTHN6gpQ=; b=qx12kVZjcmQI0RnA5I3eAlhRRRLXghmy/PdplbfUptPnGLswB6eix1aEDOmomno+Oh VOryTSGbFGr2eu/psXcpMIzaJmC/E0WDcjtBI7VglYlsHc9kdMQ/WMWmIKnbk3bYd28Y y7yYTraAxrxkafN/9BndM+5bRwxWuBN7agjz4= 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:content-transfer-encoding; b=S6LMnfk9t+YDcY3ws5gJiyl4GO4YKAoe2/1xJ1sGNlf78kkEh2zUO7ZbXXRY+zMzTj qRXwlqjRdokFx6iKhb3zs3c7OopuuFeLDukw36JpkK95rn6OL4uxDFyf8jJexUfpep+0 /eJe7V+oRA7EBKt3MfaZ9BlJvV3MVpW7JQeKE= MIME-Version: 1.0 Received: by 10.150.72.25 with SMTP id u25mr14759726yba.188.1258414702623; Mon, 16 Nov 2009 15:38:22 -0800 (PST) In-Reply-To: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> Date: Mon, 16 Nov 2009 15:38:22 -0800 Message-ID: <77ead0ec0911161538t5a835348wd50cb9b8ecbf76e0@mail.gmail.com> Subject: Re: Questions on BFD for MPLS LSP From: Vishwas Manral To: Sunil C Gutlapalli Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Mon, 16 Nov 2009 23:38:29 -0000 Hi Sunil, Thanks for the detailed mail. > MPLS LSP=92s 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 ingr= ess > to egress. Control packets from Egress to ingress are sent to UDP port 47= 84 > (multi hop session port). So does the session is single hop session or mu= lti > hop session? What is the session behavior in ingress and egress? Sunil with MPLS LSP's they have made special kinds of sessions which can be multihop in one direction and single hop in the other. There however was no requirement to model it that way, we could as well have used multhop in both directions. > If LSP takes path1 from ingress to egress and the shortest path from egre= ss > to ingress is path2, control packets takes different paths, if path2 fail= s > then BFD session goes down. But LSP path is still up. How this case will = be > handled? BFD is better suited for bidirectional LSP's than unidirectional ones. In case BFD session goes down the LSP is assumed to be down, even though the backward path may have gone down. > 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? We could as well use one session if the two sessions are bound togather in = BFD. > If both LSP=92s take same path, then link failure causes both LSP=92s dow= n, but > if they take different paths, one link failure causes both LSP=92s down. That is correct. > Sunil Thanks, Vishwas > > > From mach@huawei.com Tue Nov 17 01:06:31 2009 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 751593A69FD for ; Tue, 17 Nov 2009 01:06:31 -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, 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 k2f59ktlSb65 for ; Tue, 17 Nov 2009 01:06:30 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6696F3A6819 for ; Tue, 17 Nov 2009 01:06: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 <0KT800971XARNE@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 17 Nov 2009 17:06:27 +0800 (CST) Received: from m55527c ([10.111.12.130]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT8008F6XARJW@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 17 Nov 2009 17:06:27 +0800 (CST) Date: Tue, 17 Nov 2009 17:06:26 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> To: Sunil C Gutlapalli , rtg-bfd@ietf.org Message-id: <2A711185E3484856B441A19C9DB3AED5@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> Cc: 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: Tue, 17 Nov 2009 09:06:31 -0000 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 mahesh.akula@wipro.com Tue Nov 17 07:37:36 2009 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 97EEA28C12E for ; Tue, 17 Nov 2009 07:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SUBJ_ALL_CAPS=2.077] 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 am4COuVIAaOT for ; Tue, 17 Nov 2009 07:37:35 -0800 (PST) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 6040D3A68DD for ; Tue, 17 Nov 2009 07:37:35 -0800 (PST) X-AuditID: cb5bdd57-b7c76ae000001142-20-4b02c33b3e0e Received: from blr-ec-aa01.wipro.com ( [10.201.18.41]) by (Symantec Mail Security) with SMTP id 06.27.04418.B33C20B4; Tue, 17 Nov 2009 21:07:32 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 21:07:29 +0530 Received: from blr-ec-bh04.wipro.com ([10.201.50.98]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 21:07:28 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh04.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 21:07:27 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA679B.DDCBDFD4" Subject: BFD VCCV!! Date: Tue, 17 Nov 2009 21:05:01 +0530 Message-ID: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD VCCV!! Thread-Index: Acpnm4arfVvBgl+MSHW9Ap50owtSiw== From: To: X-OriginalArrivalTime: 17 Nov 2009 15:37:27.0864 (UTC) FILETIME=[DE2E2B80:01CA679B] X-Brightmail-Tracker: AAAAAA== 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, 17 Nov 2009 15:37:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA679B.DDCBDFD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Once the PW is operational and VCCV-BFD session is established between the PW peers (after they exchanged the BFD VCCV capabilty), can this BFD session be brought down administratively without bringing down/re-signaling the PW? =20 If i'm correct, I think the same can be done using "Administratively Down" Diag code in case of other BFD applications like OSPF.=20 =20 But in case of BFD VCCV, as per the below text in draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I understand that "Administrative down" Diag code is used to signal to the PW peer that the PW is brought down administratively, not for signaling that the BFD session between PW peers is brought down. =20 "A PE shall use "Administrative down" to bring down the BFD session when the PW is brought down administratively" =20 Thanks in Advance for any inputs, =20 Regards, Mahesh. =20 ------_=_NextPart_001_01CA679B.DDCBDFD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Once = the PW is=20 operational and VCCV-BFD session is established between the PW = peers (after=20 they exchanged the BFD VCCV capabilty), can this BFD session be brought down = administratively=20 without bringing down/re-signaling the PW?
 
If i'm = correct, I=20 think the same can be done using "Administratively Down" Diag code in = case of=20 other BFD applications like OSPF.
 
But in case of BFD VCCV, as per the below = text in=20 draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I understand that "Administrative down" Diag = code is=20 used to signal to the PW peer that the PW is brought down = administratively, not=20 for signaling that the BFD session between=20 PW peers is brought down.
 
"A PE shall  use = "Administrative=20 down" to bring down the BFD session when the PW  is brought down=20 administratively"
 
Thanks = in Advance=20 for any inputs,
 
Regards,
Mahesh.
 
------_=_NextPart_001_01CA679B.DDCBDFD4-- From vishwas.ietf@gmail.com Tue Nov 17 08:19:35 2009 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 6C8B73A68DA for ; Tue, 17 Nov 2009 08:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 gJQW14MeF8Fu for ; Tue, 17 Nov 2009 08:19:34 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 9CCD33A684E for ; Tue, 17 Nov 2009 08:19:34 -0800 (PST) Received: by gxk28 with SMTP id 28so146489gxk.9 for ; Tue, 17 Nov 2009 08:19:30 -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 :content-transfer-encoding; bh=kSBjyr+q2ZgjKDm5nppgD2fEfCA2fSy/5EK9BxM9OAU=; b=B0hFOzQQ1hWhJKy/i+edcxN9jeEOdx9PZpKgAMJ6OpOBE3uKupWd5lZEZ+BRpBA9MC hh92fIKmB7zennkdiOhnV4YM2SvTE5nPhUTm10OK1LKwbhgR9hQm2xuQpcKfMDxk3sg5 GrIL7X9xpuNAZ0UDh6JoNufmYEers/332OTmA= 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:content-transfer-encoding; b=LgH74d8nwM00IrP4pBNGNr7DR/KGOVyLa1jPgWiyfEOEoH9syuqAjdMBq51P0F7f+h 0v33GhLt8A6Z4Bz44XOcLToBSoByBXqfyQ6WbdXj6iJuF+DxzKrhgyvJWayFhz2HeLx4 O7kqnYWBN5OAgcsg4OfIseFgy1O9BEBW+qXCw= MIME-Version: 1.0 Received: by 10.150.171.14 with SMTP id t14mr272930ybe.316.1258474765975; Tue, 17 Nov 2009 08:19:25 -0800 (PST) In-Reply-To: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> References: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> Date: Tue, 17 Nov 2009 08:19:25 -0800 Message-ID: <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> Subject: Re: BFD VCCV!! From: Vishwas Manral To: mahesh.akula@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 17 Nov 2009 16:19:35 -0000 Hi Mahesh, > Once the=A0PW is operational and VCCV-BFD session is established between > the=A0PW peers (after they exchanged the BFD VCCV capabilty), can this=A0= BFD > session be brought down administratively without bringing down/re-signali= ng > the PW? > > If i'm correct, I think the same can be done using "Administratively Down= " > Diag code in case of other BFD applications like OSPF. That is correct Mahesh. > But in case of BFD VCCV, as per the below text in > draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I > understand that "Administrative down" Diag code is used to signal to the = PW > peer that the PW is brought down administratively, not for signaling that > the BFD session=A0between PW peers is brought down. > > "A PE shall=A0 use "Administrative down" to bring down the BFD session wh= en > the PW=A0 is brought down administratively" I do not see a conflict here. The BFD session can be brought down administratively. When a PW is brought down administratively, in that case too we will use the "Admin down" diag. What is it I am missing in the question? Thanks, Vishwas From mahesh.akula@wipro.com Tue Nov 17 08:52:09 2009 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 585133A6943 for ; Tue, 17 Nov 2009 08:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SUBJ_ALL_CAPS=2.077] 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 s25qvy34HkEY for ; Tue, 17 Nov 2009 08:52:07 -0800 (PST) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id DB60D3A6920 for ; Tue, 17 Nov 2009 08:51:54 -0800 (PST) X-AuditID: cb5bdd57-b7c76ae000001142-96-4b02d4a6a4d2 Received: from blr-ec-aa01.wipro.com ( [10.201.18.41]) by (Symantec Mail Security) with SMTP id 30.AA.04418.6A4D20B4; Tue, 17 Nov 2009 22:21:50 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 22:21:50 +0530 Received: from blr-ec-bh03.wipro.com ([10.201.50.97]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 22:21:50 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 22:21:50 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD VCCV!! Date: Tue, 17 Nov 2009 22:19:23 +0530 Message-ID: <6CD4ED5690208D4186E7E46B4C13B7EC09372F6E@HYD-MDP-MBX01.wipro.com> In-Reply-To: <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD VCCV!! Thread-Index: Acpnob+JS+0a4aWsRbGTHGqE5BG9DwAAliNA References: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> From: To: X-OriginalArrivalTime: 17 Nov 2009 16:51:50.0515 (UTC) FILETIME=[4220AC30:01CA67A6] X-Brightmail-Tracker: AAAAAA== 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, 17 Nov 2009 16:52:09 -0000 Hi Vishwas, Thanks for your quick reply. If we use "Admin Down" diag code to signal both the "PW Down" and "VCCV = BFD Session Down" to the PW peer, what should be the action at the peer? Should the peer just delete the BFD session and stop expecting/sending = BFD control packets on that VC or should it assume that the VC Fib has = been uninstalled on the other and take necessary action like = un-installing the VC fib entry at its end too? Thanks, Mahesh -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, November 17, 2009 9:49 PM To: Mahesh Akula (WT01 - Telecom Equipment) Cc: rtg-bfd@ietf.org Subject: Re: BFD VCCV!! Hi Mahesh, > Once the=A0PW is operational and VCCV-BFD session is established = between=20 > the=A0PW peers (after they exchanged the BFD VCCV capabilty), can = this=A0 > BFD session be brought down administratively without bringing=20 > down/re-signaling the PW? > > If i'm correct, I think the same can be done using "Administratively = Down" > Diag code in case of other BFD applications like OSPF. That is correct Mahesh. > But in case of BFD VCCV, as per the below text in > draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I=20 > understand that "Administrative down" Diag code is used to signal to=20 > the PW peer that the PW is brought down administratively, not for=20 > signaling that the BFD session=A0between PW peers is brought down. > > "A PE shall=A0 use "Administrative down" to bring down the BFD session = > when the PW=A0 is brought down administratively" I do not see a conflict here. The BFD session can be brought down = administratively. When a PW is brought down administratively, in that = case too we will use the "Admin down" diag. What is it I am missing in the question? Thanks, Vishwas From vishwas.ietf@gmail.com Tue Nov 17 09:58:02 2009 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 AA9273A686D for ; Tue, 17 Nov 2009 09:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VOF-CRWA0DCq for ; Tue, 17 Nov 2009 09:58:01 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9FB793A69DD for ; Tue, 17 Nov 2009 09:58:01 -0800 (PST) Received: by ywh13 with SMTP id 13so283748ywh.29 for ; Tue, 17 Nov 2009 09:57:57 -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 :content-transfer-encoding; bh=d6XZKy0pkneDPuuzzpLuRJwhec+baVI9CmE6immFPoQ=; b=dgvI+icnZk6G71TcJAraOcJxU1I5MN8LRb0nu6v+xGymeL+QjG/xZcZLvCmgNVPBJ/ rcISUwkO4Gr4gxk5Q2iYdlQ2WlBcTFC8iTC8F692SVamelEPSpk9HcFXaxxchSOPpZUR 3prhIP1uvpmhAvIYNN8CmsYCSTUCXChAibivE= 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:content-transfer-encoding; b=m9VGn7fJNsXRYSViun0GL1xwqbTuMHtjAlE0oiCqlcWpMV4amF+pPz8gwPm7vSGsgl Q7qNAMK9fnqgWe9/wxv4pE8VCCklizC/SO015afbeNBNvVeeJoYzsMtqXo2PqAP2fakS HXJDsO5e9DjvJM0EN33qOuZEiFmkt5t34FE00= MIME-Version: 1.0 Received: by 10.150.25.5 with SMTP id 5mr476791yby.295.1258480677668; Tue, 17 Nov 2009 09:57:57 -0800 (PST) In-Reply-To: <6CD4ED5690208D4186E7E46B4C13B7EC09372F6E@HYD-MDP-MBX01.wipro.com> References: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> <6CD4ED5690208D4186E7E46B4C13B7EC09372F6E@HYD-MDP-MBX01.wipro.com> Date: Tue, 17 Nov 2009 09:57:57 -0800 Message-ID: <77ead0ec0911170957k49a5b373s87b9d54b7dbf4c04@mail.gmail.com> Subject: Re: BFD VCCV!! From: Vishwas Manral To: mahesh.akula@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 17 Nov 2009 17:58:02 -0000 Hi Mahesh, > If we use "Admin Down" diag code to signal both the "PW Down" and "VCCV B= FD Session Down" to the PW peer, what should be the action at the peer? > > Should the peer just delete the BFD session and stop expecting/sending BF= D control packets on that VC or should it assume that the VC Fib has been u= ninstalled on the other and take necessary action like un-installing the VC= fib entry at its end too? For Admin-down you will not delete the BFD session. It will still expect BFD packets and send packets just like in the normal BFD case. Thanks, Vishwas > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 17, 2009 9:49 PM > To: Mahesh Akula (WT01 - Telecom Equipment) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD VCCV!! > > Hi Mahesh, > >> Once the=A0PW is operational and VCCV-BFD session is established between >> the=A0PW peers (after they exchanged the BFD VCCV capabilty), can this >> BFD session be brought down administratively without bringing >> down/re-signaling the PW? >> >> If i'm correct, I think the same can be done using "Administratively Dow= n" >> Diag code in case of other BFD applications like OSPF. > That is correct Mahesh. > >> But in case of BFD VCCV, as per the below text in >> draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I >> understand that "Administrative down" Diag code is used to signal to >> the PW peer that the PW is brought down administratively, not for >> signaling that the BFD session=A0between PW peers is brought down. >> >> "A PE shall=A0 use "Administrative down" to bring down the BFD session >> when the PW=A0 is brought down administratively" > I do not see a conflict here. The BFD session can be brought down adminis= tratively. When a PW is brought down administratively, in that case too we = will use the "Admin down" diag. > > What is it I am missing in the question? > > Thanks, > Vishwas > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and = may contain proprietary, confidential or privileged information. If you are= not the intended recipient, you should not disseminate, distribute or copy= this e-mail. Please notify the sender immediately and destroy all copies o= f this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient sho= uld check this email and any attachments for the presence of viruses. The c= ompany accepts no liability for any damage caused by any virus transmitted = by this email. > > www.wipro.com > From vishwas.ietf@gmail.com Tue Nov 17 09:59:46 2009 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 8609F3A69DD for ; Tue, 17 Nov 2009 09:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TaHPJQ01rpT3 for ; Tue, 17 Nov 2009 09:59:45 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 8E41E3A6939 for ; Tue, 17 Nov 2009 09:59:45 -0800 (PST) Received: by gxk28 with SMTP id 28so252580gxk.9 for ; Tue, 17 Nov 2009 09:59:41 -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 :content-transfer-encoding; bh=cTpu1oH5YZIYpsPJ/XE5UuhwWz4OxfEKg967QhD8Qdg=; b=qmTjICti6Gt6Fh76QTUpzE0q3c9uoHWcJ77AnuVPEM/V3YpbrL+5eK9t/pI8/SiyvE 2fnirmR2XZdcyv1TilAY0KK7BiEsZxtDGhmU8zynpg8zdU6J+gwDca/2JkWWYB6eZoIz 7oEmdr8Rc3zatqLMYlPUhdh8+D/WyKFhwwmPo= 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:content-transfer-encoding; b=a/K7tBx7ZvSeu/C3XAVgb4PhuRxpq1SQRVk1QN54YgKsLsbnAgDb+gxLgFJ8iIAONy QJciiH5LON4LZE5c4WdyPTwvusPFg1scUBwoGVxyGRMhrTV4kpINg6OMH2gQeYVPh2Wm L9n2YML98Krwv8um0WlsIxcPbzjuwCMqpNmV4= MIME-Version: 1.0 Received: by 10.150.46.21 with SMTP id t21mr503254ybt.234.1258480779681; Tue, 17 Nov 2009 09:59:39 -0800 (PST) In-Reply-To: <2A711185E3484856B441A19C9DB3AED5@m55527c> References: <992EE5136CC94CF9A118433E3ABBAE9E@sunilcgx620> <2A711185E3484856B441A19C9DB3AED5@m55527c> Date: Tue, 17 Nov 2009 09:59:39 -0800 Message-ID: <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> Subject: Re: Questions on BFD for MPLS LSP From: Vishwas Manral To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sunil C Gutlapalli , So Ning , 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, 17 Nov 2009 17:59:46 -0000 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, =A0we a= lso > 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 LS= P, > 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 t= o > perform protection and switching when the bidirectional LSP or the pair o= f > 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 ho= p >> session or multi hop session? What is the session behavior in ingress an= d >> 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 cas= e >> 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 mahesh.akula@wipro.com Wed Nov 18 00:24:12 2009 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 716773A68EE for ; Wed, 18 Nov 2009 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994, SUBJ_ALL_CAPS=2.077] 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 kEEhjtoYEI0K for ; Wed, 18 Nov 2009 00:24:11 -0800 (PST) Received: from wipro-blr-out02.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 12CF73A6838 for ; Wed, 18 Nov 2009 00:24:10 -0800 (PST) X-AuditID: cb5bdd58-b7b70ae00000336e-28-4b03af27c2a3 Received: from blr-ec-aa03.wipro.com (Unknown_Domain [10.201.18.42]) by (Symantec Mail Security) with SMTP id BE.8E.13166.72FA30B4; Wed, 18 Nov 2009 13:54:07 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:54:04 +0530 Received: from blr-ec-bh03.wipro.com ([10.201.50.97]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:54:03 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:54:04 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD VCCV!! Date: Wed, 18 Nov 2009 13:51:36 +0530 Message-ID: <6CD4ED5690208D4186E7E46B4C13B7EC0937306B@HYD-MDP-MBX01.wipro.com> In-Reply-To: <77ead0ec0911170957k49a5b373s87b9d54b7dbf4c04@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD VCCV!! Thread-Index: Acpnr4DXGlxrrhS9ToyGOB0yF7jRNwAbKJwQ References: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> <6CD4ED5690208D4186E7E46B4C13B7EC09372F6E@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170957k49a5b373s87b9d54b7dbf4c04@mail.gmail.com> From: To: X-OriginalArrivalTime: 18 Nov 2009 08:24:04.0003 (UTC) FILETIME=[7D159F30:01CA6828] X-Brightmail-Tracker: AAAAAA== 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, 18 Nov 2009 08:24:12 -0000 Hi Vishwas, Thanks for correcting me.=20 I'll rephrase my question then, On receiving "Admin Down" Diag code from the peer, should the node just = stop expecting the BFD control packets from the peer on that VC (or) = should it assume that the PW is down at the other end and take necessary = action, may be bring down the PW at its end too. I think if PW is down at the peer end, there is no point in sending BFD = control packets on that VC any more right? Thanks for your inputs and time. Regards, Mahesh -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, November 17, 2009 11:28 PM To: Mahesh Akula (WT01 - Telecom Equipment) Cc: rtg-bfd@ietf.org Subject: Re: BFD VCCV!! Hi Mahesh, > If we use "Admin Down" diag code to signal both the "PW Down" and = "VCCV BFD Session Down" to the PW peer, what should be the action at the = peer? > > Should the peer just delete the BFD session and stop expecting/sending = BFD control packets on that VC or should it assume that the VC Fib has = been uninstalled on the other and take necessary action like = un-installing the VC fib entry at its end too? For Admin-down you will not delete the BFD session. It will still expect = BFD packets and send packets just like in the normal BFD case. Thanks, Vishwas > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 17, 2009 9:49 PM > To: Mahesh Akula (WT01 - Telecom Equipment) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD VCCV!! > > Hi Mahesh, > >> Once the=A0PW is operational and VCCV-BFD session is established=20 >> between the=A0PW peers (after they exchanged the BFD VCCV capabilty), = >> can this BFD session be brought down administratively without=20 >> bringing down/re-signaling the PW? >> >> If i'm correct, I think the same can be done using "Administratively = Down" >> Diag code in case of other BFD applications like OSPF. > That is correct Mahesh. > >> But in case of BFD VCCV, as per the below text in >> draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I=20 >> understand that "Administrative down" Diag code is used to signal to=20 >> the PW peer that the PW is brought down administratively, not for=20 >> signaling that the BFD session=A0between PW peers is brought down. >> >> "A PE shall=A0 use "Administrative down" to bring down the BFD = session=20 >> when the PW=A0 is brought down administratively" > I do not see a conflict here. The BFD session can be brought down = administratively. When a PW is brought down administratively, in that = case too we will use the "Admin down" diag. > > What is it I am missing in the question? > > Thanks, > Vishwas > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any = attachments to this message are intended for the exclusive use of the = addressee(s) and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient = should check this email and any attachments for the presence of viruses. = The company accepts no liability for any damage caused by any virus = transmitted by this email. > > www.wipro.com > From vishwas.ietf@gmail.com Wed Nov 18 08:11:59 2009 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 1F74328C104 for ; Wed, 18 Nov 2009 08:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 oV-KPwOk86EP for ; Wed, 18 Nov 2009 08:11:37 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 6F5573A6985 for ; Wed, 18 Nov 2009 08:11:37 -0800 (PST) Received: by gxk28 with SMTP id 28so1153499gxk.9 for ; Wed, 18 Nov 2009 08:11:30 -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 :content-transfer-encoding; bh=59nzuZ/C4VywzXNKOXFIx3Svbr/LHgRi6ph3/1S87Lw=; b=OVBpgl7JZHJ7K5nkiUQ1jlbHtcvSF4B4kntVzyOlIz7nHz26jKbVTPYRaIxFmG95AZ IUdVjwgApUBGoQQQe+ARGuvM8wa4gVpHFDIAVzybqV9Q/i2ayU1W5DFhvpfT1wB6er58 J5v8XkytIHif2RZpF3JaMg3zbePg4rpEy4gs0= 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:content-transfer-encoding; b=JRW5N20AW/6VaO79wD0y81YI43Q1hAtEPvcB2WIJlfr41v7H8jS7wtXtkPsZiP0RSj KwHXg/T9D95V486YmbEZ/QIXFGMHTpBrXZC/Ma+Bpv0aEnJEBdzhKVdY5SP4i6M+MOfh axWooGlE29mYb/pDFOoHBf7WXAtKVoXU/ZPSQ= MIME-Version: 1.0 Received: by 10.150.130.31 with SMTP id c31mr2547334ybd.278.1258560679764; Wed, 18 Nov 2009 08:11:19 -0800 (PST) In-Reply-To: <6CD4ED5690208D4186E7E46B4C13B7EC0937306B@HYD-MDP-MBX01.wipro.com> References: <6CD4ED5690208D4186E7E46B4C13B7EC09372F60@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170819j21eb2f30ofe45d8f2d35b3b03@mail.gmail.com> <6CD4ED5690208D4186E7E46B4C13B7EC09372F6E@HYD-MDP-MBX01.wipro.com> <77ead0ec0911170957k49a5b373s87b9d54b7dbf4c04@mail.gmail.com> <6CD4ED5690208D4186E7E46B4C13B7EC0937306B@HYD-MDP-MBX01.wipro.com> Date: Wed, 18 Nov 2009 08:11:19 -0800 Message-ID: <77ead0ec0911180811m7d4a7f78h7cc0882313a4aea3@mail.gmail.com> Subject: Re: BFD VCCV!! From: Vishwas Manral To: mahesh.akula@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 18 Nov 2009 16:12:07 -0000 HI Mahesh, > On receiving "Admin Down" Diag code from the peer, should the node just s= top expecting the BFD control packets from the peer on that VC (or) should = it assume that the PW is down at the other end and take necessary action, m= ay be bring down the PW at its end too. > > I think if PW is down at the peer end, there is no point in sending BFD c= ontrol packets on that VC any more right? As the diganostics code is used for different scenarios we will send the BFD packets till the VC is removed from the local end. This will take care of the case where its just that BFD is brought down Administratively. Thanks, Vishwas > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 17, 2009 11:28 PM > To: Mahesh Akula (WT01 - Telecom Equipment) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD VCCV!! > > Hi Mahesh, > >> If we use "Admin Down" diag code to signal both the "PW Down" and "VCCV = BFD Session Down" to the PW peer, what should be the action at the peer? >> >> Should the peer just delete the BFD session and stop expecting/sending B= FD control packets on that VC or should it assume that the VC Fib has been = uninstalled on the other and take necessary action like un-installing the V= C fib entry at its end too? > For Admin-down you will not delete the BFD session. It will still expect = BFD packets and send packets just like in the normal BFD case. > > Thanks, > Vishwas > >> >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, November 17, 2009 9:49 PM >> To: Mahesh Akula (WT01 - Telecom Equipment) >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD VCCV!! >> >> Hi Mahesh, >> >>> Once the=A0PW is operational and VCCV-BFD session is established >>> between the=A0PW peers (after they exchanged the BFD VCCV capabilty), >>> can this BFD session be brought down administratively without >>> bringing down/re-signaling the PW? >>> >>> If i'm correct, I think the same can be done using "Administratively Do= wn" >>> Diag code in case of other BFD applications like OSPF. >> That is correct Mahesh. >> >>> But in case of BFD VCCV, as per the below text in >>> draft-ietf-pwe3-oam-msg-map-11 which discusses the BFD Diag codes, I >>> understand that "Administrative down" Diag code is used to signal to >>> the PW peer that the PW is brought down administratively, not for >>> signaling that the BFD session=A0between PW peers is brought down. >>> >>> "A PE shall=A0 use "Administrative down" to bring down the BFD session >>> when the PW=A0 is brought down administratively" >> I do not see a conflict here. The BFD session can be brought down admini= stratively. When a PW is brought down administratively, in that case too we= will use the "Admin down" diag. >> >> What is it I am missing in the question? >> >> Thanks, >> Vishwas >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any attachments= to this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you ar= e not the intended recipient, you should not disseminate, distribute or cop= y this e-mail. Please notify the sender immediately and destroy all copies = of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient sh= ould check this email and any attachments for the presence of viruses. The = company accepts no liability for any damage caused by any virus transmitted= by this email. >> >> www.wipro.com >> > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and = may contain proprietary, confidential or privileged information. If you are= not the intended recipient, you should not disseminate, distribute or copy= this e-mail. Please notify the sender immediately and destroy all copies o= f this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient sho= uld check this email and any attachments for the presence of viruses. The c= ompany accepts no liability for any damage caused by any virus transmitted = by this email. > > www.wipro.com > From mach@huawei.com Wed Nov 18 16:51:40 2009 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 D3D6C3A6879 for ; Wed, 18 Nov 2009 16:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 JSYysEOrFNan for ; Wed, 18 Nov 2009 16:51:39 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B8C393A6842 for ; Wed, 18 Nov 2009 16:51:39 -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 <0KTB00H5EZPRZW@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 19 Nov 2009 08:51:27 +0800 (CST) Received: from m55527c ([10.111.12.130]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTB00C04ZPRPE@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 19 Nov 2009 08:51:27 +0800 (CST) Date: Thu, 19 Nov 2009 08:51:27 +0800 From: Mach Chen Subject: Re: Questions on BFD for MPLS LSP In-reply-to: <77ead0ec0911170959s4a559645h985275e769db5b4f@mail.gmail.com> To: Vishwas Manral Message-id: <4A96A57F47E848C58B8B3F4E4B8CFD64@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> Cc: Sunil C Gutlapalli , So Ning , 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, 19 Nov 2009 00:51:40 -0000 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 gauravh278@yahoo.co.in Wed Nov 25 19:57:28 2009 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 04A033A6AEF for ; Wed, 25 Nov 2009 19:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 GMxtBIXGeSdo for ; Wed, 25 Nov 2009 19:57:27 -0800 (PST) Received: from web95303.mail.in2.yahoo.com (web95303.mail.in2.yahoo.com [203.104.18.203]) by core3.amsl.com (Postfix) with SMTP id 9A73D3A6AEB for ; Wed, 25 Nov 2009 19:57:26 -0800 (PST) Received: (qmail 65609 invoked by uid 60001); 26 Nov 2009 03:57:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1259207837; bh=A2UxS+5ajzxdtQ7twTX1dqp/MWwtEFRapQS1P5xVozw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=PD8Wdx++izF/Q5ew6PSotnK9iyyojM53IAWcicCFnEJK5WOH4FkmpDGVulFYRO0rh+wCho9gTX56J+/BFMhxdIFd8OoX5C2we1Hht7rNoB7Ns9la+zeHeuA6yXwVqbvOYaONVHGAsiwPkYLLbABufSN+jbKMic8cuPKXuBIYCv4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ajhpb0entPeqe3QxgG2vdj2/LKuT6osP2bkraRAv5H/VRK1Cx9+wkvxK5McjGLgz4zV7xlbW7DgtsFcR9e2XFwfbTC6wZwAaJgnui6K4YFJ32u/k6dcD+u3zv79lxNQhnveya1kNLDv/VqnVTc3FcVPxMQwTmzB4mSLGviuFqqg=; Message-ID: <370232.65283.qm@web95303.mail.in2.yahoo.com> X-YMail-OSG: vrjf31UVM1nZ.rfaaZ2L5fRwXELhewqeywQuEU7PSnhCvkl.x_Tck5uIb.YHhGDcM6eo77abIcCdg2RD_H9fQaHpoOnYOQxXFvYURcw37Q6jme6bo0wTp5gn3WxGZWVzLxGq5y3biJssrcdu3I428MKhkl9LtGhogbbZWryqlgbDG49sHQr3ZIF76GLzB8MBytqSZrBIggjO8tl3l7x40CG7DrqNCaj61jW3MkK2e_fs.bkbY5kuwOhE2eUQYlaYg7ODbOaV52_T7Iytho43MDzp3Kyr4T9rCFFfmsIgo.g45P3G Received: from [125.21.164.251] by web95303.mail.in2.yahoo.com via HTTP; Thu, 26 Nov 2009 09:27:17 IST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 Date: Thu, 26 Nov 2009 09:27:17 +0530 (IST) From: GAURAV HALWASIA Subject: Query Regarding BFD Echo Mode To: BFD MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1030666598-1259207837=:65283" Cc: Amitesh Shukla 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, 26 Nov 2009 03:57:28 -0000 --0-1030666598-1259207837=:65283 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0AI have few doubts regarding the BFD Echo mode.=0AIn case we have esta= blished BFD session in between A & B (A--------B) and have enabled Echo mod= e on A. System B must have indicated to A that it can loop back the echo pa= ckets through the use of some non zero Echo Rx intervel (X milli seconds) i= n any control packets towards System A. =0AA. Now will A send some "Stream = of BFD Echo packets" per X milli seconds towards B or will A send only "sin= gle BFD Echo packet" per X milli seconds. Further, In any case, what the de= tection time will be in case of detecting failure through Echo Mode. I unde= rstand that braft says clearly that it's outside it's scope but still any p= ointer and sugession regarding the possible approach =A0will be helpful.=0A= B. Further, till when these BFD Echo packets will be transmitted.?=0AC. Bas= e draft says that a seperate UDP port will be used for Echo mode. i.e 3785.= I assume that this UDP port will be opened on the system where the Echo pa= ckets has to be received back after getting loopbacked from the remote end = (i.e on the system where the echo mode is getting used for detectinf failur= e). Is my understanding correct..?=0A=0AAs always, any help will be highly = appreciated.=0A=A0=0AThanks & Regards,=0AGaurav=0A=0A=0A The INTERNET = now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com= / --0-1030666598-1259207837=:65283 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=0A
I have few doubts regarding the BFD Echo mode.=0A
In case we have established BFD session in between A & B (A= --------B) and have enabled Echo mode on A. System B must have indicated to= A that it can loop back the echo packets through the use of some non zero = Echo Rx intervel (X milli seconds) in any control packets towards System A.=
A. Now will A send some "Stream of BFD Echo packets" per X milli secon= ds towards B or will A send only "single BFD Echo packet" per X milli secon= ds. Further, In any case, what the detection time will be in case of detect= ing failure through Echo Mode. I understand that braft says clearly that it= 's outside it's scope but still any pointer and sugession regarding the pos= sible approach  will be helpful.
=0A
B. Further, till when th= ese BFD Echo packets will be transmitted.?
=0A
C. Base draft says = that a seperate UDP port will be used for Echo mode. i.e 3785. I assume tha= t this UDP port will be opened on the system where the Echo packets has to = be received back after getting loopbacked from the remote end (i.e on the s= ystem where the echo mode is getting used for detectinf failure). Is my und= erstanding correct..?
=0A
 
=0A
As always, any help = will be highly appreciated.
 
=0A
Thanks & Regards,Gaurav

=0A=0A=0A=0A
=0AThe = INTERNET now has a personality. YOURS! See your Yahoo! Homepa= ge. --0-1030666598-1259207837=:65283-- From dkatz@juniper.net Thu Nov 26 10:37:15 2009 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 3B20E3A6AAE for ; Thu, 26 Nov 2009 10:37:15 -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 AWjOTOEb17Qj for ; Thu, 26 Nov 2009 10:37:14 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 183093A689C for ; Thu, 26 Nov 2009 10:37:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSw7Kx4f6I3zToN/yXR68bU/jP7b+Q97F@postini.com; Thu, 26 Nov 2009 10:37:04 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, 26 Nov 2009 10:30:27 -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, 26 Nov 2009 10:30:27 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:30:26 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 10:30:26 -0800 Received: from [172.16.12.53] ([172.16.12.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id nAQIUMM94275; Thu, 26 Nov 2009 10:30:22 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <31438F18-2B8C-4011-B10E-D66F5F1DCED6@juniper.net> From: Dave Katz To: GAURAV HALWASIA In-Reply-To: <370232.65283.qm@web95303.mail.in2.yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail-1--367337387" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Query Regarding BFD Echo Mode Date: Thu, 26 Nov 2009 10:30:20 -0800 References: <370232.65283.qm@web95303.mail.in2.yahoo.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Nov 2009 18:30:26.0682 (UTC) FILETIME=[8627DDA0:01CA6EC6] Cc: BFD , Amitesh Shukla 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, 26 Nov 2009 18:37:15 -0000 --Apple-Mail-1--367337387 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 25, 2009, at 7:57 PM, GAURAV HALWASIA wrote: > Hi, > I have few doubts regarding the BFD Echo mode. > In case we have established BFD session in between A & B (A-------- > B) and have enabled Echo mode on A. System B must have indicated to > A that it can loop back the echo packets through the use of some non > zero Echo Rx intervel (X milli seconds) in any control packets > towards System A. > A. Now will A send some "Stream of BFD Echo packets" per X milli > seconds towards B or will A send only "single BFD Echo packet" per X > milli seconds. Further, In any case, what the detection time will be > in case of detecting failure through Echo Mode. I understand that > braft says clearly that it's outside it's scope but still any > pointer and sugession regarding the possible approach will be > helpful. It's whatever you want to do. The echo protocol is completely proprietary. If you're not sure what you want to do with it, you probably don't want to use it. > B. Further, till when these BFD Echo packets will be transmitted.? Until the session fails, or you decide not to. Some aspects of this are in scope (and in the spec.) > C. Base draft says that a seperate UDP port will be used for Echo > mode. i.e 3785. I assume that this UDP port will be opened on the > system where the Echo packets has to be received back after getting > loopbacked from the remote end (i.e on the system where the echo > mode is getting used for detectinf failure). Is my understanding > correct..? Well, that's the only system that is actually looking at the packets, so it would make sense. --Dave --Apple-Mail-1--367337387 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
On Nov 25, 2009, = at 7:57 PM, GAURAV HALWASIA wrote:

Hi,
I have few = doubts regarding the BFD Echo mode.
In case we = have established BFD session in between A & B (A--------B) and have = enabled Echo mode on A. System B must have indicated to A that it can = loop back the echo packets through the use of some non zero Echo Rx = intervel (X milli seconds) in any control packets towards System A. 
A. Now will A send some = "Stream of BFD Echo packets" per X milli seconds towards B or will A = send only "single BFD Echo packet" per X milli seconds. Further, In any = case, what the detection time will be in case of detecting failure = through Echo Mode. I understand that braft says clearly that it's = outside it's scope but still any pointer and sugession regarding the = possible approach  will be = helpful.

It's = whatever you want to do.  The echo protocol is completely = proprietary.  If you're not sure what you want to do with it, you = probably don't want to use it.

B. Further, till when these BFD Echo packets will be = transmitted.?

Until = the session fails, or you decide not to.  Some aspects of this are = in scope (and in the spec.)

C. Base draft says that a seperate UDP port will be = used for Echo mode. i.e 3785. I assume that this UDP port will be opened = on the system where the Echo packets has to be received back after = getting loopbacked from the remote end (i.e on the system where the echo = mode is getting used for detectinf failure). Is my understanding = correct..?

Well, = that's the only system that is actually looking at the packets, so it = would make = sense.

--Dave

= --Apple-Mail-1--367337387-- From gauravh278@yahoo.co.in Thu Nov 26 20:08:43 2009 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 3BE7B3A6886 for ; Thu, 26 Nov 2009 20:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 0Op6WA1FBz2S for ; Thu, 26 Nov 2009 20:08:42 -0800 (PST) Received: from web95313.mail.in2.yahoo.com (web95313.mail.in2.yahoo.com [203.104.18.213]) by core3.amsl.com (Postfix) with SMTP id 472D03A6846 for ; Thu, 26 Nov 2009 20:08:40 -0800 (PST) Received: (qmail 49890 invoked by uid 60001); 27 Nov 2009 04:08:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1259294914; bh=5vG4gDcuXN+PLaZ/POR8sg45a9TwGYItLpkPsIMTxVs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DOxloobvI1bHhXOtE+db461sxo/Scypf0J3V3zYs0+KbAN1EyYrYkGSB1pAnVcOIEdvE0+ZLOfUqfib7AvyLD1qi6BSuX9ZgOiqOTR7L17/zCuTyhYqbK/RY0Ts/r116jj5V169n5vq2Biq0HVhlb4LHnrkqRdxkshQCvHNnhjk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=k+TZWLo0DBrd7oDeSJnPcXqD5KYlVJh9muA53mSr4mQ5kbrgxXDw/eIm+exLUbPa5E+SKK3153I6WTWbH6StWj1Y//F+ZJYlDIyFmhrayKNltLoRBsAkh6+p/Yasb6JtWvjGuvfil89na18nkkGyh9h/jvtUJQtQ6yGxg46Ihfk=; Message-ID: <927871.48553.qm@web95313.mail.in2.yahoo.com> X-YMail-OSG: Hor9tnEVM1kH60goiI6gYQE_zVTV.tyjrigHne.pOT0K_T7oU3TYISxSpvMpjT6lJwmAdhb8536kYFb4FF_1hAktKD.qXn1O9W58.4iomRB2AHc0sVuMZb40zWNOFPnFO7wClOKMQwCd4t3GVqctbcuR2srB9RdcdGNr_Ao4aYYsRk1tLIn9KxAwZJUrsdAylpflTbGogUY_O2W.HzjsPGxWHJY6PpW0BvnCF9njDo4mgjx7TPkRRJ6gCtyfPKY1FmYRIjOUBX1gegj_xtoN Received: from [125.21.164.251] by web95313.mail.in2.yahoo.com via HTTP; Fri, 27 Nov 2009 09:38:34 IST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.7.361.4 References: <370232.65283.qm@web95303.mail.in2.yahoo.com> <31438F18-2B8C-4011-B10E-D66F5F1DCED6@juniper.net> Date: Fri, 27 Nov 2009 09:38:34 +0530 (IST) From: GAURAV HALWASIA Subject: Re: Query Regarding BFD Echo Mode To: Dave Katz In-Reply-To: <31438F18-2B8C-4011-B10E-D66F5F1DCED6@juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-261197499-1259294914=:48553" Cc: BFD , Amitesh Shukla 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: Fri, 27 Nov 2009 04:08:43 -0000 --0-261197499-1259294914=:48553 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave,=0A=0AThanks a lot for your inputs. I have one more query.=0A=0AAs = per the snip from the draft =0A=0A"Required Min Echo RX Interval=0A=0A=A0= =A0=A0=A0=A0 This is the minimum interval, in microseconds, between receive= d=0A=A0=A0=A0=A0=A0 BFD Echo packets that this system is capable of support= ing, less=0A=A0=A0=A0=A0=A0 any jitter applied by the sender (see section 6= .8.9).=A0 If this=0A=A0=A0=A0=A0=A0 value is zero, the transmitting system = does not support the=0A=A0=A0=A0=A0=A0 receipt of BFD Echo packets."=0A=0AS= o is this interval talking about the interval inbetween the individual Echo= Packets or is it the interval inbetween the stream of "Echo Packets". To m= e it looks like this is the interval in between the individual "Echo Packet= s".?=0AYour inputs/comments will be very useful and highly appreciated.=0A= =0AWith Best Regards,=0AGaurav=0A=0A=0A=0A=0A______________________________= __=0AFrom: Dave Katz =0ATo: GAURAV HALWASIA =0ACc: BFD ; Amitesh Shukla =0ASent: Fri, 27 November, 2009 12:00:20 AM=0ASubject: Re: Query R= egarding BFD Echo Mode=0A=0A=0A=0AOn Nov 25, 2009, at 7:57 PM, GAURAV HALWA= SIA wrote:=0A=0AHi,=0A>I have few doubts regarding the BFD Echo mode.=0A>In= case we have established BFD session in between A & B (A--------B) and hav= e enabled Echo mode on A. System B must have indicated to A that it can loo= p back the echo packets through the use of some non zero Echo Rx intervel (= X milli seconds) in any control packets towards System A.=A0=0A>A. Now will= A send some "Stream of BFD Echo packets" per X milli seconds towards B or = will A send only "single BFD Echo packet" per X milli seconds. Further, In = any case, what the detection time will be in case of detecting failure thro= ugh Echo Mode. I understand that braft says clearly that it's outside it's = scope but still any pointer and sugession regarding the possible approach = =A0will be helpful.=0AIt's whatever you want to do. =A0The echo protocol is= completely proprietary. =A0If you're not sure what you want to do with it,= you probably don't want to use it.=0A=0A=0AB. Further, till when these BFD= Echo packets will be transmitted.?=0AUntil the session fails, or you decid= e not to. =A0Some aspects of this are in scope (and in the spec.)=0A=0AC. B= ase draft says that a seperate UDP port will be used for Echo mode. i.e 378= 5. I assume that this UDP port will be opened on the system where the Echo = packets has to be received back after getting loopbacked from the remote en= d (i.e on the system where the echo mode is getting used for detectinf fail= ure). Is my understanding correct..?=0AWell, that's the only system that is= actually looking at the packets, so it would make sense.=0A=0A--Dave=0A=0A= =0A=0A The INTERNET now has a personality. YOURS! See your Yahoo! Home= page. http://in.yahoo.com/ --0-261197499-1259294914=:48553 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave,
=0A
 
=0A
Thanks a lot for your i= nputs. I have one more query.
=0A
 
=0A
As per the s= nip from the draft
=0A
 
=0A
"Required M= in Echo RX Interval

      This= is the minimum interval, in microseconds, between received
  =     BFD Echo packets that this system is capable of supporti= ng, less
      any jitter applied by the sender= (see section 6.8.9).  If this
      value= is zero, the transmitting system does not support the
   = ;   receipt of BFD Echo packets."
=0A
 
=0ASo is this interval talking about the interval inbetween the individual E= cho Packets or is it the interval inbetween the stream of "Echo Packets". T= o me it looks like this is the interval in between the individual "Echo Pac= kets".?
=0A
Your inputs/comments will be very useful and highly ap= preciated.
=0A
 
=0A
With Best Regards,
=0AGaurav
=0A

=0A
=0A
=0AFrom: Dave Katz &l= t;dkatz@juniper.net>
To:<= /B> GAURAV HALWASIA <gauravh278@yahoo.co.in>
Cc: BFD <rtg-bfd@ietf.org>; Amitesh Shukla= <amitesh.shukla@gmail.com>
S= ent: Fri, 27 November, 2009 12:00:20 AM
Subject: Re: Query Regarding BFD Echo Mode


=0A
=0A
On Nov 25, 2009, at 7:57 PM, GAURAV HALWASIA w= rote:

=0A
=0A
=0A
=0A
Hi,=0A
I have few doubts regarding the BFD Echo mo= de.
=0A
In case we have established BFD sess= ion in between A & B (A--------B) and have enabled Echo mode on A. Syst= em B must have indicated to A that it can loop back the echo packets throug= h the use of some non zero Echo Rx intervel (X milli seconds) in any contro= l packets towards System A. 
A. Now will A send some "Stream of BFD Echo packets" per X milli secon= ds towards B or will A send only "single BFD Echo packet" per X milli secon= ds. Further, In any case, what the detection time will be in case of detect= ing failure through Echo Mode. I understand that braft says clearly that it= 's outside it's scope but still any pointer and sugession regarding the pos= sible approach  will be helpful.
= =0A

It's whatever you want to do.  The echo protocol is = completely proprietary.  If you're not sure what you want to do with i= t, you probably don't want to use it.
=0A

=0A
=0A
=0A
=0A
= B. Further, till when these BFD Echo packets will be transmitted.?
=0A

Until the session fails, or = you decide not to.  Some aspects of this are in scope (and in the spec= .)
=0A

=0A
=0A
=0A
=0A
=0A
C. Base draft says th= at a seperate UDP port will be used for Echo mode. i.e 3785. I assume that = this UDP port will be opened on the system where the Echo packets has to be= received back after getting loopbacked from the remote end (i.e on the sys= tem where the echo mode is getting used for detectinf failure). Is my under= standing correct..?
=0A

= Well, that's the only system that is actually looking at the packets, so it= would make sense.
=0A

=0A
--Dave
=0A

<= /DIV>

=0A=0A=0A=0A
=0A= The INTERNET now has a personality. YOURS! See your Yahoo! Ho= mepage. --0-261197499-1259294914=:48553-- From rrahman@cisco.com Fri Nov 27 04:14:19 2009 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 DE4D63A676A for ; Fri, 27 Nov 2009 04:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 M160NpyVoa6r for ; Fri, 27 Nov 2009 04:14:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 30EBE3A6768 for ; Fri, 27 Nov 2009 04:14:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAN5QD0tAZnwN/2dsb2JhbACCIy2NXooGow+XQ4QxBA X-IronPort-AV: E=Sophos;i="4.47,300,1257120000"; d="scan'208,217";a="70592755" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Nov 2009 12:14:12 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nARCEC8p003109; Fri, 27 Nov 2009 12:14:12 GMT Received: from xmb-rtp-214.amer.cisco.com ([64.102.31.75]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 07:14:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6F5B.20C062BE" Subject: RE: Query Regarding BFD Echo Mode Date: Fri, 27 Nov 2009 07:14:09 -0500 Message-ID: In-Reply-To: <927871.48553.qm@web95313.mail.in2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query Regarding BFD Echo Mode Thread-Index: AcpvF06yYVYqbQfGRT2zd7xR4vNQlgAQ7Khg References: <370232.65283.qm@web95303.mail.in2.yahoo.com><31438F18-2B8C-4011-B10E-D66F5F1DCED6@juniper.net> <927871.48553.qm@web95313.mail.in2.yahoo.com> From: "Reshad Rahman (rrahman)" To: "GAURAV HALWASIA" , "Dave Katz" X-OriginalArrivalTime: 27 Nov 2009 12:14:11.0980 (UTC) FILETIME=[20FF74C0:01CA6F5B] Cc: BFD , Amitesh Shukla 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: Fri, 27 Nov 2009 12:14:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6F5B.20C062BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the interval between individual packets for that particular BFD session. =20 Regards, Reshad. =20 From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of GAURAV HALWASIA Sent: Thursday, November 26, 2009 11:09 PM To: Dave Katz Cc: BFD; Amitesh Shukla Subject: Re: Query Regarding BFD Echo Mode =20 Hi Dave, =20 Thanks a lot for your inputs. I have one more query. =20 As per the snip from the draft=20 =20 "Required Min Echo RX Interval This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.9). If this value is zero, the transmitting system does not support the receipt of BFD Echo packets." =20 So is this interval talking about the interval inbetween the individual Echo Packets or is it the interval inbetween the stream of "Echo Packets". To me it looks like this is the interval in between the individual "Echo Packets".? Your inputs/comments will be very useful and highly appreciated. =20 With Best Regards, Gaurav =20 ________________________________ From: Dave Katz To: GAURAV HALWASIA Cc: BFD ; Amitesh Shukla Sent: Fri, 27 November, 2009 12:00:20 AM Subject: Re: Query Regarding BFD Echo Mode On Nov 25, 2009, at 7:57 PM, GAURAV HALWASIA wrote: Hi, I have few doubts regarding the BFD Echo mode. In case we have established BFD session in between A & B (A--------B) and have enabled Echo mode on A. System B must have indicated to A that it can loop back the echo packets through the use of some non zero Echo Rx intervel (X milli seconds) in any control packets towards System A.=20 A. Now will A send some "Stream of BFD Echo packets" per X milli seconds towards B or will A send only "single BFD Echo packet" per X milli seconds. Further, In any case, what the detection time will be in case of detecting failure through Echo Mode. I understand that braft says clearly that it's outside it's scope but still any pointer and sugession regarding the possible approach will be helpful. =20 It's whatever you want to do. The echo protocol is completely proprietary. If you're not sure what you want to do with it, you probably don't want to use it. B. Further, till when these BFD Echo packets will be transmitted.? =20 Until the session fails, or you decide not to. Some aspects of this are in scope (and in the spec.) =20 C. Base draft says that a seperate UDP port will be used for Echo mode. i.e 3785. I assume that this UDP port will be opened on the system where the Echo packets has to be received back after getting loopbacked from the remote end (i.e on the system where the echo mode is getting used for detectinf failure). Is my understanding correct..? =20 Well, that's the only system that is actually looking at the packets, so it would make sense. =20 --Dave =20 ________________________________ The INTERNET now has a personality. YOURS! See your Yahoo! Homepage . ------_=_NextPart_001_01CA6F5B.20C062BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is the interval between individual packets for that particular BFD session.

 

Regards,

Reshad.

 

From:= rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of GAURAV HALWASIA
Sent: Thursday, November 26, 2009 11:09 PM
To: Dave Katz
Cc: BFD; Amitesh Shukla
Subject: Re: Query Regarding BFD Echo Mode

 

Hi = Dave,

 

Thanks a lot for your inputs. I have one more query.

 

As = per the snip from the draft

 

"Required Min Echo RX = Interval

      This is the minimum interval, in = microseconds, between received
      BFD Echo packets that this system is = capable of supporting, less
      any jitter applied by the sender (see = section 6.8.9).  If this
      value is zero, the transmitting system = does not support the
      receipt of BFD Echo = packets."

 

So = is this interval talking about the interval inbetween the individual Echo = Packets or is it the interval inbetween the stream of "Echo Packets". To me = it looks like this is the interval in between the individual "Echo Packets".?

Your inputs/comments will be very useful and highly = appreciated.

 

With Best Regards,

Gaurav

 

From: Dave Katz = <dkatz@juniper.net>
To: GAURAV HALWASIA <gauravh278@yahoo.co.in>
Cc: BFD <rtg-bfd@ietf.org>; Amitesh Shukla <amitesh.shukla@gmail.com>
Sent: Fri, 27 November, 2009 12:00:20 AM
Subject: Re: Query Regarding BFD Echo Mode

On Nov 25, 2009, at 7:57 PM, GAURAV HALWASIA = wrote:



Hi,

I have few doubts regarding the BFD Echo mode.

In case we have established BFD session in between A & B (A--------B) = and have enabled Echo mode on A. System B must have indicated to A that it can = loop back the echo packets through the use of some non zero Echo Rx intervel (X = milli seconds) in any control packets towards System A. 
A. Now will A send some "Stream of BFD Echo packets" per X = milli seconds towards B or will A send only "single BFD Echo packet" = per X milli seconds. Further, In any case, what the detection time will be in = case of detecting failure through Echo Mode. I understand that braft says = clearly that it's outside it's scope but still any pointer and sugession regarding = the possible approach  will be helpful.

 

It's whatever you want to do.  The echo = protocol is completely proprietary.  If you're not sure what you want to do = with it, you probably don't want to use it.



B. Further, till when these BFD Echo packets will be = transmitted.?

 

Until the session fails, or you decide not to. =  Some aspects of this are in scope (and in the spec.)

 

C. Base draft says that a seperate UDP port will be used for Echo mode. i.e = 3785. I assume that this UDP port will be opened on the system where the Echo = packets has to be received back after getting loopbacked from the remote end = (i.e on the system where the echo mode is getting used for detectinf failure). = Is my understanding correct..?

 

Well, that's the only system that is actually = looking at the packets, so it would make sense.

 

--Dave

 



The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.

------_=_NextPart_001_01CA6F5B.20C062BE--