headers
Tony Li | 1 Feb 2006 19:57
Picon
Gravatar

Next revision of AS_HOPCOUNT


Hi all,

Surprisingly, my mailbox wasn't full this morning.  For those that
didn't notice, the next revision of the AS_HOPCOUNT draft (now
AS_PATHLIMIT) has been released.  Here's the link:

http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-00.txt

Please comment now...  Given our previous discussions, I can't believe
that there are no further comments.  ;-)

Regards,
Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 28 comments |
headers
Erblichs | 2 Feb 2006 02:40
Picon
Favicon

draft-ietf-idr-as-pathlimit-00.txt

Tony Li, et al,

	1) Do I implicitly read that this new will also
	   limit looping paths to AS_PATHLIMIT?

	2) 5.1 Operations
   If the
   AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH,
   then the route should not be sent.

	I must be dsylexic, I would think that you want the number of
	ASs found to be less or equal to the AS_PATH_LIMIT,

	Thus...

	If the number of ASs found in the AS_PATH exceeds the
        AS_PATHLIMIT value, then the route should not be forwarded.

	As this also seems backward..

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

	3a) Stupid question.

	  Why isn't this AS_PATHLIMIT decremented at each BGP speaker
	  who would examine the route, and when it reaches 0, then
	  the route would be dropped?

	3b) Another stupid question
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tony Li | 2 Feb 2006 03:09
Picon
Gravatar

Re: draft-ietf-idr-as-pathlimit-00.txt


Hi,

> 	1) Do I implicitly read that this new will also
> 	   limit looping paths to AS_PATHLIMIT?

I'm not sure I understand the question.  The additional path attribute
is in addition to all existing BGP attributes and mechanisms, and does
not replace or supplant any of them.  Thus, the normal AS_PATH loop
detection should prevent all looping paths even without AS_PATHLIMIT.

> 	2) 5.1 Operations
>    If the
>    AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH,
>    then the route should not be sent.
> 
> 	I must be dsylexic, I would think that you want the number of
> 	ASs found to be less or equal to the AS_PATH_LIMIT,
> 
> 	Thus...
> 
> 	If the number of ASs found in the AS_PATH exceeds the
>         AS_PATHLIMIT value, then the route should not be forwarded.
> 
> 	As this also seems backward..
> 
> 	If the attribute value exceeds the number of ASes in the
>    AS_PATH, then the route MUST be ignored without further processing.

Dyslexia is all mine.  Your corrections are what was intended.  Sorry
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erblichs | 3 Feb 2006 09:03
Picon
Favicon

Re: draft-ietf-idr-as-pathlimit-00.txt

Tony Li, et al,

	Inline..

	This is just a expectation.

	Mitchell Erblich
	

Tony Li wrote:
> 
> Hi,
> 
> >       1) Do I implicitly read that this new will also
> >          limit looping paths to AS_PATHLIMIT?
> 
> I'm not sure I understand the question.  The additional path attribute
> is in addition to all existing BGP attributes and mechanisms, and does
> not replace or supplant any of them.  Thus, the normal AS_PATH loop
> detection should prevent all looping paths even without AS_PATHLIMIT.
> 

	I was thinking where the loop is sufficently large that the
	AS_PATHLIMIT is encountered before normal AS_PATH detection.

	Wouldn't it then implicitly also duty as an additional means
	to stop larger loops? Thus, I associate AS_PATHLIMIT equal to
	a TTL size and decrementing by 1 at each BGP speaker.

	Thus, am I right that no loops can completely form (loop onto itself)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Li | 3 Feb 2006 11:36
Picon
Gravatar

Re: Re: draft-ietf-idr-as-pathlimit-00.txt


Hi Mitchell,

> 	I was thinking where the loop is sufficently large that the
> 	AS_PATHLIMIT is encountered before normal AS_PATH detection.
> 
> 	Wouldn't it then implicitly also duty as an additional means
> 	to stop larger loops? Thus, I associate AS_PATHLIMIT equal to
> 	a TTL size and decrementing by 1 at each BGP speaker.

Well, in the sense that AS_PATHLIMIT restricts the path, it will stop
all longer paths, both loops and non-loops.

> 	Thus, am I right that no loops can completely form (loop onto itself)
> 	that are larger than AS_PATHLIMIT?

