From ldunbar@huawei.com Fri Oct 2 12:34:05 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 45E263A6842 for ; Fri, 2 Oct 2009 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.602, 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 n+u0Zgo0CS1I for ; Fri, 2 Oct 2009 12:33:51 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E323A3A6A14 for ; Fri, 2 Oct 2009 12:33:50 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQW00GJWJQNV4@usaga04-in.huawei.com> for rtg-bfd@ietf.org; Fri, 02 Oct 2009 14:35:12 -0500 (CDT) Received: from L735042 ([10.124.12.51]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQW0099DJQL3M@usaga04-in.huawei.com> for rtg-bfd@ietf.org; Fri, 02 Oct 2009 14:35:11 -0500 (CDT) Date: Fri, 02 Oct 2009 14:35:09 -0500 From: Linda Dunbar Subject: The usage of "Concatenation" in BFD spec. In-reply-to: <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> To: 'Dave Katz' Message-id: <004f01ca4397$7489c8b0$330c7c0a@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_/s0sEsqNqPoItQ03CjGj6g)" Thread-index: AcpAcvqzvEDQ6/xjSoKgC3LMfzMU3gDA7ycg References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> Cc: rtg-bfd@ietf.org, dward@cisco.com, dkatz@juniper.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: Fri, 02 Oct 2009 19:34:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/s0sEsqNqPoItQ03CjGj6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave, Thank you very much for the detailed description. It really helped me to understand the specification much better. As for "Concatenated Path", you are right that the Oxford Dictionary defines "concatenation" as "series of linked things or events". The only problem is that huge deployed bases of Optical interfaces (OC192, OC48, etc) conform to GR253's definition of concatenation which is to form a fatter pipe (like STS-3c, STS-48c, STS192c). Those optical interfaces (OC192, OC48, OC12) are present on all deployed routers/switches and transport equipment. PW uses "stitch" to refer combining multiple segments. Can BFD use "stitch" too? If you still think that "Concatenated Path" is a better way, then you should add a "Definition Section" in the document to explain it clearly. I am sure that I am not the only one being confused by this. Linda _____ From: Dave Katz [mailto:dkatz@juniper.net] Sent: Monday, September 28, 2009 2:26 PM To: Linda Dunbar Cc: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: Re: How to enforce BFD to be sent over different paths between two systems? On Sep 23, 2009, at 10:34 AM, Linda Dunbar wrote: Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of systems transmit BFD packets periodically over each path between the two systems". Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed? The idea is that a BFD session protects a path, and if multiple paths are present, the operator/implementor can protect any or all of them. "Enforcement" is outside the scope, but is most often a matter of configuration (configuring BFD to run on an interface or an LSP or whatever it may be.) 2. The Echo function is pretty much like "Ping". Each system can initiate a "Ping" to another system. Is "periodic Ping" an accurate description of the "Echo function"? More or less, with two additions. First, the echo protocol itself is unspecified, so implementors can put whatever they want in the packets, and this could presumably have some additional added value. Second, the failure of the echo protocol is reflected in the control protocol, so there is a standardized (more or less) mechanism to signal that failure to the far end and to react to the failure. 3. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD implementation share fate with its control plane". Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol? Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system's control plane? The most common reason to share fate with the control plane is to implement BFD in the control plane, which is where many implementations start. BFD doesn't know or care about whether zero or more routing protocols are running; the protocol is protecting the data path over which the routing protocol runs. How BFD interacts with some or all of those protocols is outside the spec (though strongly hinted at in the Generic spec.) We have taken pains to keep BFD very loosely coupled with the rest of the system; BFD tests the path, and if it detects a failure, other parts of the system (typically routing protocols) are advised of this. If multiple routing protocols are running over IPv4, there will be a single BFD session running over the IPv4 path between systems, and a failure of that BFD session would typically be signaled to each protocol. 4. The BFD's Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)? Because it is not necessary to signal them in this way; the bits would be redundant and/or useless. 4. 5. Is the Discriminator field of the BFD' Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems? That's what we called it. It discriminates between multiple sessions between the same pair of systems. 5. 6. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path? In my dictionary, "concatenation" is the process of hooking things together "in a chain or series." Bundling is not concatenation, at least in the general definition of the word, since it is parallel. The point of this section is to point out that an end-to-end path may be stitched together out of segments of various technologies, and BFD may run over only part of this end-to-end path. If a failure is detected by other means on an adjacent segment (say, OAM), this can be signaled through BFD to the system connecting to the next segment, with the idea that the failure can be signaled all the way to the end, even though the bit over which BFD is running may not have failed itself. This is an interworking hack. 7. Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo? No, just my somewhat arcane choice of wording. "In concert with" means "along with" or "in combination with". 7. Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_/s0sEsqNqPoItQ03CjGj6g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave,

 

Thank you very much for the detailed description. It really helped me to understand the specification much better.

 

As for “Concatenated Path”, you are right that the Oxford Dictionary defines “concatenation” as “series of linked things or events”. The only problem is that huge deployed bases of Optical interfaces (OC192, OC48, etc) conform to GR253’s definition of concatenation which is to form a fatter pipe (like STS-3c, STS-48c, STS192c). Those optical interfaces (OC192, OC48, OC12) are present on all deployed routers/switches and transport equipment.

 

PW uses “stitch” to refer combining multiple segments. Can BFD use “stitch” too?  If you still think that “Concatenated Path” is a better way, then you should add a “Definition Section” in the document to explain it clearly. I am sure that I am not the only one being confused by this.

 

Linda

 

 

 

From: Dave Katz [mailto:dkatz@juniper.net]
Sent: Monday, September 28, 2009 2:26 PM
To: Linda Dunbar
Cc: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: Re: How to enforce BFD to be sent over different paths between two systems?

 

 

On Sep 23, 2009, at 10:34 AM, Linda Dunbar wrote:



Dave,

 

I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

1.      Section 3: 3rd line of the first paragraph states “A pair of systems transmit BFD packets periodically over each path between the two systems”.

 

Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed?

 

The idea is that a BFD session protects a path, and if multiple paths are present, the operator/implementor can protect any or all of them.  "Enforcement" is outside the scope, but is most often a matter of configuration (configuring BFD to run on an interface or an LSP or whatever it may be.)



 

2.      The Echo function is pretty much like “Ping”. Each system can initiate a “Ping” to another system. Is “periodic Ping” an accurate description of the “Echo function”?

 

 

More or less, with two additions.  First, the echo protocol itself is unspecified, so implementors can put whatever they want in the packets, and this could presumably have some additional added value.  Second, the failure of the echo protocol is reflected in the control protocol, so there is a standardized (more or less) mechanism to signal that failure to the far end and to react to the failure.



 

3.      Section 4.1 under the “Control Plane Independent” sub-section:

The first paragraph states “if clear, the transmitting system’s BFD implementation share fate with its control plane”.

Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol?    Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system’s control plane?

 

The most common reason to share fate with the control plane is to implement BFD in the control plane, which is where many implementations start.  BFD doesn't know or care about whether zero or more routing protocols are running;  the protocol is protecting the data path over which the routing protocol runs.  How BFD interacts with some or all of those protocols is outside the spec (though strongly hinted at in the Generic spec.)  We have taken pains to keep BFD very loosely coupled with the rest of the system;  BFD tests the path, and if it detects a failure, other parts of the system (typically routing protocols) are advised of this.

 

If multiple routing protocols are running over IPv4, there will be a single BFD session running over the IPv4 path between systems, and a failure of that BFD session would typically be signaled to each protocol.



 

4.      The BFD’s Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)?

 

Because it is not necessary to signal them in this way;  the bits would be redundant and/or useless.



4.       

5.      Is the Discriminator field of the BFD’ Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems?

 

That's what we called it.  It discriminates between multiple sessions between the same pair of systems.



5.       

 

6.      Section 6.18.17 Concatenated Paths

In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path?

 

In my dictionary, "concatenation" is the process of hooking things together "in a chain or series."  Bundling is not concatenation, at least in the general definition of the word, since it is parallel.

 

The point of this section is to point out that an end-to-end path may be stitched together out of segments of various technologies, and BFD may run over only part of this end-to-end path.  If a failure is detected by other means on an adjacent segment (say, OAM), this can be signaled through BFD to the system connecting to the next segment, with the idea that the failure can be signaled all the way to the end, even though the bit over which BFD is running may not have failed itself.

 

This is an interworking hack.



 

7.      Editorial: Section 2 Design: 6th line of the first paragraph: “making it useful in concert with”? Is it a typo?

 

No, just my somewhat arcane choice of wording.  "In concert with" means "along with" or "in combination with".

 



7.       

 

Thank you very much for helping me.

 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

 

--Boundary_(ID_/s0sEsqNqPoItQ03CjGj6g)-- From dkatz@juniper.net Fri Oct 2 13:11: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 61B693A67D2 for ; Fri, 2 Oct 2009 13:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 6nnI5Q9Vgu5Z for ; Fri, 2 Oct 2009 13:11:06 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 2217B3A67C1 for ; Fri, 2 Oct 2009 13:11:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSsZeste3c2NsVmp1tlmWxq7LSFPWUhct@postini.com; Fri, 02 Oct 2009 13:12:35 PDT 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; Fri, 2 Oct 2009 13:07:43 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 13:07:43 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 13:07:43 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 13:07:43 -0700 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 n92K7gM84072 for ; Fri, 2 Oct 2009 13:07:42 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <5D2E194A-F922-4D83-AF76-162B2F206684@juniper.net> From: Dave Katz To: "rtg-bfd@ietf.org WG" In-Reply-To: <004f01ca4397$7489c8b0$330c7c0a@china.huawei.com> Content-Type: multipart/alternative; boundary="Apple-Mail-14--818528157" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: The usage of "Concatenation" in BFD spec. Date: Fri, 2 Oct 2009 14:07:42 -0600 References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> <004f01ca4397$7489c8b0$330c7c0a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Oct 2009 20:07:43.0220 (UTC) FILETIME=[0048A340:01CA439C] 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, 02 Oct 2009 20:11:07 -0000 --Apple-Mail-14--818528157 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Our good friends at Bellcore used an unfortunate choice of =20 terminology, alas. It is technically true, if you squint, in that the =20= frames that would have been interleaved in a channelized pipe are =20 serialized (one after the other) in the OCxC pipe, and so are =20 concatenated in that sense, but this creates an obviously misleading =20 impression. I can add a parenthetical insertion that disambiguates it, but given =20 that the spec is in the final throes of last call, ready for RFC and =20 the standards track, I'm loathe to start changing terminology at this =20= late date. --Dave On Oct 2, 2009, at 1:35 PM, Linda Dunbar wrote: > Dave, > > Thank you very much for the detailed description. It really helped =20 > me to understand the specification much better. > > As for =93Concatenated Path=94, you are right that the Oxford = Dictionary =20 > defines =93concatenation=94 as =93series of linked things or events=94. = The =20 > only problem is that huge deployed bases of Optical interfaces =20 > (OC192, OC48, etc) conform to GR253=92s definition of concatenation =20= > which is to form a fatter pipe (like STS-3c, STS-48c, STS192c). =20 > Those optical interfaces (OC192, OC48, OC12) are present on all =20 > deployed routers/switches and transport equipment. > > PW uses =93stitch=94 to refer combining multiple segments. Can BFD use = =20 > =93stitch=94 too? If you still think that =93Concatenated Path=94 is = a =20 > better way, then you should add a =93Definition Section=94 in the =20 > document to explain it clearly. I am sure that I am not the only one =20= > being confused by this. > --Apple-Mail-14--818528157 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable Our good friends at Bellcore = used an unfortunate choice of terminology, alas.  It is technically = true, if you squint, in that the frames that would have been interleaved = in a channelized pipe are serialized (one after the other) in the OCxC = pipe, and so are concatenated in that sense, but this creates an = obviously misleading impression.

