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.