BGP already prevents all inter-AS loops from forming.  AS_PATHLIMIT is
only operating at the inter-AS level, so it will not do anything to
prevent intra-AS transient loops.

> 	Somehow, I think this is a good thing.. But during transient
> 	routing loops distances between Provider Edege boundries may
> 	increase and the AS_PATHLIMIT may be too short for the route
> 	to be propagated to the expected destination..

Presumably, the transient routing loop is within an AS, as part of the
IGP converging.  Assuming that the duration is sufficiently short, this
should not perturb BGP at all.

Tony
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 12 Feb 2006 22:18
Favicon

2858bis and SNPA

Folks,

If any of you has an implementation that uses the SNPA field
of MP_REACH, please drop me an e-mail. If we would not get
at least two reports of an implementation that uses the SNPA field 
within the next two weeks we'll need to assume that this field is not used,
and therefore has to be deprecated as we move to Draft Standard.

Yakov.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Susan Hares | 13 Feb 2006 18:54

RE: 2858bis and SNPA

Yakov:

One of our implementations use the SNPA field of MP_REACH. 

Count 1. 

Sue

-----Original Message-----
From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of
Yakov Rekhter
Sent: Sunday, February 12, 2006 4:18 PM
To: idr <at> ietf.org
Subject: [Idr] 2858bis and SNPA

Folks,

If any of you has an implementation that uses the SNPA field
of MP_REACH, please drop me an e-mail. If we would not get
at least two reports of an implementation that uses the SNPA field 
within the next two weeks we'll need to assume that this field is not
used,
and therefore has to be deprecated as we move to Draft Standard.

Yakov.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manav Bhatia | 15 Feb 2006 06:18

Multiple Paths in BGP

Hi,

Recently there have been proposals in the IDR to extend BGP to advertise
multiple paths for a given NLRI. There are various applications that could
use this - Passive Route Servers, Interdomain TE, ECMP, MED oscillations,
Suboptimal routing with RRs, etc. 

We have written a draft that proposes a new path attribute MULTIPLE_HOP that
can be used to advertise multiple paths in BGP. This draft has been built
upon the feedback/suggestions that we received for the earlier versions of
our ecmp draft.

http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t
xt

We also propose a way for BGP speakers to legitimately do ECMP using the new
path attribute defined in the above draft. 

http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt

Would appreciate comments on the above drafts.

Thanks,
Manav

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Sanders | 16 Feb 2006 03:28
Picon

RE: Multiple Paths in BGP


> Recently there have been proposals in the IDR to extend BGP to advertise
> multiple paths for a given NLRI. There are various applications that could
> use this - Passive Route Servers, Interdomain TE, ECMP, MED oscillations,
> Suboptimal routing with RRs, etc.
 
I read the drafts but could find nothing pertaining to Interdomain TE. How can the ideas presented in the draft help in doing Interdomain TE? 
 
Toms.
 
>
> We have written a draft that proposes a new path attribute MULTIPLE_HOP that
> can be used to advertise multiple paths in BGP. This draft has been built
> upon the feedback/suggestions that we received for the earlier versions of
> our ecmp draft.
>
> http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t
> xt
>
> We also propose a way for BGP speakers to legitimately do ECMP using the new
> path attribute defined in the above draft.
>
> http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt
>
> Would appreciate comments on the above drafts.
>
> Thanks,
> Manav
>
>
>

--
Toms. 
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 752 comments |
headers
Yakov Rekhter | 16 Feb 2006 08:21
Favicon

WG Last Call on draft-ietf-l2vpn-signaling-06.txt

Folks,

WG Last Call on draft-ietf-l2vpn-signaling-06.txt is over.
There has been no comments during the Last Call.

Yakov.
------- Forwarded Message

Date:    Thu, 26 Jan 2006 10:20:32 -0800
From:    Yakov Rekhter <yakov <at> juniper.net>
To:      idr <at> ietf.org
cc:      Susan Hares <skh <at> nexthop.com>, Danny McPherson <danny <at> tcb.net>,
	 Stewart Bryant <stbryant <at> cisco.com>
Subject: [Idr] WG Last Call on draft-ietf-l2vpn-signaling-06.txt

Folks,

This is to start the IDR WG Last Call on
draft-ietf-l2vpn-signaling-06.txt (as this document has some BGP-related
stuff). The Last Call ends Feb 10,2006.

Yakov.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

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

Gmane