The last point that Sriram made is important to the higher level discussion of the problem.
Semantically what we are proposing is that a BGP speaker can ad a semantic tag to a route that describes restrictions on the intent of the authorization that is implicit in sending a peer a BGP route. Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was the intent that the sender expects that you will not redistribute this update to transit providers. "I am sending you this route, but I do not wish it propagated to your providers" So discussing the semantics of the tag: what that tag applies to (e.g., specific route, vs peering session), what the tags attempt to signal, what the security properties of such a tag should be, and what policies might one build using such tags ... is the important part. The specific encoding proposed was the result of one attempt to think through these issues ... but not all the thoughts made it into the draft. dougm -- DougM at Work
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
