headers
John G. Scudder | 4 Jun 04:37
Picon
Gravatar

draft-ietf-idr-rfc3065bis-06.txt editorial change

Folks,

While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the  
vigilant RFC Editor pointed out several nits with the draft.  Most  
can be resolved as minor editorial changes, however, one of them is  
slightly more than that.

Section 4.1 of the draft ("AS_PATH Modification Rules") is  
essentially a cut-n-paste of section 5.1.2 of the base spec, with  
necessary changes for confederations.  Unfortunately, we did not  
revise the draft to match when the base spec was revised.

To correct this, we propose to re-do section 4.1.  There are no  
changes of any substance compared to earlier versions, i.e. the  
intent is still to say "do what the base spec does, only do it with  
confed-type segments", but the text is brought into line with RFC 4271.

The change is extensive enough that we thought it worthwhile to poll  
the WG again.  Chairs, please consider this a request for a WGLC,  
only on this revised text.

Thanks,

--John (with Danny and Paul)

Revised section 4.1:

4.1.  AS_PATH Modification Rules

    AS_PATH is a well-known mandatory attribute.  This attribute
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 4 Jun 05:33
Favicon

Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.txt

Folks,

This is to start the IDR WG Last Call on draft-ietf-idr-rfc3065bis-06.txt.
Please note that the scope of this Last Call is limited to only the 
revised text.  

The Last Call ends on June 17.

Yakov.
------- Forwarded Message

Date:    Sun, 03 Jun 2007 22:37:21 -0400
From:    "John G. Scudder" <jgs <at> bgp.nu>
To:      idr <at> ietf.org
cc:      John Scudder <jgs <at> juniper.net>
Subject: [Idr] draft-ietf-idr-rfc3065bis-06.txt editorial change

Folks,

While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the  
vigilant RFC Editor pointed out several nits with the draft.  Most  
can be resolved as minor editorial changes, however, one of them is  
slightly more than that.

Section 4.1 of the draft ("AS_PATH Modification Rules") is  
essentially a cut-n-paste of section 5.1.2 of the base spec, with  
necessary changes for confederations.  Unfortunately, we did not  
revise the draft to match when the base spec was revised.

To correct this, we propose to re-do section 4.1.  There are no
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vishwas Manral | 7 Jun 23:02
Picon

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

Hi Tony,

I had a small doubt regarding the use of AS_PATHLIMIT attribute in
case the routes are getting aggregated. If the AS_PATHLIMIT is
different for different routes, what would be the AS_PATHLIMIT for the
aggregated route?

I think it should be the minimum of the component routes.

Thanks,
Vishwas

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 11 comments |
headers
Tony Li | 7 Jun 23:47
Picon
Favicon

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


On Jun 7, 2007, at 2:02 PM, Vishwas Manral wrote:

> I had a small doubt regarding the use of AS_PATHLIMIT attribute in
> case the routes are getting aggregated. If the AS_PATHLIMIT is
> different for different routes, what would be the AS_PATHLIMIT for the
> aggregated route?
>
> I think it should be the minimum of the component routes.

Hi Vishwas,

Thank you for your question.

As you probably surmised, we did not specify that behavior.  This is  
pretty much intentional, leaving it up to the implementation to  
decide what policy it will select by default.

The propagation of an aggregate may have no relationship to the  
desired propagation of the component routes, so manual intervention  
is probably the best alternative.  For typical aggregates, global  
flooding is unlikely to be an issue.  The problem that we have is  
quite the opposite...  global flooding of more specifics.  Trading a  
number of specifics for one aggregate is a net win.

Tony

_______________________________________________
Idr mailing list
Idr <at> ietf.org
(Continue reading)

Permalink | Reply | 9 comments |
headers
Erblichs | 8 Jun 01:27
Picon
Favicon

Re: Re: draft-ietf-idr-as-pathlimit-03.txt and Confeds

