Subject: [Idr] minutes of IDR meeting

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Mar 2009 06:48:54 -0700

Folks,

Attached are minutes of IDR meeting.

The deadline for comments is 3/31/2009.

Yakov.
-----------------------------------------------------------------
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.