I can add a = parenthetical insertion that disambiguates it, but given that the spec = is in the final throes of last call, ready for RFC and the standards = track, I'm loathe to start changing terminology at this late = date.

--Dave

On Oct 2, = 2009, at 1:35 PM, Linda Dunbar wrote:

 
Thank you very much for the = detailed description. It really helped me to understand the = specification much better.
As for =93Concatenated Path=94, you are right that the = Oxford Dictionary defines =93concatenation=94 as =93series of linked = things or events=94. The only problem is that huge deployed bases of = Optical interfaces (OC192, OC48, etc) conform to GR253=92s definition of = concatenation which is to form a fatter pipe (like STS-3c, STS-48c, = STS192c). Those optical interfaces (OC192, OC48, OC12) are present on = all deployed routers/switches and transport = equipment.
 
PW uses =93stitch=94 to refer = combining multiple segments. Can BFD use =93stitch=94 too?  If you = still think that =93Concatenated Path=94 is a better way, then you = should add a =93Definition Section=94 in the document to explain it = clearly. I am sure that I am not the only one being confused by = this.
In-Reply-To: <98104C07-A927-4412-A54B-5539A2F558DA@cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: The usage of "Concatenation" in BFD spec. Date: Fri, 2 Oct 2009 14:08:17 -0600 References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> <004f01ca4397$7489c8b0$330c7c0a@china.huawei.com> <98104C07-A927-4412-A54B-5539A2F558DA@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Oct 2009 20:08:17.0786 (UTC) FILETIME=[14E2FDA0:01CA439C] 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, 02 Oct 2009 20:11:37 -0000 As has been pointed out to me privately, the terminology has been completely messed up by the definition of "virtual concatenation", which is a parallel bundle of pipes over which a "concatenated" pipe is reverse-muxed. This effectively destroys the usefulness of the term. Perhaps we can get the folks at Lake Superior State to add it to this year's list of banned words. ;-) --Dave On Oct 2, 2009, at 1:43 PM, David Ward wrote: > Linda - > > So far, you are the first to ask :-) > > Nonetheless, the functionality is about to be deprecated for PWE as > that WG is going to use status signaling and not BFD. The PWE WG was > the origination of "concatenated path" (where the request for the > diag came from) so, unfort we couldn't change without a lengthy > interaction/exchange with that WG. From dkatz@juniper.net Fri Oct 2 14:17:29 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 06F963A68D7 for ; Fri, 2 Oct 2009 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 aQxzQnZq2ZdR for ; Fri, 2 Oct 2009 14:17:28 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id D73723A67E9 for ; Fri, 2 Oct 2009 14:17:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSsZuNPAFhiSbXEFPTVADCs8KTEmzBIxW@postini.com; Fri, 02 Oct 2009 14:18:57 PDT 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; Fri, 2 Oct 2009 14:16:22 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 14:16:22 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 14:16:21 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 14:16:21 -0700 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 n92LGKM85603; Fri, 2 Oct 2009 14:16:21 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <5E8AAFEC-5600-417C-94E6-348EB8A53278@juniper.net> From: Dave Katz To: Linda Dunbar In-Reply-To: <008d01ca43a2$fb5a4300$330c7c0a@china.huawei.com> Content-Type: multipart/alternative; boundary="Apple-Mail-16--814410516" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: The usage of "Concatenation" in BFD spec. Date: Fri, 2 Oct 2009 15:16:19 -0600 References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> <004f01ca4397$7489c8b0$330c7c0a@china.huawei.com> <67FB774C-5419-4958-BDC1-8D5B127A6207@juniper.net> <008d01ca43a2$fb5a4300$330c7c0a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Oct 2009 21:16:21.0413 (UTC) FILETIME=[96EB0550:01CA43A5] 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: Fri, 02 Oct 2009 21:17:29 -0000 --Apple-Mail-16--814410516 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I've already done so... --Dave On Oct 2, 2009, at 2:57 PM, Linda Dunbar wrote: > It would be very helpful to add a parenthetical insertion that > disambiguates it > > Linda --Apple-Mail-16--814410516 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I've already done = so...

--Dave

On Oct 2, 2009, = at 2:57 PM, Linda Dunbar wrote:

It would be = very helpful to add a parenthetical insertion that disambiguates = it 

= --Apple-Mail-16--814410516-- From ldunbar@huawei.com Wed Oct 7 07:57:33 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 D88093A6AAE for ; Wed, 7 Oct 2009 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 xUgQwrWroGV6 for ; Wed, 7 Oct 2009 07:57:25 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id AB6D53A6AA9 for ; Wed, 7 Oct 2009 07:57:25 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR500JNCGAGH1@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 07 Oct 2009 07:59:05 -0700 (PDT) Received: from L735042 ([10.124.12.51]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR500M40GAF3Q@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 07 Oct 2009 07:59:04 -0700 (PDT) Date: Wed, 07 Oct 2009 09:59:03 -0500 From: Linda Dunbar Subject: RE: More questions on "draft-ietf-bfd-base-09.txt" In-reply-to: To: 'Linda Dunbar' , 'Dave Katz' , rtg-bfd@ietf.org Message-id: <001e01ca475e$b5fc4ff0$330c7c0a@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_Rz7SElYfupgmZ+k9uX/XlA)" Thread-index: AcpG2aIKeVlkYCLbTCGtGASAKftvigAhMxwQ References: 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, 07 Oct 2009 14:57:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Rz7SElYfupgmZ+k9uX/XlA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave, My email was bounced back by rtg-bfd alias due to the size being too large. So I will send the PDF file marked with my comments directly to you. Here are my questions and hope you can help. Thanks, Linda _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, October 06, 2009 6:06 PM To: 'Dave Katz'; 'rtg-bfd@ietf.org' Subject: More questions on "draft-ietf-bfd-base-09.txt" Hi Dave, Thank you very much for answering my questions last week. Now I do see unique values of BFD, comparing to IEEE802.1ag. I was very actively involved in IEEE802.1ag's development for a few years. BFD is simpler than IEEE802.1ag and has some useful features, such as its Demand mode, which IEEE802.1ag doesn't have. I think Demand Mode is very useful in reducing the processing power imposed on systems. Here are some more questions. Hope you can help me again. - Section 3 Protocol Overview, 2nd paragraph: "A path is only declared to be operational when two way communication has been established ." My comment: Under the context of MPLS, "a path", i.e. LSP, is always uni-directional. So it is not correct to declare a path being operational when two way communication is established. My suggestion: Should have an entity which binds two uni-directional paths in the BFD context, or paired paths. Then you can easily say a path in the pair (or in the entity) is declared operational when two way communication is established. Even though the specification doesn't have to specify how two paths are associated, it is worthwhile to have an entity to bind two uni-directional paths together in the BFD document. The "My (Your) Discriminator" in the BFD control packet should have "Entity identifier" embedded in. - I don't see ECHO reply packet from remote system defined anywhere in the document. I would think that it is necessary to have an ECHO reply message which includes the original ECHO packet plus some information from the remote system. Why? - Section 6.8.5: Is the "Detecting Failures with Echo Function" referring to the system who initiates "Echo"? The system which loops back Echo shouldn't have any failure related to Echo, should it? - The BFD Control Packet has "Required Min RX Interval" and "Required Min Echo RX Interval". When "Required Min RX Interval" is set to zero, can remote system still send Echo frame? If yes, then the description for Required Min RX Interval should be more accurate. - Questions on State Machine of BFD: o The second last paragraph of Section 6.2 indicates "Once a session has been declared down, it cannot come back until remote end first signals that it is down". What if the local system goes down by provisioning, and decides to turn up. Why have to wait for the remote end to go down first? o Why "Admin Down" is not on the state machine? o When local system is Down state, why the BFD packet from remote system with DOWN status transition the state machine from "DOWN" to "INIT" state? I thought it should be INIT state from remote node to trigger the local node to go to INIT state. - Section 6.8.16: Why set SessionState to Down when Enabling a session? Should it be "INIT"? - In the Introduction and overview sections, the word "adjacent systems/forwarding engines" is used frequently. For example, the first sentence of the Introduction stated: the rapid detection of communication failures between adjacent systems. However, the sections in the latter part of the specification use "two systems", or "pair of systems". My question: are they referring to the same thing? Does the "adjacent" in the overview sections mean neighboring node as in OSPF's neighbors or two systems on two ends of the path for BFD session? - Section 2 Design, the first paragraph: What does it mean by saying "failure in communication with a forwarding plane next hop"? Why next hop? The rest of the specification uses "two systems", "remote system", etc, which I think is more accurate. In addition, all forwarding engines are unidirectional. Who impose the bi-directional property on forwarding engines? Do you mean BFD is to detect failures between two forwarding engines which face (or peer with) each other for some applications? - Section 4.1, under "Diagnostic (Diag)": 3 -- Neighbor Signaled Session Down Should "remote node (or system)" be more accurate description than the "Neighbor"? - End of the first paragraph of Section 2, it stated that BFD implemented in Control Plane may preclude the detection of some kinds of failure. What kind of failures will be precluded? - Section 3.1, last sentence of the first paragraph: you stated that BFD can run between two OSPF neighbors. Why you need to run BFD between two OSPF neighbors? If the two immediate neighbors need to discover connectivity to each other faster, HELLO timer can be set shorter. I have some editorial comments marked on the enclosed PDF file. Please have a look. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_Rz7SElYfupgmZ+k9uX/XlA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave,

 

