Tue, May 09, 2017 at 07:20:26PM -0700, Suresh Krishnan: > Suresh Krishnan has entered the following ballot position for > draft-ietf-grow-large-communities-usage-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Overall the document was well written and easy to read. I did have one > question though. It is not clear how the values for the Local data part 1 > are matched up to the functions and communicated between the peer ASes? > Is this going to stay purely a local matter between ASes or is there > going to be a movement towards some sets of known functions (e.g. the BGP > blackhole community RFC7999)?
LD1 and LD2 are expected to be unique to and defined by the GA (ASN). No effort was made to address standardizing LD1 or LD2 values and this was intentionally avoided in discussion of both this draft and RFC8092, which itself creates no well-knowns like RFC7999. well-knowns such as RFC7999 are well served by RFC1997 communities and may co-exist with RFC8092 communities, thus there is no need to duplicate them. An effort could be made to standardize LD1 or LD2 or define well-knowns requiring the utility of RFC8092, but that is considered out of scope for this draft - and likely a rathole best explored separately. Thanks for reviewing. Prost _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
