See inline replies indicated with *** below. On Sat, Jan 8, 2011 at 3:54 PM, Randy Bush <[email protected]> wrote:
> thank you, thank you, thank you, for your review. > > > Comment 1) The validation state terminology used in this draft is not > > consistent with the terminology of draft-sidr-pfx-validate. That > > draft uses states: valid, invalid, not found, whereas this draft uses > > states: valid, invalid, unknown. Do we want these to be consistent > > across i-ds? The 3 states are defined in draft-sidr-pfx-validate but > > are not defined here. We should either define them or point to the > > definition in draft-sidr-pfx-validate where they are defined. > > thanks. will do. are you happy with "not found?" i have had to sit > through meetings with a bunch of folk discussing this until i had to > leave the room, and definitely have lost any opinion i might have ever > had on the subject. > *** I don't care which is used as long as it is the same in all internet drafts. > > > Comparison of draft-sidr-pfx-validate section 6 called "deployment > > considerations": > > > > I'm confused by the relationship of this draft to > > draft-sidr-pfx-validate section 6 called "deployment considerations". > > Is this the operational section and therefore should > > draft-sidr-pfx-validate reference draft-sidr-origin-ops? > > probably a reference from pfx-validate would be good. i'll have a talk > with the authors :) > *** Agree. > > > The deployment guidance is not the same in sidr-pfx-validate as it is > > in sidr-origin-ops in the sense that there are no SHOULDs or > > MUSTs. The deployment considerations in sidr-pfx-validate are just > > advice. Here is the specific text from draft-sidr-pfx-validate: > > > > 6. Deployment Considerations > > > > "Once a route is received from an EBGP peer it is categorized > > according the procedure given in section 2. Subsequently, routing > > policy as discussed in section 3 > > <http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-00#section-3 > > > > can be used to take action based on the validation state. > > > > Policies which could be implemented include filtering routes based on > > validation state (for example, rejecting all "invalid" routes) or > > adjusting a route's degree of preference in the selection algorithm > > based on its validation state. The latter could be accomplished by > > adjusting the value of such attributes as LOCAL_PREF. > > > > In some cases (particularly when the selection algorithm is > > influenced by the adjustment of a route property that is not > > propagated into IBGP) it could be necessary for routing correctness > > to propagate the validation state to the IBGP peer. This can be > > accomplished on the sending side by setting a community or extended > > community based on the validation state, and on the receiving side > > by matching the (extended) community and setting the validation > > state." > > i am not sure if this conflicts with or even overlays origin-ops. it is > not suggesting policy, merely discussing mechanisms. clue bat please. > **** Well, frankly I think your text is just perfect and I prefer it to what is in the first paragraph of this deployment considerations section. (I'm ignoring the second paragraph for this discussion BTW.) By the use of the word SHOULD instead of MUST along with the ranking of the relative preference, you convey a strong sense of what the best practice is without mandating it. I think this is exactly the right way to do it. Notice above how they talk about throwing information away as an example "(for example, rejecting all invalid routes)", but your text points out why you might not want to do this in case there is some problem/error. The relative preference guidelines are a very clever way of handling this state information and I was convinced it was the best way to do it after reading your draft. As to whether or not the text (first paragraph above) conflicts or overlays what you have written: Since you did not use the word MUST, it does not conflict with it because you allow anything. They allow anything as well because they neither used MUST nor SHOULD. However, if your guidelines are taken (meaning the SHOULDs), I believe your guidelines are a subset of what is recommended above. The important point is that your recommendations are more specific and I feel like I have a better idea of what to do with the state information and the advice is both sound and clever. This is why I like what you wrote and think it should be referenced in this section of draft-sidr-pfx-validate so they don't miss it. Maureen > and thanks again! > > randy >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
