BGP Deployment Group Meeting

Hi, The BGP Deployment Group Meeting is scheduled at 7-10 pm Tue Mar. 17 at this comming IETF meeting at San Diego. One of the topics will be discussed in this session is the mechanism for each domain to describe its routing policy and share them. As you know, sharing routing policy information is a means in helping avoiding domains set contradictary routing policies which leads packets go nowhere. It is importand for the enviroment which use routing protocols supports policy routing. Developing the sharing mechanism is one of the goal of this group. As a start, in our meeting at this ietf, we are going to develope a routing policy description form which hopefully will include all the policy descriptions we think is necessary to share. The policy description language in this form will be plain English initially but will be evolving to a common description language understood by machine. we will also discuss the mechansim of gathering and destribution of the form. I came up with a draft form which include some suggests from Yakov (thanks Yakov). I am including this draft form below. Please read it before our meeting and bring your comments and suggestions. Thanks! By the way, I will post an agenda shortly. --Jessica Routing Policy Description Form (Draft) ------------------------------- A. General Description of your domain a. List your Domain and the AS number(s) b. List the Routing administrator of the Domain Name: Organization: e-mail: phone number: c. List the networks that belong to your domain and mark them with RE or non-RE type if applicable. d. List your direct neighbor domain(s) and its AS number(s) e. List each IP address of your border router(s) which interface with your neighbor border router(s) and the Exterior Routing Protocol(s) used respectivly. f. Are your domain a Stub domain? Multi-homed Stub domain? Transit domain? Pure Transit domain? g. List the IGP used within your domain (optional for a non-transit domain) h. Describe the average bandwidth of your domain (optional for a non-transit domain) i. Describe the delay characteristic of average physical links, e.g. satellite, terriestrial, of your domain (optional for a non-transit domain) B. Policy Descriptions If you are a stub domain: o Outbound advertisement filtering: list the set of nets belong to your domain that you do not advertise to your neighbor. o Inbound acceptance filtering: list the set of ASs whose nets you do or (do not) accept from your neighbor(s) If AS number is not a satisfactory granularity, list the set of nets. o Describe your routing policy based on your AUP (e.g. RE vs non-RE traffic, etc.) o Does your border router default to your neighbor border router? If you are a multi-homed stub domain: o Outbound advertisement filtering: list the nets belong to your domain that you do not advertise to your neighbors. o Inbound acceptance filtering: list the set of ASs whose nets you do or (do not) accept from your neighbor(s) If AS number is not a satisfactory granularity, list the set of nets. o List the prefrence/denial of the neighbor ASs which can route your traffic to the same destination. o Describe your routing policy based on your AUP (e.g. RE vs non-RE traffic, etc.) o Do you point default to your neighbor(s)? If yes, describe the mechanism. If you are a transit domain: o Outbound advertisement filtering: list the nets belong to you (not a pure transit domain) that you do not advertise advertise to your direct neighbors o Inbound acceptance filtering: list the set of ASs whose nets you do or (do not) accept from your neighbor(s) If AS number is not a satisfactory granularity, list the set of nets. o List the paris of source/destination ASs or nets that your domain does not provide transitivity with. o List the prefrence/denial of the ASs which can route your traffic to a certain destination. o Describe your routing policy based on your AUP (e.g. RE vs non-RE traffic, etc.) o Do you point default to your neighbor(s)? If yes, describe the mechanism.
participants (1)
-
Jessica Yu