Thomas, On Tue, Nov 15, 2016 at 07:52:59AM +0000, Exa wrote: > Thank you very much for this document which present ever eloquently one of > the issues with the current development process. > > It is however not how I would propose to move forward. As a individual > developer, I do not have an IANA code and I am not sure I could get one.
As mentioned elsewhere in thread, PENs are easy to get hence suggesting that managed code pode. I tried to make sure that was clear in the [IANA-PEN] link, but perhaps there's text I could add to make it more explicit? > Also it changes the way features are coded and would require re-coding once > the format is stable and or the code is defined and not simply a code change > which is for me unwise and an overkill. I have admittedly not taken a look at your implementation. My expectation for the bulk of BGP implementations based on my past experience is that the code associated with parsing or encoding a given path attribute is mostly separate on a per attribute basis. There's obviously some shared infrastructure to code the flags/code point/length of the standard path attribute. Since the inner container shouldn't need to move, it's mostly a matter of abstracting out the contents (the feature data, in the draft) and permitting them to be parsed or encoded in more than one code point. Perhaps working through an example may be appropriate. > I would rather see a much simpler solution: allocate some code point for > development and make them iBGP transitive only, (and give operators an option > to bypass this limit on selected eBGP links if they so wish...) And how would you propose to deal with code point allocation for this? For example, we already have 255 available. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
