How is this different than tagging with communities today? In either case, the provider's correct action on the semantics is needed (and can go awry through misconfiguration).
Tony On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
