I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-bfd-mpls-05.txt Reviewer: Brian Carpenter Review Date: 2008-05-30 IESG Telechat date: 2008-6-05 Summary: Almost ready, but LC comments still open Comments: These Last Call comments have not been addressed (see author's response appended below). I was expecting a -06 version. 6. Session Establishment A BFD session is boot-strapped using LSP-Ping. This specification describes procedures only for BFD asynchronous mode. Should you state explicitly that BFD Demand mode MUST NOT be used? 7. Encapsulation ... 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]. The source IP address is a routable address of the sender. The destination IP address is randomly chosen from the 127/8 range, This is written in IPv4 terms. What happens in an IPv6-only environment? There is no range of loopback addresses to borrow in IPv6, but you could use a ULA prefix. ID Nits finds a bunch of warnings: Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 117 has weird spacing: '... may be assoc...' == Line 334 has weird spacing: '...ence of the f...' Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 83, but not defined == Missing Reference: 'LSP-Ping' is mentioned on line 351, but not defined == Unused Reference: 'RFC' is defined on line 381, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bfd-base-06 == Outdated reference: A later version (-08) exists of draft-ietf-bfd-v4v6-1hop-05 == Outdated reference: A later version (-06) exists of draft-ietf-bfd-multihop-04 == Outdated reference: draft-ietf-pwe3-vccv has been published as RFC 5085 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-oam-msg-map-02 -------- Original Message -------- Subject: Re: Gen-ART LC review of draft-ietf-bfd-mpls-05.txt Date: Wed, 30 Apr 2008 16:35:43 -0700 (PDT) From: Rahul Aggarwal To: Brian E Carpenter CC: General Area Review Team , Ross Callon , draft-ietf-bfd-mpls@tools.ietf.org, bfd-chairs@tools.ietf.org References: <4818F441.8050002@gmail.com> Hi Brian, Thanks for the comments. Please see below prefixed by : 1. 6. Session Establishment A BFD session is boot-strapped using LSP-Ping. This specification describes procedures only for BFD asynchronous mode. Should you state explicitly that BFD Demand mode MUST NOT be used? I will spell out that BFD demand mode is out of scope. 7. Encapsulation ... 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]. The source IP address is a routable address of the sender. The destination IP address is randomly chosen from the 127/8 range, This is written in IPv4 terms. What happens in an IPv6-only environment? There is no range of loopback addresses to borrow in IPv6, but you could use a ULA prefix. The procedures of RFC 4379 need to be used which is basically a destination IPv6 address from the range 0:0:0:0:0:FFFF:127/104. I will spell this out. Thanks for the catch. Will fix the idnits. Thanks, rahul