My email was bounced back by rtg-bfd alias due to the size being too large. So I will send the PDF file marked with my comments directly to you.

 

Here are my questions and hope you can help.

 

Thanks, Linda

 

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, October 06, 2009 6:06 PM
To: 'Dave Katz'; 'rtg-bfd@ietf.org'
Subject: More questions on "draft-ietf-bfd-base-09.txt"

 

Hi Dave,

 

Thank you very much for answering my questions last week. Now I do see unique values of BFD, comparing to IEEE802.1ag. I was very actively involved in IEEE802.1ag’s development for a few years. BFD is simpler than IEEE802.1ag and has some useful features, such as its Demand mode, which IEEE802.1ag doesn’t have. I think Demand Mode is very useful in reducing the processing power imposed on systems. Here are some more questions. Hope you can help me again.

 

-          Section 3 Protocol Overview, 2nd paragraph: “A path is only declared to be operational when two way communication has been established …”

 

My comment:  Under the context of MPLS, “a path”, i.e. LSP, is always uni-directional. So it is not correct to declare a path being operational when two way communication is established.

 

My suggestion: Should have an entity which binds two uni-directional paths in the BFD context, or paired paths. Then you can easily say a path in the pair (or in the entity) is declared operational when two way communication is established. Even though the specification doesn’t have to specify how two paths are associated, it is worthwhile to have an entity to bind two uni-directional paths together in the BFD document. The “My (Your) Discriminator” in the BFD control packet should have “Entity identifier” embedded in.

 

-          I don’t see ECHO reply packet from remote system defined anywhere in the document. I would think that it is necessary to have an ECHO reply message which includes the original ECHO packet plus some information from the remote system. Why?

 

-          Section 6.8.5: Is the “Detecting Failures with Echo Function” referring to the system who initiates “Echo”?  

 

The system which loops back Echo shouldn’t have any failure related to Echo, should it?

 

-          The BFD Control Packet has “Required Min RX Interval” and “Required Min Echo RX Interval”. When “Required Min RX Interval” is set to zero, can remote system still send Echo frame? If yes, then the description for Required Min RX Interval should be more accurate.

 

-          Questions on State Machine of BFD:

 

o       The second last paragraph of Section 6.2 indicates “Once a session has been declared down, it cannot come back until remote end first signals that it is down”. What if the local system goes down by provisioning, and decides to turn up. Why have to wait for the remote end to go down first?

o       Why “Admin Down” is not on the state machine?

o       When local system is Down state, why the BFD packet from remote system with DOWN status transition the state machine from “DOWN” to “INIT” state? I thought it should be INIT state from remote node to trigger the local node to go to INIT state.

 

-          Section 6.8.16: Why set SessionState to Down when Enabling a session? Should it be “INIT”?

 

 

-          In the Introduction and overview sections, the word “adjacent systems/forwarding engines” is used frequently. For example, the first sentence of the Introduction stated: the rapid detection of communication failures between adjacent systems.

However, the sections in the latter part of the specification use “two systems”, or “pair of systems”.

 

My question: are they referring to the same thing? Does the “adjacent” in the overview sections mean neighboring node as in OSPF’s neighbors or two systems on two ends of the path for BFD session?

 

-          Section 2 Design, the first paragraph:

What does it mean by saying "failure in communication with a forwarding plane next hop"? Why next hop? The rest of the specification uses “two systems”, “remote system”, etc, which I think is more accurate.

 

In addition, all forwarding engines are unidirectional.  Who impose the bi-directional property on forwarding engines?

 

Do you mean BFD is to detect failures between two forwarding engines which face (or peer with) each other for some applications? 

 

 

-          Section 4.1, under “Diagnostic (Diag)”:

3 -- Neighbor Signaled Session Down

Should “remote node (or system)” be more accurate description than the “Neighbor”?

 

-          End of the first paragraph of Section 2, it stated that BFD implemented in Control Plane may preclude the detection of some kinds of failure. What kind of failures will be precluded?

 

 

-          Section 3.1, last sentence of the first paragraph: you stated that BFD can run between two OSPF neighbors. Why you need to run BFD between two OSPF neighbors? If the two immediate neighbors need to discover connectivity to each other faster, HELLO timer can be set shorter.

 

 

I have some editorial comments marked on the enclosed PDF file. Please have a look.

 

 

