IDR Working Group Meeting IETF 74 Monday 23 March 2009 Chairs: Yakov Rekhter, Sue Hares Minutes: Geoff Huston 1. Document Status Update Since the last WG meeting there have been 3 published RFCs, adopted 3 drafts as WG documents and had 2 new protocol parameter registries established. The BGP MIB2 draft will go to WG Last Call after this IETF meeting. Proposed WG procedures for documents calls for a wait period of up to 12 months following WG Last Call for an implementation report that details two (or more) independent implementations of the document that conform to the document's specifications as a precondition for passing the document to the IESG. Yakov noted the IPR disclosure on the flow spec draft, and polled the WG as to whether the document should be passed to the IESG. The consensus of the WG was to proceed with this document and pass it to the IESG. 2. draft-rfernando-idr-link-bandwidth-00.txt (See presentation slides) Draft proposes the use of an extended community to carry the link's bandwidth. There was discussion of the proposed use of a 2 byte AS number field and the explicit use of AS-TRANS for 4-byte AS representation. In WG discussion of this 2 byte field for the AS number value, The presenter claimed that the AS was present as a well-defined way of using this community, and the AS field had no intended semantic interpretation, as this community was intended to be used in a non-transitive fashion. This 2 byte AS number field also allowed 4 bytes for the specification of the bandwidth value. All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 3. draft-scudder-idr-optional-transitive-01.txt Enke Chen described the material presented in the drafts. (See presentation slides) Draft proposes a change to the behaviour as specified in RFC4271 such that the detection of a malformed optional transitive attribute should not necessarily cause a NOTIFICATION and a BGP peer session reset. The draft proposes that each optional transitive community define the behaviour for treatment of malformed versions of the attribute, and this can also include the option to discard the malformed optional transitive attribute under certain circumstances, or treat an update that contains such an optional transitive update as a withdrawal and obviate the need to perform a NOTIFICATION and peer reset under all circumstances. The treatment of malformed AS4_PATH attributes was cited as an example of the inappropriateness of the current NOTIFICATION response. It was noted that the responses of discarding the attribute or discarding the withdrawal both represented compromises, and that the appropriate behaviour may vary according to the intended purpose of the attribute. Accordingly, the draft notes that future specifications that propose optional transitive attributes MUST specify what an error is, and how it must be handled All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 4. draft-chen-rfc4893bis-02.txt The author described the material presented in the drafts. (See presentation slides) The draft is an update on RFC4893, that contains some editorial clarifications and some changes to the specification. The changes focus on handling malformed optional transitive attributes in the AS4-AGGREGATOR and AS4_PATH. The draft proposes specific responses for malformed attributes according to the context of the error (whether receiver from OLD or NEW BGP peer), and notes that the options of attribute discard or implicit withdraw have potential advantages and disadvantages. Discussion on whether dropping a malformed AS4_PATH attribute, with the consequent implications for the operation of BGP loop detection or to perform an implicit withdraw was an appropriate action. The chair noted that this was an operational issue with some pressing time constraints and a need for a timely pragmatic response from the WG on this. All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 5. draft-knoll-idr-qos-attribute, draft-knoll-idr-cos-interconnect The author described the material presented in the drafts. (See presentation slides) Not many WG members had read the draft. The chairs noted that the drafts would need greater levels of WG attention before making a WG decision on adoption or not. 6. draft-scholl-idr-advisory-00.txt The author described the material presented in the drafts. (See presentation slides) Discussion on the draft noted a previous draft relating to a BGP inform capability and requested further information on how this draft differs from the earlier contribution. The potential to use such a mechanism to perform max prefix negotiation (offer / accept) between peers was discussed. WG members also commented on the issues involved with extracting such messages from BGP logs and referring such items to operational personnel and compared this approach to the current practices for operational communications. The draft author indicated an intention to apply this feedback to the draft. 7. draft-rosen-idr-aigp-00.txt – 15 mins An author described the material presented in the draft. (See presentation slides) This draft describes an eBGP signalling mechanism using an optional transitive attribute intended to support MPLS environments where the network is configured using multiple AS's where the IGP metric across an AS can be communicated to neighboring AS's via this mechanism. Discussion concerned the relationship with this proposed approach and cost communities with MEDs, the nature of the operational requirements that motivated this proposed mechanism and the issue of possible impact of information leakage of this attribute beyond the intended community of use. Of the WG members who had read the draft there was no clear indication of a preference to adopt the draft as a WG item or not. The chairs will take the question to the mailing list. 8. IPR Presentation On behalf of the WG Yakov thanked Dave Ward for his support to the WG as Routing AD, with a round of applause from the WG. (See presentation slides) The presentation highlighted the responsibility of IETF participants to perform a timely disclosure of known IPR and that participants may wish to disclose knowledge of third party IPR, and that all participants should always assume that they need to know more about possible IPR than they currently know. The WG can makes its own decision about how it wishes to handle IPR and may do so either as a general procedure or on a case-by-case basis. Discussion noted that the IETF's IPR processes are the outcome of many years of efforts and are about transparency of process as well as allowing the WG's work to proceed, and the outcomes represent certain levels of compromise that reflect a broader issue of appropriate handling of IPR on a global scale.