Subject: [pim] PIM WG minutes

From: Mike McBride <[email-masked]>
Date: Fri, 6 Aug 2004 17:28:21 -0700 (PDT)

PIM WG minutes for IETF 60

[Thanks to Toerless Eckert for taking the notes]

Isidor Kouvelas
  - PIM-SM Update:
    Many editorial comments, few state machinery comments,
    all covered in newest version of spec. Summary had recently
    been sent by Bill Fenner to wg mailing list. Spec considered
    to be done. Diminishing return. Ask chairs to move spec to IESG.

    Tom Pusateri: Move on, go to IESG, no more comments!

  - Bidir-PIM: minor fixes only, no real protocol changes.
    One protocol issue open: applying BSR to Bidir-PIM: Wanted
    not to use BSR Hashing. Because this would forego load-splitting,
    solution is now to recommend longer hash-mask length by default.

    Toerless: The longer the hash mask, the more HW table entries
    are required. Up to implementors/customers to figure out how
    much it is worth it.

Alex Gall
  - Present BSR update (-04), with Nidhi and Stig.
  - Counted about 60 comments from mailing list.
  - Minor issues, need to revisit spec.
  - Scoping was not well understood. Leave unchanged right now and
    try to better understand.
  - Need to take out PIM-SM specifics out of draft now it's separate spec
    and supposed to apply to Bidir-PIM and PIM-SM.
  - Bidir flag should also be interpreted by implementations who
    do not support Bidir appropriately.
  - Remove hash function from BSR spec

    Mark Handley: It is ONLY in BSR spec ?
    Mike: Conclusion is that hash function is actually in PIM-SM

    Discussion (Bill, Lorenzo, Mark, Toerless, Hugh, Stig, Tom):
    where is the best place of the hash function ?
    - It is already in PIM-SM.
    - Wanted to have hash function in PIM-SM to have load balancing
       without necessarily using BSR (but also with static RP, etc..., ppp...)
    - Bill Fenner: ask Cisco whether we implement section 4.7
      (hashing across different RP information: autoRP/BSR/static)

    - Tom Pusateri: Thinks no implementation is doing this today,
      but just apply hash function to BSR.

    - Bill: Let's figure out what to fix: spec or implementation

    - Lorenzo: proposed workaround how to get implementation/spec into sync
      ...what...

    - Dino: Usage comment into spec: Should only run one RP discovery
      mechanism within an AS ?

    - Bill mentioned that not applying hash to non-BSR sources
      may be considered to be compliant by mean of calling it the
      allowed local policy also referred to by the spec.

    - Compare section 4.7 against implementation and take it to the list.

    - Update on changes in handling of holdtime in BSR (slide 4 - 6).

    - Q Mark Handley: to slide 6: Does not allow for the BSR to immediately
      remove C-RP from RPset. A: Should work by setting holdtime to 0.
      Mark: May cause compatibility issue with routers using different
      versions of the spec during holdtime.

    - Mike: Take to list, 20 min left for 5 drafts.

    - Scoping (page 7...13)

Mike:
  - Dense-mode spec is approved for experimental by IESG, need to get RFC.

Thom:
  - MIB work: Biggest piece left to do is v6 compatibility piece.
    Couldn't find person who knows PIM and PIM and MIBs.

Dino:
  - Anycast-PIM, version -02 update
    See preso from San Francisco IETF.
    11/2003, draf-ietf-pim-anycast-rp-00.txt
    MSDP interworking info added
    11/2003, draf-ietf-pim-anycast-rp-01.txt
    Post last call:
    11/2003, draf-ietf-pim-anycast-rp-02.txt
      -in RFC editors queue

  - Some slides about interworking issues. Describe interworking with
    external MSDP peerings.

  - present personal draft:
    draft-farinacci-pim-pop-count-00.txt

    - Lorenzo: sounds a bit like GRA in RMT, but hopefully more
      constrained, so may actually go anywhere

    - Toerless: Validate/explain how this work in the presence of
      IGMP snooping.

    - (??): Maybe out of scope of PIM WG or routing area, more like
      measurement in-band with routing protocol.

      Toerless: disagreed.

    - Tom: if implemented separately over UDP outside of UDP nobody
      coupld complain.

    - Mark: PIM tree topology information is very much related to
      PIM itself - but timezones for example might be a bit outside
      of the scope.

    - Pekka: ICMP ping ? would that allow similar results ?
      yes, possible out of band but does not scale.

Ice:
   - presenting pim-proxy draft.

   - Discussion: should default-route on core router be considered to
       override RPF-proxy.

   - WG chairs to work with ADs on updating PIM WG charter to potentially
     include these new drafts.

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Beau Williamson <[email-masked]>
Date: Mon, 09 Aug 2004 09:55:46 -0500

Does anyone have a link to the BSR update presentation?

The notes reference a discussion regarding holdtime.  This is certainly an 
area that I've recently found to have some issues both in the old version 
and what is in the new spec.  Possibly this was discussed/presented in 
slide 4-6 but since I was not able to attend I don't know if it was covered.

Thanks.

Beau Williamson

At 07:28 PM 8/6/2004, Mike McBride wrote:
>M

---

From: Mike McBride <[email-masked]>
Date: Wed, 11 Aug 2004 14:08:18 -0700 (PDT)

> Does anyone have a link to the BSR update presentation?

http://www.employees.org/~mmcbride/pimwg/IETF60/bsr-IETF-60.pdf

mike