Best Regards, Linda Dunbar

 

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_Rz7SElYfupgmZ+k9uX/XlA)-- From vishwas.ietf@gmail.com Wed Oct 7 10:20:58 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 9A30E3A687B for ; Wed, 7 Oct 2009 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 cG97g7CHhXCf for ; Wed, 7 Oct 2009 10:20:57 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 5A1713A67FC for ; Wed, 7 Oct 2009 10:20:57 -0700 (PDT) Received: by ywh9 with SMTP id 9so5555750ywh.19 for ; Wed, 07 Oct 2009 10:22:33 -0700 (PDT) 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=i4WbsR/tA91n9UQwS/FXR/2nVU8mO7VG5n0DINcrekQ=; b=GsnReC8Bi73o/IbTVXtYFNtSJr05H3q21l1fmew6l35dl/I9Rni9W9m36mCAeNnbZv g+JsvCOS4NcCzl55I8i7nkuRy2/Mhu5TWv2ytVwZSgh7yCk4ueB96TrfGhuvnn3JYtMl /xGS4cX3/mO2XE5QmpzR9q+PvodQJPgn6gGGw= 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=gENjsuuXX9T9LLKa1mzAi5ym+i/BfHsIvQUkpBGBRqNIk3LXeiwLU9TRalSe/mQvHP 1RJTEYWnAaN6FMSpsfisDZldSd8elkzDVOWP+/vqvlnHcBVcYkd1dnrlv4S7+e0hRhlH ZV3h7c7OSm/OJt5FhixeXBT4GkP/vGfoLhHvo= MIME-Version: 1.0 Received: by 10.150.89.3 with SMTP id m3mr450574ybb.186.1254936153912; Wed, 07 Oct 2009 10:22:33 -0700 (PDT) In-Reply-To: <001e01ca475e$b5fc4ff0$330c7c0a@china.huawei.com> References: <001e01ca475e$b5fc4ff0$330c7c0a@china.huawei.com> Date: Wed, 7 Oct 2009 10:22:33 -0700 Message-ID: <77ead0ec0910071022s64f0a0a6rd4e522a031a44970@mail.gmail.com> Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, Dave Katz 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, 07 Oct 2009 17:20:58 -0000 Hi Linda, Good to see you have spent quite an effort preparing and doing such an indepth review. > Thank you very much for answering my questions last week. Now I do see > unique values of BFD, comparing to IEEE802.1ag. I was very actively invol= ved > in IEEE802.1ag=92s development for a few years. BFD is simpler than > IEEE802.1ag and has some useful features, such as its Demand mode, which > IEEE802.1ag doesn=92t have. I think Demand Mode is very useful in reducin= g the > processing power imposed on systems. Here are some more questions. Hope y= ou > can help me again. Great to know you were so instrumental in 802.1ag. Yes BFD is a good CC protocol. The base protocol however does not provide all the other functionality like Locking etc. There are additional drafts under consideration for each of the other functionalities extending BFD. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3 Protocol Overview, 2nd paragraph: = =93A path is only > declared to be operational when two way communication has been establishe= d > =85=94 > My comment: =A0Under the context of MPLS, =93a path=94, i.e. LSP, is alwa= ys > uni-directional. So it is not correct to declare a path being operational > when two way communication is established. For the BFD case if we only have unidirectional LSP's there has to be an off path mechanism to transfer packets in the other direction, otherwise BFD will not be able to operate over such a scenario. > My suggestion: Should have an entity which binds two uni-directional path= s > in the BFD context, or paired paths. Then you can easily say a path in th= e > pair (or in the entity) is declared operational when two way communicatio= n > is established. Even though the specification doesn=92t have to specify h= ow > two paths are associated, it is worthwhile to have an entity to bind two > uni-directional paths together in the BFD document. The =93My (Your) > Discriminator=94 in the BFD control packet should have =93Entity identifi= er=94 > embedded in. To see how BFD works with MPLS LSP or over Pseudowire you can look at http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07 http://tools.ietf.org/html/draft-ietf-bfd-mpls-07 > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 I don=92t see ECHO reply packet from remote = system defined anywhere > in the document. I would think that it is necessary to have an ECHO reply > message which includes the original ECHO packet plus some information fro= m > the remote system. Why? The format of the echo packet is outside the scope of the spec. This is because the echo packet is only processed and received only by the sender. It is forwarded from the peers forwarding plane. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.5: Is the =93Detecting Failures = with Echo Function=94 > referring to the system who initiates =93Echo=94? That is correct. > The system which loops back Echo shouldn=92t have any failure related to = Echo, > should it? It would not know. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The BFD Control Packet has =93Required Min R= X Interval=94 and > =93Required Min Echo RX Interval=94. When =93Required Min RX Interval=94 = is set to > zero, can remote system still send Echo frame? If yes, then the descripti= on > for Required Min RX Interval should be more accurate. Yes. For echo's the "Required Min Echo RX Interval" is used instead. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Questions on State Machine of BFD: > > o=A0=A0=A0=A0=A0=A0 The second last paragraph of Section 6.2 indicates = =93Once a session > has been declared down, it cannot come back until remote end first signal= s > that it is down=94. What if the local system goes down by provisioning, a= nd > decides to turn up. Why have to wait for the remote end to go down first? The question is not clear. > o=A0=A0=A0=A0=A0=A0 Why =93Admin Down=94 is not on the state machine? It could have been added to the diagram. though there is only one transition out of it is the ADMIN UP state and to the down state. > o=A0=A0=A0=A0=A0=A0 When local system is Down state, why the BFD packet f= rom remote > system with DOWN status transition the state machine from =93DOWN=94 to = =93INIT=94 > state? I thought it should be INIT state from remote node to trigger the > local node to go to INIT state. INIT is there for the 3 way handshake. The idea of INIT is, I have heard from you, but dont know if you have heard from me yet. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.16: Why set SessionState to Down= when Enabling a > session? Should it be =93INIT=94? Refer above. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In the Introduction and overview sections, t= he word =93adjacent > systems/forwarding engines=94 is used frequently. For example, the first > sentence of the Introduction stated: the rapid detection of communication > failures between adjacent systems. > > However, the sections in the latter part of the specification use =93two > systems=94, or =93pair of systems=94. > > > > My question: are they referring to the same thing? Does the =93adjacent= =94 in > the overview sections mean neighboring node as in OSPF=92s neighbors or t= wo > systems on two ends of the path for BFD session? It could be made consistent. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 2 Design, the first paragraph: > > What does it mean by saying "failure in communication with a forwarding > plane next hop"? Why next hop? The rest of the specification uses =93two > systems=94, =93remote system=94, etc, which I think is more accurate. This could be clarified. > > In addition, all forwarding engines are unidirectional. =A0Who impose the > bi-directional property on forwarding engines? Can you clarify the question? > > Do you mean BFD is to detect failures between two forwarding engines whic= h > face (or peer with) each other for some applications? Same as above? > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 End of the first paragraph of Section 2, it = stated that BFD > implemented in Control Plane may preclude the detection of some kinds of > failure. What kind of failures will be precluded? This can be clarified for sure. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3.1, last sentence of the first para= graph: you stated > that BFD can run between two OSPF neighbors. Why you need to run BFD betw= een > two OSPF neighbors? If the two immediate neighbors need to discover > connectivity to each other faster, HELLO timer can be set shorter. This is something that goes back to the introduction. The idea is: 1. Lesser load. 2. Single faster detection mechanism for multiple protocols. > I have some editorial comments marked on the enclosed PDF file. Please ha= ve > a look. > > Best Regards, Linda Dunbar Thanks a lot for the really thorough review. Vishwas From ldunbar@huawei.com Wed Oct 7 13:55: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 B065E3A68D3 for ; Wed, 7 Oct 2009 13:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.593, 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 E-ieWexbiXBy for ; Wed, 7 Oct 2009 13:55:39 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6E8BD28C0F0 for ; Wed, 7 Oct 2009 13:55:39 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR500GXFWVIWA@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 07 Oct 2009 13:57:19 -0700 (PDT) Received: from L735042 ([10.124.12.51]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR500GHFWVH6H@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 07 Oct 2009 13:57:18 -0700 (PDT) Date: Wed, 07 Oct 2009 15:57:17 -0500 From: Linda Dunbar Subject: RE: More questions on "draft-ietf-bfd-base-09.txt" In-reply-to: <77ead0ec0910071022s64f0a0a6rd4e522a031a44970@mail.gmail.com> To: 'Vishwas Manral' Message-id: <006701ca4790$c1851eb0$330c7c0a@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_KHrH056WBazksiP359caIQ)" Thread-index: AcpHcuseFhrr0fHOTImCLHwKAOXTywAHNSvg References: <001e01ca475e$b5fc4ff0$330c7c0a@china.huawei.com> <77ead0ec0910071022s64f0a0a6rd4e522a031a44970@mail.gmail.com> Cc: rtg-bfd@ietf.org, 'Dave Katz' 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, 07 Oct 2009 20:55:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_KHrH056WBazksiP359caIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Vishwas, Thank you very much for the quick feedback. > - I don't see ECHO reply packet from remote system defined > anywhere in the document. I would think that it is necessary to have > an ECHO reply message which includes the original ECHO packet plus > some information from the remote system. Why? The format of the echo packet is outside the scope of the spec. This is because the echo packet is only processed and received only by the sender. It is forwarded from the peers forwarding plane. [Linda] Do you mean the format of the ECHO reply message is out of the scope? But you have to specify how remote system sends the received Echo back to the sender, right? Otherwise how does the sender know a received packet is really a reply message of an Echo message earlier? Linda -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, October 07, 2009 12:23 PM To: Linda Dunbar Cc: Dave Katz; rtg-bfd@ietf.org Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" Hi Linda, Good to see you have spent quite an effort preparing and doing such an indepth review. > Thank you very much for answering my questions last week. Now I do see > unique values of BFD, comparing to IEEE802.1ag. I was very actively involved > in IEEE802.1ag's development for a few years. BFD is simpler than > IEEE802.1ag and has some useful features, such as its Demand mode, which > IEEE802.1ag doesn't have. I think Demand Mode is very useful in reducing the > processing power imposed on systems. Here are some more questions. Hope you > can help me again. Great to know you were so instrumental in 802.1ag. Yes BFD is a good CC protocol. The base protocol however does not provide all the other functionality like Locking etc. There are additional drafts under consideration for each of the other functionalities extending BFD. > - Section 3 Protocol Overview, 2nd paragraph: "A path is only > declared to be operational when two way communication has been established > ." > My comment: Under the context of MPLS, "a path", i.e. LSP, is always > uni-directional. So it is not correct to declare a path being operational > when two way communication is established. For the BFD case if we only have unidirectional LSP's there has to be an off path mechanism to transfer packets in the other direction, otherwise BFD will not be able to operate over such a scenario. > My suggestion: Should have an entity which binds two uni-directional paths > in the BFD context, or paired paths. Then you can easily say a path in the > pair (or in the entity) is declared operational when two way communication > is established. Even though the specification doesn't have to specify how > two paths are associated, it is worthwhile to have an entity to bind two > uni-directional paths together in the BFD document. The "My (Your) > Discriminator" in the BFD control packet should have "Entity identifier" > embedded in. To see how BFD works with MPLS LSP or over Pseudowire you can look at http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07 http://tools.ietf.org/html/draft-ietf-bfd-mpls-07 > - I don't see ECHO reply packet from remote system defined anywhere > in the document. I would think that it is necessary to have an ECHO reply > message which includes the original ECHO packet plus some information from > the remote system. Why? The format of the echo packet is outside the scope of the spec. This is because the echo packet is only processed and received only by the sender. It is forwarded from the peers forwarding plane. > - Section 6.8.5: Is the "Detecting Failures with Echo Function" > referring to the system who initiates "Echo"? That is correct. > The system which loops back Echo shouldn't have any failure related to Echo, > should it? It would not know. > - The BFD Control Packet has "Required Min RX Interval" and > "Required Min Echo RX Interval". When "Required Min RX Interval" is set to > zero, can remote system still send Echo frame? If yes, then the description > for Required Min RX Interval should be more accurate. Yes. For echo's the "Required Min Echo RX Interval" is used instead. > - Questions on State Machine of BFD: > > o The second last paragraph of Section 6.2 indicates "Once a session > has been declared down, it cannot come back until remote end first signals > that it is down". What if the local system goes down by provisioning, and > decides to turn up. Why have to wait for the remote end to go down first? The question is not clear. > o Why "Admin Down" is not on the state machine? It could have been added to the diagram. though there is only one transition out of it is the ADMIN UP state and to the down state. > o When local system is Down state, why the BFD packet from remote > system with DOWN status transition the state machine from "DOWN" to "INIT" > state? I thought it should be INIT state from remote node to trigger the > local node to go to INIT state. INIT is there for the 3 way handshake. The idea of INIT is, I have heard from you, but dont know if you have heard from me yet. > > - Section 6.8.16: Why set SessionState to Down when Enabling a > session? Should it be "INIT"? Refer above. > - In the Introduction and overview sections, the word "adjacent > systems/forwarding engines" is used frequently. For example, the first > sentence of the Introduction stated: the rapid detection of communication > failures between adjacent systems. > > However, the sections in the latter part of the specification use "two > systems", or "pair of systems". > > > > My question: are they referring to the same thing? Does the "adjacent" in > the overview sections mean neighboring node as in OSPF's neighbors or two > systems on two ends of the path for BFD session? It could be made consistent. > - Section 2 Design, the first paragraph: > > What does it mean by saying "failure in communication with a forwarding > plane next hop"? Why next hop? The rest of the specification uses "two > systems", "remote system", etc, which I think is more accurate. This could be clarified. > > In addition, all forwarding engines are unidirectional. Who impose the > bi-directional property on forwarding engines? Can you clarify the question? > > Do you mean BFD is to detect failures between two forwarding engines which > face (or peer with) each other for some applications? Same as above? > > - End of the first paragraph of Section 2, it stated that BFD > implemented in Control Plane may preclude the detection of some kinds of > failure. What kind of failures will be precluded? This can be clarified for sure. > > - Section 3.1, last sentence of the first paragraph: you stated > that BFD can run between two OSPF neighbors. Why you need to run BFD between > two OSPF neighbors? If the two immediate neighbors need to discover > connectivity to each other faster, HELLO timer can be set shorter. This is something that goes back to the introduction. The idea is: 1. Lesser load. 2. Single faster detection mechanism for multiple protocols. > I have some editorial comments marked on the enclosed PDF file. Please have > a look. > > Best Regards, Linda Dunbar Thanks a lot for the really thorough review. Vishwas --Boundary_(ID_KHrH056WBazksiP359caIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT RE: More questions on "draft-ietf-bfd-base-09.txt"

Vishwas,

Thank you very much for the quick feedback.

      > -          I don’t see ECHO reply packet from remote system defined

      > anywhere in the document. I would think that it is necessary to have

      > an ECHO reply message which includes the original ECHO packet plus

      > some information from the remote system. Why?

      The format of the echo packet is outside the scope of the spec. This is because the echo packet is only processed and received only by the sender. It is forwarded from the peers forwarding plane.

[Linda] Do you mean the format of the ECHO reply message is out of the scope? But you have to specify how remote system sends the received Echo back to the sender, right? Otherwise how does the sender know a received packet is really a reply message of an Echo message earlier?

 

Linda

-----Original Message-----
From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, October 07, 2009 12:23 PM
To: Linda Dunbar
Cc: Dave Katz; rtg-bfd@ietf.org
Subject: Re: More questions on "draft-ietf-bfd-base-09.txt"

Hi Linda,

Good to see you have spent quite an effort preparing and doing such an

indepth review.

> Thank you very much for answering my questions last week. Now I do see

> unique values of BFD, comparing to IEEE802.1ag. I was very actively involved

> in IEEE802.1ag’s development for a few years. BFD is simpler than

> IEEE802.1ag and has some useful features, such as its Demand mode, which

> IEEE802.1ag doesn’t have. I think Demand Mode is very useful in reducing the

> processing power imposed on systems. Here are some more questions. Hope you

> can help me again.

