Minutes IETF114: grow
minutes-114-grow-00

GROW WG Meeting notes:

* Update on Active WG documents - Job Snijders:
- draft-ietf-grow-bmp-tlv-ebit approved for WG adoption
- draft-spaghetti-grow-nrtm-v4 approved for WG adoption
- draft-ietf-grow-bmp-tlv doc needs a write-up from the chairs

* ANYCAST Well-Known BGP Community - Maximilian Wilhelm
- draft-wilhelm-grow-anycast-community-01
- Proposes a new well-known BGP community to tag anycast prefixes
- Asks operators to always use hot-potato routing for tagged prefixes
- Author requests feedback.

Q&A:
- Unknown Participant: Q: Do you think it makes sense to use large
  communities or would you prefer to to be a generic community. A: Thought
  about using large communities, but open to the WG to decide. Author afraid
  that Large Communities may not be sufficiently widely supported.
- Ben Maddison (Akamai): Q: I wouldn't allow any 3rd party network to send
  me hints that alters my local routing policy without some trust mechanism.
  If that trust needs to be established out of band anyway, then you lose the
  benefit of the community. A: Author sees the point and suggests with RPKI
  it should be OK to filter.
- Tom Hill (BT): Q: The all or nothing solution could go very wrong. Is
  there a proposal to track and inform owners that they haven't implemented
  all-or-nothing. A: I see the point. Should be possible with current routing
  information. (Route Views, RIS etc.). Would require asking operators to pay
  attention.
- Jeff Haas (Juniper): Q: There is no such thing as a well-known Large Community
- Linda Dunbar: Q: Since ANYCAST is used widely, can ANYCAST address be
  treated as Multicast address? so the ports belonging to the ANYCAST can
  register and the network can forward appropriately?
- David Lamparter: Q: re: trust issue, isn't it 2 separate things, 1 being
  the advertisement in a permissive way, vs having an expectation of doing
  something with it.
- Rudiger Volk: Q: Comment that Large Community space has not assigned any
  space for special purposes, but the space is large. Opinion that it should.
  Attachment of communities can be manipulated by any hop on the path.
  Assumption that anytime the origin AS should do the tagging so that any
  transiting AS should
- Warren Kumari (no hats): Q: Networks decide if they want to do hot potato
  or not, that's their decision. Nothing stops me applying this to any route
  I feel like. Suggests calling it a "Different routing policy for this
  prefix" community instead of Anycast specifically.
- Ben Maddison (Akamai): Comment: Feels that this would lose it's
  usefulness when more than 1-hop away.
- Freddy Kunzler (co-author): Comment: When selling transit to a network
  that was on-selling transit to Middle East, transit customer prefixes
  usually higher localpref, so our local customers were using a route to the
  Middle East. If we had known it was an anycast prefix, we could've made
  better route selection.
- Job Snijders (Chair): Comment: Request document defines Anycast.
- Chairs: More discussion required on the list before we decide if the WG
  wants to work on the document.


* YANG model for BMP - Camilo Cardona
- drafts-cptv-grow-bmp-yang
- Author requests WG adoption
- Ben Maddison (Akamai): Q: Is this work available via Github etc. to help
  with collaboration/feedback. A: We don't, but we can make it public.
- Warren Kumari (AD): Comment: There are also the IETF YANG Doctors that
  can help the WG
- Tom Hill (BT): Comment: There has been a suggestion in NetMod to group
  all WG YANG models together in to a centralised NetMod repo.
- Job Snijders (Chair): Will launch a WG adoption call on-list.