Group, et al,

	I disagree with the min for propogation.

	I can see that due to the fact that
	the attribute is transitive, then it should be passed
	no matter what. So, appling the min would effectively
	decrease the propogation to a non-transitive type attr
	based on the min value. We are trying to make sure that
	the attr is passed even if it is not understood. Thus,
	we SHOULD be able to reach the dst of PATHLIMITs based
	from our source. If we aggregate to the min, with
	periodicly changing aggregates, should we sometimes be
	able to reach a dst or should it be always? I fault
	for a consistent propogation distance of max with ALWAYS.

	Secondly, COULD a value ??0?? be chosen that defers its value
	to another value if present due to expected or possible
	aggregation, and use the TTL of the IP hdr if not 
	aggregated? MY assumption is that the TTL initial
	value COULD be set to a smaller than expected value.

	However, I have a larger concern with the attribute
	itself. Should the attribute also be decremented when
	traversing Confederations? Aren't two ASs essentially
	two sub/logical/virtual ASs and thus propogation of routing
	info be controllable at the entrance of a Confederation?

	Would you allow it to cross ONLY 3 ASs and keep going after
	100 Confederations because only 2 ASs were crossed?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kalpesh Zinjuwadia | 10 Jun 22:34
Favicon

BGP4 MIBv2 Question

Hi all,

 

I had a question regarding the “meshedClient” value of bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How does a route-reflector know whether the RR client is in full-mesh with other clients? Please let me know if I’m missing something.

 

I’ve pasted the description of this field below.

 

DESCRIPTION

            "This value indicates whether the given peer is a

             reflector client of this router, or not.  A value of

             nonClient indicates that this peer is not a reflector

             client.  A value of client indicates that this peer is a

             reflector client that is not fully meshed with other

             reflector clients.  A value of meshedClient indicates

             that the peer is a reflector client and is fully meshed

             with all other reflector clients.

 

             This value must be nonClient (0) for BGP external peers."

 

Thanks,

Kalpesh

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Jeffrey Haas | 11 Jun 00:05

Re: BGP4 MIBv2 Question

Kalpesh,

The same way you know if something is a route-reflector: By
configuration.

-- Jeff

On Sun, Jun 10, 2007 at 01:34:09PM -0700, Kalpesh Zinjuwadia wrote:
> Hi all,
> 
>  
> 
> I had a question regarding the "meshedClient" value of
> bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How
> does a route-reflector know whether the RR client is in full-mesh with
> other clients? Please let me know if I'm missing something.
> 

-- Jeff

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Ilya Varlashkin | 12 Jun 17:29

BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt)

Hello all,

I realise that now it's too late for significant changes in
draft-ietf-idr-rfc3065bis-06.txt, so I send this as standalone message.

Currently major implementations disregard length of AS_CONFED_SEQUENCE,
and such behaviour documented in step 3 of section 5.3 in
draft-ietf-idr-rfc3065bis-06. While MED or community+localpref can be
used to alter route preferences where only in-confederation path
different, I believe it will be advantageous to consider length of
AS_CONFED_SEQUENCE too as this can provide more clear and simple way of
choosing optimum route if path length within confederation varies.
Possible order for using AS_CONFED_SEQUENCE as tie-breaker could be
after MED and before IGP cost, i.e. somewhere between 'c' and 'e' in
section 9.1.2.2 of RFC4271). To avoid inconsistency with existing
implementation such change in best-path selection could be done via a
configuration option with default behaviour being as described in
RFC4271 and draft-ietf-idr-rfc3065bis-06.

Besides implementation work, are there other reasons not to use
AS_CONFED_SEQUENCE length as tie-breaker?

Cheers,
iLya

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 4 comments |
headers
Jeffrey Haas | 12 Jun 22:30

Re: BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt)

Ilya,

On Tue, Jun 12, 2007 at 05:29:50PM +0200, Ilya Varlashkin wrote:
> Besides implementation work, are there other reasons not to use
> AS_CONFED_SEQUENCE length as tie-breaker?

As long as the tie-breaking is consistent within the AS, it'll work
fine.  Perhaps a more interesting alternative to AS_PATH length
including confederation segments is to use confederation segment length
only when non-confederation lengths are comparable.

-- Jeff

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
Jeffrey Haas | 12 Jun 23:03

Re: BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt)

Responding to myself:

On Tue, Jun 12, 2007 at 04:30:00PM -0400, Jeffrey Haas wrote:
> Ilya,
> 
> On Tue, Jun 12, 2007 at 05:29:50PM +0200, Ilya Varlashkin wrote:
> > Besides implementation work, are there other reasons not to use
> > AS_CONFED_SEQUENCE length as tie-breaker?
> 
> As long as the tie-breaking is consistent within the AS, it'll work
> fine.  Perhaps a more interesting alternative to AS_PATH length
> including confederation segments is to use confederation segment length
> only when non-confederation lengths are comparable.

Doing this is usually pretty comparable to your IGP metric and may be
useful only when you have disjoint IGP domains.

-- Jeff

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

Gmane