Great to know you were so instrumental in 802.1ag. Yes BFD is a good

CC protocol. The base protocol however does not provide all the other

functionality like Locking etc. There are additional drafts under

consideration for each of the other functionalities extending BFD.

> -          Section 3 Protocol Overview, 2nd paragraph: “A path is only

> declared to be operational when two way communication has been established

> …”

> My comment:  Under the context of MPLS, “a path”, i.e. LSP, is always

> uni-directional. So it is not correct to declare a path being operational

> when two way communication is established.

For the BFD case if we only have unidirectional LSP's there has to be

an off path mechanism to transfer packets in the other direction,

otherwise BFD will not be able to operate over such a scenario.

> My suggestion: Should have an entity which binds two uni-directional paths

> in the BFD context, or paired paths. Then you can easily say a path in the

> pair (or in the entity) is declared operational when two way communication

> is established. Even though the specification doesn’t have to specify how

> two paths are associated, it is worthwhile to have an entity to bind two

> uni-directional paths together in the BFD document. The “My (Your)

> Discriminator” in the BFD control packet should have “Entity identifier”

> embedded in.

To see how BFD works with MPLS LSP or over Pseudowire you can look at

http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07

http://tools.ietf.org/html/draft-ietf-bfd-mpls-07

> -          I don’t see ECHO reply packet from remote system defined anywhere

> in the document. I would think that it is necessary to have an ECHO reply

> message which includes the original ECHO packet plus some information from

> the remote system. Why?

The format of the echo packet is outside the scope of the spec. This

is because the echo packet is only processed and received only by the

sender. It is forwarded from the peers forwarding plane.

> -          Section 6.8.5: Is the “Detecting Failures with Echo Function”

> referring to the system who initiates “Echo”?

That is correct.


> The system which loops back Echo shouldn’t have any failure related to Echo,

> should it?

It would not know.

> -          The BFD Control Packet has “Required Min RX Interval” and

> “Required Min Echo RX Interval”. When “Required Min RX Interval” is set to

> zero, can remote system still send Echo frame? If yes, then the description

> for Required Min RX Interval should be more accurate.

Yes. For echo's the "Required Min Echo RX Interval" is used instead.

> -          Questions on State Machine of BFD:

>

> o       The second last paragraph of Section 6.2 indicates “Once a session

> has been declared down, it cannot come back until remote end first signals

> that it is down”. What if the local system goes down by provisioning, and

> decides to turn up. Why have to wait for the remote end to go down first?

The question is not clear.

> o       Why “Admin Down” is not on the state machine?

It could have been added to the diagram. though there is only one

transition out of it is the ADMIN UP state and to the down state.

> o       When local system is Down state, why the BFD packet from remote

> system with DOWN status transition the state machine from “DOWN” to “INIT”

> state? I thought it should be INIT state from remote node to trigger the

> local node to go to INIT state.

INIT is there for the 3 way handshake. The idea of INIT is, I have

heard from you, but dont know if you have heard from me yet.

>

> -          Section 6.8.16: Why set SessionState to Down when Enabling a

> session? Should it be “INIT”?

Refer above.

> -          In the Introduction and overview sections, the word “adjacent

> systems/forwarding engines” is used frequently. For example, the first

> sentence of the Introduction stated: the rapid detection of communication

> failures between adjacent systems.

>

> However, the sections in the latter part of the specification use “two

> systems”, or “pair of systems”.

>

>

>

> My question: are they referring to the same thing? Does the “adjacent” in

> the overview sections mean neighboring node as in OSPF’s neighbors or two

> systems on two ends of the path for BFD session?

It could be made consistent.

> -          Section 2 Design, the first paragraph:

>

> What does it mean by saying "failure in communication with a forwarding

> plane next hop"? Why next hop? The rest of the specification uses “two

> systems”, “remote system”, etc, which I think is more accurate.

This could be clarified.

>

> In addition, all forwarding engines are unidirectional.  Who impose the

> bi-directional property on forwarding engines?

Can you clarify the question?

>

> Do you mean BFD is to detect failures between two forwarding engines which

> face (or peer with) each other for some applications?

Same as above?


>

> -          End of the first paragraph of Section 2, it stated that BFD

> implemented in Control Plane may preclude the detection of some kinds of

> failure. What kind of failures will be precluded?

This can be clarified for sure.

>

> -          Section 3.1, last sentence of the first paragraph: you stated

> that BFD can run between two OSPF neighbors. Why you need to run BFD between

> two OSPF neighbors? If the two immediate neighbors need to discover

> connectivity to each other faster, HELLO timer can be set shorter.

This is something that goes back to the introduction. The idea is:

1. Lesser load.

2. Single faster detection mechanism for multiple protocols.

> I have some editorial comments marked on the enclosed PDF file. Please have

> a look.

>

> Best Regards, Linda Dunbar

Thanks a lot for the really thorough review.

Vishwas

