Last Call: draft-ietf-l2vpn-arp-mediation-17.txt (ARP Mediation for IP Interworking of Layer 2 VPN) to Proposed Standard
The IESG has received a request from the Layer 2 Virtual Private Networks WG (l2vpn) to consider the following document: - 'ARP Mediation for IP Interworking of Layer 2 VPN' draft-ietf-l2vpn-arp-mediation-17.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as ARP Mediation. ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' to Proposed Standard (draft-ietf-pwe3-fat-pw-07.txt)
The IESG has approved the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' (draft-ietf-pwe3-fat-pw-07.txt) as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ Technical Summary Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. Working Group Summary The WG process was smooth. An IPR disclosure was made after this document had completed IETF last call. A new IETF last call was immediately made specifically calling out the IPR disclosure as the reason. The last call announcment was copied to the PWE3 working group mailing list. No comments of any type were received during the second last call. Document Quality There are no concerns with document quality. Personnel Matthew Bocci (matthew.bo...@alcatel-lucent.com) is the document shepherd. Adrian Farrel (adr...@olddog.co.uk) is the responsible AD. RFC Editor Note Section 1.1 OLD A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], Section 9. NEW A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], see Section 9 of this document. END Section 1.2 s/it will always be will preceded/it will always be preceded/ Section 1.2 OLD This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that this may be a departure from considerations that apply to the general MPLS case. NEW This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that setting the TTL to 1 regardless of the payload may be considered a departure from the TTL procedures defined in [RFC3032] that apply to the general MPLS case. END Section 1.2 OLD This document does not define a use for the TC bits (formerly known as the EXP bits) in the flow label. Future documents may define a use for these bits, therefore implementations conforming to this specification MUST set the TC bits to zero at the ingress and MUST ignore them at the egress. NEW This document does not define a use for the TC field [RFC5462] (formerly known as the EXP bits [RFC3032]) in the flow label. Future documents may define a use for these bits, therefore implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress. END Section 2 OLD it is required that the NSP NEW it is REQUIRED that the NSP END Section 4 OLD The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. A PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. A PE that is using PW signalling and which does not receive a FL Sub- TLV from its peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. NEW The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and which does not receive a FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. END Section 4.1 OLD o FL (value 0x17) is the flow label sub-TLV identifier assigned by IANA (seeSection 11 ). NEW o FL (value 0x17) is the flow label indicator sub-TLV identifier assigned by IANA (see Section 11). END OLD 7. OAM NEW 7. Operations, Administration, and Maintenance (OAM) END Section 7 OLD +---+ | | | VCCV Message | n octets | | +---+ | Optional Control Word | 4 octets +---+ | Flow label | 4 octets +---+ | PW label | 4 octets
Protocol Action: 'Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths' to Proposed Standard (draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt)
The IESG has approved the following document: - 'Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP- TE Label Switched Paths' (draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-no-php-oob-mapping/ Technical Summary There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some out-of-band (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. Working Group Summary There was no objection to this work within the MPLS working group, but there were very few voices raised in support at any time in the process. Document Quality As a result of the low level of contribution from within the WG additional reviews were sort and these resulted in substantial changes to the document. Personnel Martin Vigoureux (martin.vigour...@alcatel-lucent.com) is the document shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note Section 1 OLD As there is one-to-one correspondence between bits in the Attribute Flags TLV and the RRO Attributes subobject, corresponding flags to be carried in RRO Attributes subobject are also defined. NEW As there is one-to-one correspondence between bits in the Attribute Flags TLV and the Record Route Object (RRO) Attributes subobject, corresponding flags to be carried in RRO Attributes subobject are also defined. END Section 3 Addition of non-PHP behavior adds a variable of attacks on the label assigned by the Egress node. s/variable/variety/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'An Interface ID Hello Option for PIM' to Proposed Standard (draft-ietf-pim-hello-intid-01.txt)
The IESG has approved the following document: - 'An Interface ID Hello Option for PIM' (draft-ietf-pim-hello-intid-01.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ Technical Summary This document defines a new PIM Hello option to advertise an interface identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. Working Group Summary There is consensus within the PIM WG to publish the document. The participation has been with individuals from a variety of vendors and providers. The authors made minor changes based upon feedback during the wglc. Document Quality There exists at least one implementation of this protocol for which IANA early allocation was performed. Personnel Mike McBride is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note Section1 New final paragraph NEW All multi-byte integers in this specification are transmitted in network byte order (i.e. most-significant byte first). END Section 2 OLD The Interface Identifier option is used to identify which interface of a neighboring router a PIM Hello [RFC4601] is sent on. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. NEW The Interface Identifier option is used to identify through which interface of a neighboring router a PIM Hello [RFC4601] was sent. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. END Section 2.1 OLD The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. Many systems make use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]. NEW The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. If a node goes down and comes up again. the Identifier for each interface MAY change. Many systems make use of an ifIndex [RFC2863] as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may have messages that optionally reference an Interface Identifier, and they may use the value of 0 to show that no Interface Identifier is being referenced. Note that the value of 0 is not a valid ifIndex as defined in [RFC2863]. END Section 2.2 OLD The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifier, but MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 bit identifiers for routers. One may use the same identifier to construct the Interface Identifier option, provided it meets the stability and uniqueness requirements of protocols making use of this option. NEW The 32 bit Router Identifier may be used to uniquely identify the router. The requirements for the scope in which the Router Identifier needs to be unique depend on the protocols that utilize it. It may need to be unique within some administrative domain, or it may possibly be globally unique. A router implementation selects a Router Identifier according to a configured policy that defines the uniqueness scope. Thus, an implementation MAY be configured to choose an IPv4 unicast address assigned to the router as the Router Identifier, but the implementation MUST allow the identifier to be
Document Action: 'General Area Review Team (Gen-ART) Experiences' to Informational RFC (draft-doria-genart-experience-04.txt)
The IESG has approved the following document: - 'General Area Review Team (Gen-ART) Experiences' (draft-doria-genart-experience-04.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-doria-genart-experience/ Technical Summary The General Area Review Team (Gen-ART) has been doing Reviews of Internet Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. Working Group Summary This is not the product of an IETF WG. Document Quality Many Gen-ART members, including some that are no longer on the team, have review the document. All three IETF Chairs that were served by the Gen-ART have reviewed it too. Personnel Reviewed for the IESG by Russ Housley. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions' to Proposed Standard (draft-ietf-grow-geomrt-07.txt
The IESG has approved the following document: - 'Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions' (draft-ietf-grow-geomrt-07.txt) as a Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ Technical Summary This document extends the Border Gateway Protocol (BGP) MRT export format for routing information to include terrestrial coordinates. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? I don't believe there are implementations already in existence, this draft would extend existing MRT implementations, however. Personell Chris Morrow is shepherd for this draft. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Terminology for Benchmarking Link-State IGP Data Plane Route Convergence' to Informational RFC (draft-ietf-bmwg-igp-dataplane-conv-term-23.txt)
The IESG has approved the following document: - 'Terminology for Benchmarking Link-State IGP Data Plane Route Convergence' (draft-ietf-bmwg-igp-dataplane-conv-term-23.txt) as an Informational RFC This document is the product of the Benchmarking Methodology Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bmwg-igp-dataplane-conv-term/ All BMWG RFCs are Informational, but they are implemented by test equipment vendors and cited in trade publications and advertisements. Technical Summary This set of memos describes the process for benchmarking IGP Route Convergence as described in the Applicability memo. This approach measures convergence time in the dataplane, and treats the Device Under Test as a Black Box. The methodology and terminology memos define the metrics and process for benchmarking route convergence that can be applied to any link-state IGP such as ISIS and OSPF. WG Summary The drafts received extensive comment and review since their initial acceptance on the WG charter in 2003. Many active WG members affirmed that this set of drafts were ready for publication (WGLC in October, 2005). There was a subsequent cross-area review that resulted in additional minor revisions, discussed and agreed by the WG. Protocol Summary These methods have been performed in at least one lab, and review comments were posted based on that experience. Several test equipment vendors commented actively during the WG development. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-boucadair-pppext-portrange-option-07.txt
The IESG has no problem with the publication of 'Huawei Port Range Configuration Options for PPP IPCP' draft-boucadair-pppext-portrange-option-07.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-boucadair-pppext-portrange-option/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-boucadair-pppext-portrange-option/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document proposes a PPP IPCP extension to negotiate port ranges for A+P type solutions. Working Group Summary This is an independent submission via the RFC Editor. Document Quality n.a. Personnel The responsible Area Director is Jari Arkko. RFC Editor Note 1. The IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-weeb-research-to-internet-stds-02.txt
The IESG has no problem with the publication of 'How to Contribute Research Results to Internet Standardization' draft-weeb-research-to-internet-stds-02.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-weeb-research-to-internet-stds/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-weeb-research-to-internet-stds/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community. For an individual researcher, it can however by quite puzzling how to begin to most effectively participate in the IETF and - arguably to a much lesser degree - in the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. Working Group Summary This is a submission on the independent stream; not a working group document. Document Quality No protocol is described in this document. It contains practical advice and useful encouragement for increasing positive IETF participation from the academic and research communities. Personnel Wesley Eddy is the area director assigned for the RFC 5742 review, per the IESG procedure for performing such reviews. He proposes that the IESG position on this document be: The IESG has concluded that there is no conflict between this document and IETF work. IESG Note The IESG notes that response (1) from RFC 5742 applies: The IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-lisp-map-versioning-02.txt (LISP Map-Versioning) to Experimental RFC
The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Map-Versioning' draft-ietf-lisp-map-versioning-02.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the LISP Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
