headers
Internet-Drafts | 4 Jan 21:50
Picon
Favicon

I-D ACTION:draft-ietf-idr-bgp-multisession-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Multisession BGP
	Author(s)	: J. Scudder, C. Appanna
	Filename	: draft-ietf-idr-bgp-multisession-03.txt
	Pages		: 14
	Date		: 2007-1-4
	
This specification augments "Multiprotocol Extensions for BGP-4" [MP-
   BGP] by proposing a mechanism to allow multiple sessions to be used
   between a given pair of BGP speakers.  Each session is used to
   transport routes for one or more AFI/SAFI.  This provides an
   alternative to the current [MP-BGP] approach of multiplexing routes
   for all AFI/SAFI onto a single connection.

   Use of this approach is expected to increase the robustness of the
   BGP protocol as it is used to support more and more diverse AFI/SAFI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Jan 21:50
Picon
Favicon

I-D ACTION:draft-ietf-idr-as-pathlimit-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: The AS_PATHLIMIT Path Attribute
	Author(s)	: T. Li, et al.
	Filename	: draft-ietf-idr-as-pathlimit-03.txt
	Pages		: 16
	Date		: 2007-1-5
	
This document describes the 'AS path limit' (AS_PATHLIMIT) path
   attribute for BGP.  This is an optional, transitive path attribute
   that is designed to help limit the distribution of routing
   information in the Internet.

   By default, prefixes advertised into the BGP graph are distributed
   freely, and if not blocked by policy will propagate globally.  This
   is harmful to the scalability of the routing subsystem since
   information that only has a local effect on routing will cause state
   creation throughout the default-free zone.  This attribute can be
   attached to a particular path to limit its scope to a subset of the
   Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 12 Jan 22:37
Picon
Favicon

AS_PATHLIMIT


Folks,

Are there any more comments on AS_PATHLIMIT?

Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 4 comments |
headers
Erblichs | 20 Jan 02:22
Picon
Favicon

Re: AS_PATHLIMIT

Tony Li,

	I have a few concerns/ questions.

	1) I seem to recall in either a non-IETF
	   document of a IETF doc, that AS_PATHLIMIT
	   was already used to determine whether
	   some form of looping was done. With this
	   value the same AS could be added to allow
	   an alternate pathing method.

	   It will limit a non redundant AS looping
	   environment to this LIMIT value. Right?

	   Should a section thne be added for
	   "loop mitigation"?

	2) As was mentioned in the draft, AS_PATHLIMIT
	may be changed by other than the originator.

	Would it then make sense, if the change was
	intentionally done, to suggest a parasitic
	version field. This, COULD then be incremented
	each time a this value was changed because of
	policy mechanisms.

	3) Of of the reasons for this new value is to
	   restrict the propogation of routing information.

	   However, with this restriction, doesn't it
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tony Li | 20 Jan 02:55
Picon
Favicon

Re: AS_PATHLIMIT


Hi Mitchell,

> 	1) I seem to recall in either a non-IETF
> 	   document of a IETF doc, that AS_PATHLIMIT
> 	   was already used to determine whether
> 	   some form of looping was done. With this
> 	   value the same AS could be added to allow
> 	   an alternate pathing method.
>
> 	   It will limit a non redundant AS looping
> 	   environment to this LIMIT value. Right?
>
> 	   Should a section thne be added for
> 	   "loop mitigation"?

I'm unaware of any other documents (other than prior revs of this  
one) that refer to AS_PATHLIMIT.

In any case, AS_PATHLIMIT should have no impact whatsoever on BGP's  
normal loop prevention mechanisms.  It should only provide an  
additional mechanism for prefix filtering.

> 	2) As was mentioned in the draft, AS_PATHLIMIT
> 	may be changed by other than the originator.

More strictly, the AS_PATHLIMIT may be removed by an AS.  Another  
AS_PATHLIMIT can then be added, but it should always include the AS  
number of the domain that added the attribute.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erblichs | 20 Jan 04:12
Picon
Favicon

Re: AS_PATHLIMIT

Tony Li,

	I think you missed my points.

	You were justifying the use of AS_PATHLIMIT
	to limit the scope of specific/local routing
	information to the network.

	0) NEW:  I don't quite see why this new proposed
	   attribute would not be a non-transitive
	   optional category?

	   If the value is unknown by one or more BGP
	   nbrs, shouldn't that restrict the usage to
	   those local BGP spkrs? Without doing so
	   allows the route to be passed along with
	   the result of no AS_PATHLIMIT being set.
	   This clearly was not the intent when the
	   AS-PATHLIMIT was set.
	   Right?

	3)  Summary: Change "MUST" to "SHOULD".

>From the draft:
	If the number of ASes in the AS_PATH exceeds the value of
   the AS_PATHLIMIT attribute, then the route MUST be ignored without
   further processing.

	Sorry, IMO, the AS_PATHLIMIT is a origination filter,
	where the normal filters are locally applied based
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Li | 20 Jan 06:49
Picon
Favicon

Re: AS_PATHLIMIT


Mitchell,

> 	I think you missed my points.

Sorry.  I'm trying the best that I can.  Please feel free to enclose  
clue.

> 	You were justifying the use of AS_PATHLIMIT
> 	to limit the scope of specific/local routing
> 	information to the network.
>
> 	0) NEW:  I don't quite see why this new proposed
> 	   attribute would not be a non-transitive
> 	   optional category?

Well, we want it to be transitive as we want it to cross ASes that  
don't understand the attribute.

> 	   If the value is unknown by one or more BGP
> 	   nbrs, shouldn't that restrict the usage to
> 	   those local BGP spkrs? Without doing so
> 	   allows the route to be passed along with
> 	   the result of no AS_PATHLIMIT being set.
> 	   This clearly was not the intent when the
> 	   AS-PATHLIMIT was set.
> 	   Right?

If the attribute is not understood by a BGP speaker, then it  
hopefully will be received by some BGP speaker that recognizes it and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 22 Jan 21:40
Favicon

IDR WG agenda

Folks,

Its about time to start thinking about agenda items for the next
IETF. Please forward any IDR agenda items you might have to Sue and
myself. The deadline is Feb 23.

And if you plan to make a presentation, please also keep in mind
the rule "no Internet Draft - no time slot".

Sue & Yakov.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |

Gmane