--Boundary_(ID_KHrH056WBazksiP359caIQ)-- From vishwas.ietf@gmail.com Wed Oct 7 14:03: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 2F41628C121 for ; Wed, 7 Oct 2009 14:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 sIebTaITt97a for ; Wed, 7 Oct 2009 14:03:29 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id A28033A6914 for ; Wed, 7 Oct 2009 14:03:29 -0700 (PDT) Received: by yxe4 with SMTP id 4so5197658yxe.32 for ; Wed, 07 Oct 2009 14:05:05 -0700 (PDT) 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=/CWyKJuapJLIxpzwU5S4EcDAk1qhc1phzfh2FauE8NU=; b=iyDEIXx/iEhsh7uROnj7EOe28ZDNqx3RiSxcOQ1R2ziLVs/qH1sqBFE5PalX+SURrz UrW3y0WWVxpVjqPPr2qXvs/EVpHyIjzdcW810FEHYUqXKg2u2wL5boCfAa5DSUVxc/ug iPiHeXzt0AfwhjlXDqjvhTRWW6magk8fSmW1E= 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=gky1ofLOV+3uqEiJYVF5uMekZnzHrKJRESn13WqLhpQ6Qmn1jj8DQXwrSqEQKhhok0 GrLhEz8aLjKnCiz9RoYlZnHujvIhHTdlW6vRnQPCkGsmWgvzsRzhUXjIp5g2x/DeLt3o SO27ohbrYtHvZ+GOWjdBWJMaYVEm6X4wcUpiY= MIME-Version: 1.0 Received: by 10.150.45.34 with SMTP id s34mr806046ybs.274.1254949505631; Wed, 07 Oct 2009 14:05:05 -0700 (PDT) In-Reply-To: <006701ca4790$c1851eb0$330c7c0a@china.huawei.com> References: <001e01ca475e$b5fc4ff0$330c7c0a@china.huawei.com> <77ead0ec0910071022s64f0a0a6rd4e522a031a44970@mail.gmail.com> <006701ca4790$c1851eb0$330c7c0a@china.huawei.com> Date: Wed, 7 Oct 2009 14:05:05 -0700 Message-ID: <77ead0ec0910071405o54d01045x7eddd0139ef0099d@mail.gmail.com> Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, Dave Katz 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, 07 Oct 2009 21:03:31 -0000 Hi Linda, > > The format of the echo packet is outside the scope of the spec. This is > because the echo packet is only processed and received only by the sender= . > It is forwarded from the peers forwarding plane. > > [Linda] Do you mean the format of the ECHO reply message is out of the > scope? But you have to specify how remote system sends the received Echo > back to the sender, right? Otherwise how does the sender know a received > packet is really a reply message of an Echo message earlier? The packet format for the echo packet is itself not specified. The idea is that the echo packet itself is looped back by the forwarder (there is only forwarding processing the receiver will not know it received a BFD echo packet). Thanks, Vishwas > Linda > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, October 07, 2009 12:23 PM > To: Linda Dunbar > Cc: Dave Katz; rtg-bfd@ietf.org > Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" > > Hi Linda, > > Good to see you have spent quite an effort preparing and doing such an > > indepth review. > >> Thank you very much for answering my questions last week. Now I do see > >> unique values of BFD, comparing to IEEE802.1ag. I was very actively >> involved > >> in IEEE802.1ag=92s development for a few years. BFD is simpler than > >> IEEE802.1ag and has some useful features, such as its Demand mode, which > >> IEEE802.1ag doesn=92t have. I think Demand Mode is very useful in reduci= ng >> the > >> processing power imposed on systems. Here are some more questions. Hope >> you > >> can help me again. > > Great to know you were so instrumental in 802.1ag. Yes BFD is a good > > CC protocol. The base protocol however does not provide all the other > > functionality like Locking etc. There are additional drafts under > > consideration for each of the other functionalities extending BFD. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3 Protocol Overview, 2nd paragraph:= =93A path is only > >> declared to be operational when two way communication has been establish= ed > >> =85=94 > >> My comment: =A0Under the context of MPLS, =93a path=94, i.e. LSP, is alw= ays > >> uni-directional. So it is not correct to declare a path being operationa= l > >> when two way communication is established. > > For the BFD case if we only have unidirectional LSP's there has to be > > an off path mechanism to transfer packets in the other direction, > > otherwise BFD will not be able to operate over such a scenario. > >> My suggestion: Should have an entity which binds two uni-directional pat= hs > >> in the BFD context, or paired paths. Then you can easily say a path in t= he > >> pair (or in the entity) is declared operational when two way communicati= on > >> is established. Even though the specification doesn=92t have to specify = how > >> two paths are associated, it is worthwhile to have an entity to bind two > >> uni-directional paths together in the BFD document. The =93My (Your) > >> Discriminator=94 in the BFD control packet should have =93Entity identif= ier=94 > >> embedded in. > > To see how BFD works with MPLS LSP or over Pseudowire you can look at > > http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07 > > http://tools.ietf.org/html/draft-ietf-bfd-mpls-07 > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 I don=92t see ECHO reply packet from remote= system defined >> anywhere > >> in the document. I would think that it is necessary to have an ECHO repl= y > >> message which includes the original ECHO packet plus some information fr= om > >> the remote system. Why? > > The format of the echo packet is outside the scope of the spec. This > > is because the echo packet is only processed and received only by the > > sender. It is forwarded from the peers forwarding plane. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.5: Is the =93Detecting Failures= with Echo Function=94 > >> referring to the system who initiates =93Echo=94? > > That is correct. > >> The system which loops back Echo shouldn=92t have any failure related to >> Echo, > >> should it? > > It would not know. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The BFD Control Packet has =93Required Min = RX Interval=94 and > >> =93Required Min Echo RX Interval=94. When =93Required Min RX Interval=94= is set to > >> zero, can remote system still send Echo frame? If yes, then the >> description > >> for Required Min RX Interval should be more accurate. > > Yes. For echo's the "Required Min Echo RX Interval" is used instead. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Questions on State Machine of BFD: > >> > >> o=A0=A0=A0=A0=A0=A0 The second last paragraph of Section 6.2 indicates = =93Once a session > >> has been declared down, it cannot come back until remote end first signa= ls > >> that it is down=94. What if the local system goes down by provisioning, = and > >> decides to turn up. Why have to wait for the remote end to go down first= ? > > The question is not clear. > >> o=A0=A0=A0=A0=A0=A0 Why =93Admin Down=94 is not on the state machine? > > It could have been added to the diagram. though there is only one > > transition out of it is the ADMIN UP state and to the down state. > >> o=A0=A0=A0=A0=A0=A0 When local system is Down state, why the BFD packet = from remote > >> system with DOWN status transition the state machine from =93DOWN=94 to = =93INIT=94 > >> state? I thought it should be INIT state from remote node to trigger the > >> local node to go to INIT state. > > INIT is there for the 3 way handshake. The idea of INIT is, I have > > heard from you, but dont know if you have heard from me yet. > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.16: Why set SessionState to Dow= n when Enabling a > >> session? Should it be =93INIT=94? > > Refer above. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In the Introduction and overview sections, = the word =93adjacent > >> systems/forwarding engines=94 is used frequently. For example, the first > >> sentence of the Introduction stated: the rapid detection of communicatio= n > >> failures between adjacent systems. > >> > >> However, the sections in the latter part of the specification use =93two > >> systems=94, or =93pair of systems=94. > >> > >> > >> > >> My question: are they referring to the same thing? Does the =93adjacent= =94 in > >> the overview sections mean neighboring node as in OSPF=92s neighbors or = two > >> systems on two ends of the path for BFD session? > > It could be made consistent. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 2 Design, the first paragraph: > >> > >> What does it mean by saying "failure in communication with a forwarding > >> plane next hop"? Why next hop? The rest of the specification uses =93two > >> systems=94, =93remote system=94, etc, which I think is more accurate. > > This could be clarified. > >> > >> In addition, all forwarding engines are unidirectional. =A0Who impose th= e > >> bi-directional property on forwarding engines? > > Can you clarify the question? > >> > >> Do you mean BFD is to detect failures between two forwarding engines whi= ch > >> face (or peer with) each other for some applications? > > Same as above? > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 End of the first paragraph of Section 2, it= stated that BFD > >> implemented in Control Plane may preclude the detection of some kinds of > >> failure. What kind of failures will be precluded? > > This can be clarified for sure. > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3.1, last sentence of the first par= agraph: you stated > >> that BFD can run between two OSPF neighbors. Why you need to run BFD >> between > >> two OSPF neighbors? If the two immediate neighbors need to discover > >> connectivity to each other faster, HELLO timer can be set shorter. > > This is something that goes back to the introduction. The idea is: > > 1. Lesser load. > > 2. Single faster detection mechanism for multiple protocols. > >> I have some editorial comments marked on the enclosed PDF file. Please >> have > >> a look. > >> > >> Best Regards, Linda Dunbar > > Thanks a lot for the really thorough review. > > Vishwas From davari@broadcom.com Wed Oct 7 14:55: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 E76F93A6887 for ; Wed, 7 Oct 2009 14:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 Af90mpb6686t for ; Wed, 7 Oct 2009 14:55:51 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id B48F43A69FD for ; Wed, 7 Oct 2009 14:55:51 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 07 Oct 2009 14:54:57 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 7 Oct 2009 14:54:58 -0700 From: "Shahram Davari" To: "Vishwas Manral" , "Linda Dunbar" Date: Wed, 7 Oct 2009 14:54:57 -0700 Subject: RE: More questions on "draft-ietf-bfd-base-09.txt" Thread-Topic: More questions on "draft-ietf-bfd-base-09.txt" Thread-Index: AcpHkfAeWkfo3IsOS5ijDS+1MdnopgABsGFw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681575CD88F@SJEXCHCCR02.corp.ad.broadcom.com> References: <001e01ca475e$b5fc4ff0$330c7c0a@china.huawei.com> <77ead0ec0910071022s64f0a0a6rd4e522a031a44970@mail.gmail.com> <006701ca4790$c1851eb0$330c7c0a@china.huawei.com> <77ead0ec0910071405o54d01045x7eddd0139ef0099d@mail.gmail.com> In-Reply-To: <77ead0ec0910071405o54d01045x7eddd0139ef0099d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66D3D1BB0UC7250932-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , Dave Katz 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, 07 Oct 2009 21:55:53 -0000 Linda, LSP-ping, ICMP-ping, etc. are examples of Echo packets. Regards, Shahram=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Vishwas Manral Sent: Wednesday, October 07, 2009 2:05 PM To: Linda Dunbar Cc: rtg-bfd@ietf.org; Dave Katz Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" Hi Linda, > > The format of the echo packet is outside the scope of the spec. This is > because the echo packet is only processed and received only by the sender= . > It is forwarded from the peers forwarding plane. > > [Linda] Do you mean the format of the ECHO reply message is out of the > scope? But you have to specify how remote system sends the received Echo > back to the sender, right? Otherwise how does the sender know a received > packet is really a reply message of an Echo message earlier? The packet format for the echo packet is itself not specified. The idea is that the echo packet itself is looped back by the forwarder (there is only forwarding processing the receiver will not know it received a BFD echo packet). Thanks, Vishwas > Linda > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, October 07, 2009 12:23 PM > To: Linda Dunbar > Cc: Dave Katz; rtg-bfd@ietf.org > Subject: Re: More questions on "draft-ietf-bfd-base-09.txt" > > Hi Linda, > > Good to see you have spent quite an effort preparing and doing such an > > indepth review. > >> Thank you very much for answering my questions last week. Now I do see > >> unique values of BFD, comparing to IEEE802.1ag. I was very actively >> involved > >> in IEEE802.1ag's development for a few years. BFD is simpler than > >> IEEE802.1ag and has some useful features, such as its Demand mode, which > >> IEEE802.1ag doesn't have. I think Demand Mode is very useful in reducing >> the > >> processing power imposed on systems. Here are some more questions. Hope >> you > >> can help me again. > > Great to know you were so instrumental in 802.1ag. Yes BFD is a good > > CC protocol. The base protocol however does not provide all the other > > functionality like Locking etc. There are additional drafts under > > consideration for each of the other functionalities extending BFD. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3 Protocol Overview, 2nd paragraph:= "A path is only > >> declared to be operational when two way communication has been establish= ed > >> ." > >> My comment: =A0Under the context of MPLS, "a path", i.e. LSP, is always > >> uni-directional. So it is not correct to declare a path being operationa= l > >> when two way communication is established. > > For the BFD case if we only have unidirectional LSP's there has to be > > an off path mechanism to transfer packets in the other direction, > > otherwise BFD will not be able to operate over such a scenario. > >> My suggestion: Should have an entity which binds two uni-directional pat= hs > >> in the BFD context, or paired paths. Then you can easily say a path in t= he > >> pair (or in the entity) is declared operational when two way communicati= on > >> is established. Even though the specification doesn't have to specify ho= w > >> two paths are associated, it is worthwhile to have an entity to bind two > >> uni-directional paths together in the BFD document. The "My (Your) > >> Discriminator" in the BFD control packet should have "Entity identifier" > >> embedded in. > > To see how BFD works with MPLS LSP or over Pseudowire you can look at > > http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07 > > http://tools.ietf.org/html/draft-ietf-bfd-mpls-07 > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 I don't see ECHO reply packet from remote s= ystem defined >> anywhere > >> in the document. I would think that it is necessary to have an ECHO repl= y > >> message which includes the original ECHO packet plus some information fr= om > >> the remote system. Why? > > The format of the echo packet is outside the scope of the spec. This > > is because the echo packet is only processed and received only by the > > sender. It is forwarded from the peers forwarding plane. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.5: Is the "Detecting Failures w= ith Echo Function" > >> referring to the system who initiates "Echo"? > > That is correct. > >> The system which loops back Echo shouldn't have any failure related to >> Echo, > >> should it? > > It would not know. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The BFD Control Packet has "Required Min RX= Interval" and > >> "Required Min Echo RX Interval". When "Required Min RX Interval" is set = to > >> zero, can remote system still send Echo frame? If yes, then the >> description > >> for Required Min RX Interval should be more accurate. > > Yes. For echo's the "Required Min Echo RX Interval" is used instead. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Questions on State Machine of BFD: > >> > >> o=A0=A0=A0=A0=A0=A0 The second last paragraph of Section 6.2 indicates "= Once a session > >> has been declared down, it cannot come back until remote end first signa= ls > >> that it is down". What if the local system goes down by provisioning, an= d > >> decides to turn up. Why have to wait for the remote end to go down first= ? > > The question is not clear. > >> o=A0=A0=A0=A0=A0=A0 Why "Admin Down" is not on the state machine? > > It could have been added to the diagram. though there is only one > > transition out of it is the ADMIN UP state and to the down state. > >> o=A0=A0=A0=A0=A0=A0 When local system is Down state, why the BFD packet = from remote > >> system with DOWN status transition the state machine from "DOWN" to "INI= T" > >> state? I thought it should be INIT state from remote node to trigger the > >> local node to go to INIT state. > > INIT is there for the 3 way handshake. The idea of INIT is, I have > > heard from you, but dont know if you have heard from me yet. > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 6.8.16: Why set SessionState to Dow= n when Enabling a > >> session? Should it be "INIT"? > > Refer above. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In the Introduction and overview sections, = the word "adjacent > >> systems/forwarding engines" is used frequently. For example, the first > >> sentence of the Introduction stated: the rapid detection of communicatio= n > >> failures between adjacent systems. > >> > >> However, the sections in the latter part of the specification use "two > >> systems", or "pair of systems". > >> > >> > >> > >> My question: are they referring to the same thing? Does the "adjacent" i= n > >> the overview sections mean neighboring node as in OSPF's neighbors or tw= o > >> systems on two ends of the path for BFD session? > > It could be made consistent. > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 2 Design, the first paragraph: > >> > >> What does it mean by saying "failure in communication with a forwarding > >> plane next hop"? Why next hop? The rest of the specification uses "two > >> systems", "remote system", etc, which I think is more accurate. > > This could be clarified. > >> > >> In addition, all forwarding engines are unidirectional. =A0Who impose th= e > >> bi-directional property on forwarding engines? > > Can you clarify the question? > >> > >> Do you mean BFD is to detect failures between two forwarding engines whi= ch > >> face (or peer with) each other for some applications? > > Same as above? > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 End of the first paragraph of Section 2, it= stated that BFD > >> implemented in Control Plane may preclude the detection of some kinds of > >> failure. What kind of failures will be precluded? > > This can be clarified for sure. > >> > >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 3.1, last sentence of the first par= agraph: you stated > >> that BFD can run between two OSPF neighbors. Why you need to run BFD >> between > >> two OSPF neighbors? If the two immediate neighbors need to discover > >> connectivity to each other faster, HELLO timer can be set shorter. > > This is something that goes back to the introduction. The idea is: > > 1. Lesser load. > > 2. Single faster detection mechanism for multiple protocols. > >> I have some editorial comments marked on the enclosed PDF file. Please >> have > >> a look. > >> > >> Best Regards, Linda Dunbar > > Thanks a lot for the really thorough review. > > Vishwas From root@core3.amsl.com Fri Oct 16 09:15:01 2009 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D3E728C132; Fri, 16 Oct 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-v4v6-1hop-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016161501.5D3E728C132@core3.amsl.com> Date: Fri, 16 Oct 2009 09:15:01 -0700 (PDT) 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, 16 Oct 2009 16:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-10.txt Pages : 7 Date : 2009-10-16 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16091446.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 16 09:30:01 2009 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 696D03A68C1; Fri, 16 Oct 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-multihop-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016163001.696D03A68C1@core3.amsl.com> Date: Fri, 16 Oct 2009 09:30:01 -0700 (PDT) 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, 16 Oct 2009 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-08.txt Pages : 7 Date : 2009-10-16 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16092736.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Oct 19 16:15:10 2009 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5979928C16A; Mon, 19 Oct 2009 16:15:09 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'BFD for IPv4 and IPv6 (Single Hop)' to Proposed Standard Message-Id: <20091019231510.5979928C16A@core3.amsl.com> Date: Mon, 19 Oct 2009 16:15:09 -0700 (PDT) Cc: bfd mailing list , Internet Architecture Board , bfd chair , RFC Editor 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, 19 Oct 2009 23:15:10 -0000 The IESG has approved the following document: - 'BFD for IPv4 and IPv6 (Single Hop) ' as a Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-10.txt Technical Summary 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 document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Working Group Summary WG progress has been reported as being quite smooth. Document Quality The protocol is widely implemented and deployed and has become part of common deployments on the internet. The drafts reflect the lessons learned from the deployed and operation. Multiple vendors have implemented and deployed BFD in operational networks. The document has been updated based on Gen-Art and IETF Last Call comments, and based on IESG review. Personnel Dave Ward is the document shepherd. Ross Callon is the responsible Area Director. From mach@huawei.com Mon Oct 26 18:44:57 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 0DE963A6824; Mon, 26 Oct 2009 18:44:57 -0700 (PDT) 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, 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 Ps5NZqp+bICv; Mon, 26 Oct 2009 18:44:56 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 186423A6894; Mon, 26 Oct 2009 18:44:52 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS500E3TGV4X2@szxga01-in.huawei.com>; Tue, 27 Oct 2009 09:45:04 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS5008D6GV3QG@szxga01-in.huawei.com>; Tue, 27 Oct 2009 09:45:04 +0800 (CST) Date: Tue, 27 Oct 2009 09:45:04 +0800 From: Mach Chen Subject: New draft notification: draft-chen-mpls-bfd-enhancement-00 To: mpls@ietf.org, mpls-tp@ietf.org, rtg-bfd@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal 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, 27 Oct 2009 01:44:57 -0000 Hi all, We just sumbitted a new draft that defines some enhancments to "BFD for MPLS". This is the link: http://tools.ietf.org/id/draft-chen-mpls-bfd-enhancement-00.txt The enhancement defined in this draft can be used to specify the return path of BFD control packets for a specific BFD session. Specifying the return path increases the robustness of BFD failure detection and reduces false positives. This draft also defines a way to avoid duplicate BFD sessions currently encountered with co-routed bidirectional LSPs and associated bidirectional LSP. The enhancement halves the number of BFD sessions over those LSPs, and allows a co-routed bidirectional LSP, an associated bidirectional LSP or even a pair of unidirectional LSPs to be protected and switched as a single entity. Any comments and suggestions are welcomed! Best regards, Mach From vishwas.ietf@gmail.com Wed Oct 28 10:57:55 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 DFD2E3A6A39 for ; Wed, 28 Oct 2009 10:57:55 -0700 (PDT) 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 NHH19oudCbG9 for ; Wed, 28 Oct 2009 10:57:55 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 23F143A6A40 for ; Wed, 28 Oct 2009 10:57:55 -0700 (PDT) Received: by gxk28 with SMTP id 28so940756gxk.9 for ; Wed, 28 Oct 2009 10:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=Ok7hUl8gWnPvChIAVUKRiFUvueMpx9CepNI6BdcmHwQ=; b=rx8c+xqVkT1PULyWhf0+ZeEzgXA7HnNXxa22ZlcUNzqRnsoqFwlo4JDg5Od0B018Nu S7D7xsykpLf34nSJpL829GIcAg5JQgj6gSbUWflcmjVNd6ArQzzsEmW6L1aZ9xmWMt12 R4+yKokFDEJ8Baj+G/qVPi3JRmEUFOYph3nAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bV0Tu0GLGd9iO+bHBNJgdgmhvGUluehriEKnSQI1figDhE5PFSCztgJEszxeydai/u XoA6j4fHVBrjhpQfLqDvJgqP208WhL1H/ldkpCxUlra9aivh7k/h/cilhAdOfa+QX1JN UlYdhO+0tibv+3v5+W9wJ0EpKS76qdjLTFWHk= MIME-Version: 1.0 Received: by 10.150.90.17 with SMTP id n17mr2543390ybb.71.1256752685656; Wed, 28 Oct 2009 10:58:05 -0700 (PDT) Date: Wed, 28 Oct 2009 10:58:05 -0700 Message-ID: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> Subject: BFD LSP Ping From: Vishwas Manral To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Kireeti Kompella , rahul@juniper.net X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:57:56 -0000 Hi, I noticed a basic issue with BFD LSP ping with a a TTL processing in a Uniform Model LSP. The draft states that: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. A single hop session verifies the TTL is 255. However the TTL in the IP header is changed at the Egress before the IP header handling because we are using hte uniform model. I think the easiest and the best way for this would be to use Multihop sessions in both directions. Do let me know if I am missing something? Thanks, Vishwas From nitinb@juniper.net Wed Oct 28 11:13:29 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 55C6B3A69E3 for ; Wed, 28 Oct 2009 11:13:29 -0700 (PDT) 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=[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 g7dBIaY6J896 for ; Wed, 28 Oct 2009 11:13:28 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5FDF73A6921 for ; Wed, 28 Oct 2009 11:13:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSuiJ1liNUt4T+cyGJ/2MwEmOvjciG3jN@postini.com; Wed, 28 Oct 2009 11:13:44 PDT 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; Wed, 28 Oct 2009 11:08:23 -0700 From: Nitin Bahadur To: 'Vishwas Manral' , "rtg-bfd@ietf.org" Date: Wed, 28 Oct 2009 11:08:22 -0700 Subject: RE: BFD LSP Ping Thread-Topic: BFD LSP Ping Thread-Index: AcpX+Dl6FaKFM95kQ2+6UPrUJI/QggAASrMw Message-ID: <05542EC42316164383B5180707A489EE1D033B511C@EMBX02-HQ.jnpr.net> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> In-Reply-To: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.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 Cc: Kireeti Kompella , Rahul Aggarwal 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, 28 Oct 2009 18:13:29 -0000 I'm not sure if the TTL check is mandatory/required for BFD MPLS. Thanks Nitin=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f > Of Vishwas Manral > Sent: Wednesday, October 28, 2009 10:58 AM > To: rtg-bfd@ietf.org > Cc: Kireeti Kompella; Rahul Aggarwal > Subject: BFD LSP Ping >=20 > Hi, >=20 > I noticed a basic issue with BFD LSP ping with a a TTL processing in a > Uniform Model LSP. >=20 > The draft states that: >=20 >=20 > The BFD control packet sent by the ingress LSR MUST be a UDP packet > with a well known destination port 3784 [BFD-IP] and a source port > assigned by the sender as per the procedures in [BFD-IP]. >=20 > A single hop session verifies the TTL is 255. However the TTL in the > IP header is changed at the Egress before the IP header handling > because we are using hte uniform model. I think the easiest and the > best way for this would be to use Multihop sessions in both > directions. >=20 > Do let me know if I am missing something? >=20 > Thanks, > Vishwas From vishwas.ietf@gmail.com Wed Oct 28 11:22: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 EF3AE28C187 for ; Wed, 28 Oct 2009 11:22:31 -0700 (PDT) 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 21+YMkbFg3lv for ; Wed, 28 Oct 2009 11:22:31 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 186E328C11C for ; Wed, 28 Oct 2009 11:22:31 -0700 (PDT) Received: by yxe30 with SMTP id 30so1046280yxe.29 for ; Wed, 28 Oct 2009 11:22:43 -0700 (PDT) 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=z/xhJoYzdQDrFWqSuG/1Sh83WuM3m2iGlvOxQNuD2YM=; b=UKRw6zINQv1py/3RoMay4qrP7wkB4rF1jKPT7y+rhJjwJRnuHQz3tP+JmTVKmPTlO8 wpkUjy07Rl5f9Acy+84mAjYOiMPxL0ajhYYdqmaszut/dPZakNNzaWjT8D9v/OAhuS46 xBit4J62S/inoeEAYwPKe4oXbxV7rc9cspCNI= 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=HDG+ZIHN3+UYFqAtfWl9Y8LIpLAnaent5NEFJPccHWIohch8BJYuLf2+sjdK7PSPcn nHFnxzaOyFKv0LCNsbppMmnscmGO2KL7k3/95UryMCbkHRd4xXskmSOsnNKjVVVcUEB0 7RbYYHgIlY04Vfze5Sv59ktJial1+TExsJjmg= MIME-Version: 1.0 Received: by 10.150.254.3 with SMTP id b3mr29644590ybi.161.1256754163831; Wed, 28 Oct 2009 11:22:43 -0700 (PDT) In-Reply-To: <05542EC42316164383B5180707A489EE1D033B511C@EMBX02-HQ.jnpr.net> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <05542EC42316164383B5180707A489EE1D033B511C@EMBX02-HQ.jnpr.net> Date: Wed, 28 Oct 2009 11:22:43 -0700 Message-ID: <77ead0ec0910281122w27074ad5je40e1e52c5916e9b@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Nitin Bahadur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , Rahul Aggarwal 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, 28 Oct 2009 18:22:32 -0000 Hi Nitin, BFD MPLS LSP is not changing anything in BFD other than what is specified like - no echo and demand mode. So I am assuming the TTL check is still the same for a single hop session, and we can do the auth algorithm for the same. I think we should for correctness and simplicity use Multihop sessions in both directions. Thanks, Vishwas On Wed, Oct 28, 2009 at 11:08 AM, Nitin Bahadur wrote: > > I'm not sure if the TTL check is mandatory/required for BFD MPLS. > > Thanks > Nitin > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beha= lf >> Of Vishwas Manral >> Sent: Wednesday, October 28, 2009 10:58 AM >> To: rtg-bfd@ietf.org >> Cc: Kireeti Kompella; Rahul Aggarwal >> Subject: BFD LSP Ping >> >> Hi, >> >> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >> Uniform Model LSP. >> >> The draft states that: >> >> >> =A0 =A0The BFD control packet sent by the ingress LSR MUST be a UDP pack= et >> =A0 =A0with a well known destination port 3784 [BFD-IP] and a source por= t >> =A0 =A0assigned by the sender as per the procedures in [BFD-IP]. >> >> A single hop session verifies the TTL is 255. However the TTL in the >> IP header is changed at the Egress before the IP header handling >> because we are using hte uniform model. I think the easiest and the >> best way for this would be to use Multihop sessions in both >> directions. >> >> Do let me know if I am missing something? >> >> Thanks, >> Vishwas > From vishwas.ietf@gmail.com Wed Oct 28 11:25:58 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 37FDE28C1B6 for ; Wed, 28 Oct 2009 11:25:58 -0700 (PDT) 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 nHT-q7bJIP-H for ; Wed, 28 Oct 2009 11:25:57 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 541E73A6A45 for ; Wed, 28 Oct 2009 11:25:57 -0700 (PDT) Received: by ywh13 with SMTP id 13so1039191ywh.29 for ; Wed, 28 Oct 2009 11:26:09 -0700 (PDT) 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=reaVpDNUL7R+CAk7JEWgdlNAMXbw+4HlekSKqWottDg=; b=C4GAiaXYdJ880twcPUIZoabSyfSjAxSi3X7t+WDH01fx8sJsUF0F9Yg7sjD6ZINY9L C6kikynVQTYZB2RZZ5uEUztS9UMuIAUFHeyF4NUqIpE6U7qlO2eFEdxlKm/n+rig8HYk xojvtjnWZo+Ay3Ao9S0qJGm88e3DRhFA8+IZE= 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=XV+3aKw/tT9m/GcbrQHXnLcrKu8x81ZC8I44Jkdr9MI3f9gegLD/ACA/ASqZ90glps WCimD2rEcWLIuRskQAFlu0k+rBwWAuLBlgcmlJeiRSqGkaxISml7xXQmEZxm8aNhw4l2 tgUY+OcfeCSNNGlwR4Ru+T7NnVc8xYna4y1OM= MIME-Version: 1.0 Received: by 10.150.27.1 with SMTP id a1mr16023297yba.125.1256754369850; Wed, 28 Oct 2009 11:26:09 -0700 (PDT) In-Reply-To: <77ead0ec0910281122w27074ad5je40e1e52c5916e9b@mail.gmail.com> References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com> <05542EC42316164383B5180707A489EE1D033B511C@EMBX02-HQ.jnpr.net> <77ead0ec0910281122w27074ad5je40e1e52c5916e9b@mail.gmail.com> Date: Wed, 28 Oct 2009 11:26:09 -0700 Message-ID: <77ead0ec0910281126w7047e751nd1ae75bf2a25b389@mail.gmail.com> Subject: Re: BFD LSP Ping From: Vishwas Manral To: Nitin Bahadur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kireeti Kompella , "rtg-bfd@ietf.org" , Rahul Aggarwal 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, 28 Oct 2009 18:25:58 -0000 Hi Nitin, Also thinking of it if we do not care about the TTL we can use Multihop in such a case. Thats the only big difference between the functionality provided my a Multihop versus a single hop session. Thanks, Vishwas On Wed, Oct 28, 2009 at 11:22 AM, Vishwas Manral w= rote: > Hi Nitin, > > BFD MPLS LSP is not changing anything in BFD other than what is > specified like - no echo and demand mode. > > So I am assuming the TTL check is still the same for a single hop > session, and we can do the auth algorithm for the same. > > I think we should for correctness and simplicity use Multihop sessions > in both directions. > > Thanks, > Vishwas > > On Wed, Oct 28, 2009 at 11:08 AM, Nitin Bahadur wrot= e: >> >> I'm not sure if the TTL check is mandatory/required for BFD MPLS. >> >> Thanks >> Nitin >> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Beh= alf >>> Of Vishwas Manral >>> Sent: Wednesday, October 28, 2009 10:58 AM >>> To: rtg-bfd@ietf.org >>> Cc: Kireeti Kompella; Rahul Aggarwal >>> Subject: BFD LSP Ping >>> >>> Hi, >>> >>> I noticed a basic issue with BFD LSP ping with a a TTL processing in a >>> Uniform Model LSP. >>> >>> The draft states that: >>> >>> >>> =A0 =A0The BFD control packet sent by the ingress LSR MUST be a UDP pac= ket >>> =A0 =A0with a well known destination port 3784 [BFD-IP] and a source po= rt >>> =A0 =A0assigned by the sender as per the procedures in [BFD-IP]. >>> >>> A single hop session verifies the TTL is 255. However the TTL in the >>> IP header is changed at the Egress before the IP header handling >>> because we are using hte uniform model. I think the easiest and the >>> best way for this would be to use Multihop sessions in both >>> directions. >>> >>> Do let me know if I am missing something? >>> >>> Thanks, >>> Vishwas >> > From rrahman@cisco.com Wed Oct 28 16:08:55 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 DA4A73A6A6E for ; Wed, 28 Oct 2009 16:08:55 -0700 (PDT) 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=[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 GR2oH5R3WOnv for ; Wed, 28 Oct 2009 16:08:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C94D93A68E4 for ; Wed, 28 Oct 2009 16:08:54 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHNr6EqtJV2a/2dsb2JhbADDA5gjhD8E X-IronPort-AV: E=Sophos;i="4.44,642,1249257600"; d="scan'208";a="65388214" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 23:09:09 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id n9SN99mV003715; Wed, 28 Oct 2009 23:09:09 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); Wed, 28 Oct 2009 19:09:09 -0400 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 LSP Ping Date: Wed, 28 Oct 2009 19:09:02 -0400 Message-ID: In-Reply-To: <77ead0ec0910281126w7047e751nd1ae75bf2a25b389@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD LSP Ping Thread-Index: AcpX/Chp7EUtMiayRlq+HoxsMQVRZQAJ1NVA References: <77ead0ec0910281058i7f3171fcyb7b3223602ef0ec7@mail.gmail.com><05542EC42316164383B5180707A489EE1D033B511C@EMBX02-HQ.jnpr.net><77ead0ec0910281122w27074ad5je40e1e52c5916e9b@mail.gmail.com> <77ead0ec0910281126w7047e751nd1ae75bf2a25b389@mail.gmail.com> From: "Reshad Rahman (rrahman)" To: "Vishwas Manral" , "Nitin Bahadur" X-OriginalArrivalTime: 28 Oct 2009 23:09:09.0376 (UTC) FILETIME=[A7ADB800:01CA5823] Cc: Kireeti Kompella , rtg-bfd@ietf.org, Rahul Aggarwal 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, 28 Oct 2009 23:08:55 -0000 It's not clear to me either why the single-hop UDP port is used if TTL = check isn't needed. I agree that it seems to make more sense to use = multihop in both directions. Regards, Reshad. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Vishwas Manral Sent: Wednesday, October 28, 2009 2:26 PM To: Nitin Bahadur Cc: Kireeti Kompella; rtg-bfd@ietf.org; Rahul Aggarwal Subject: Re: BFD LSP Ping Hi Nitin, Also thinking of it if we do not care about the TTL we can use Multihop in such a case. Thats the only big difference between the functionality provided my a Multihop versus a single hop session. Thanks, Vishwas On Wed, Oct 28, 2009 at 11:22 AM, Vishwas Manral = wrote: > Hi Nitin, > > BFD MPLS LSP is not changing anything in BFD other than what is > specified like - no echo and demand mode. > > So I am assuming the TTL check is still the same for a single hop > session, and we can do the auth algorithm for the same. > > I think we should for correctness and simplicity use Multihop sessions > in both directions. > > Thanks, > Vishwas > > On Wed, Oct 28, 2009 at 11:08 AM, Nitin Bahadur = wrote: >> >> I'm not sure if the TTL check is mandatory/required for BFD MPLS. >> >> Thanks >> Nitin >> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf >>> Of Vishwas Manral >>> Sent: Wednesday, October 28, 2009 10:58 AM >>> To: rtg-bfd@ietf.org >>> Cc: Kireeti Kompella; Rahul Aggarwal >>> Subject: BFD LSP Ping >>> >>> Hi, >>> >>> I noticed a basic issue with BFD LSP ping with a a TTL processing in = a >>> Uniform Model LSP. >>> >>> The draft states that: >>> >>> >>> =A0 =A0The BFD control packet sent by the ingress LSR MUST be a UDP = packet >>> =A0 =A0with a well known destination port 3784 [BFD-IP] and a source = port >>> =A0 =A0assigned by the sender as per the procedures in [BFD-IP]. >>> >>> A single hop session verifies the TTL is 255. However the TTL in the >>> IP header is changed at the Egress before the IP header handling >>> because we are using hte uniform model. I think the easiest and the >>> best way for this would be to use Multihop sessions in both >>> directions. >>> >>> Do let me know if I am missing something? >>> >>> Thanks, >>> Vishwas >> >