Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt
From: Enke Chen <[email-masked]>
To: Zheng Wang <[email-masked]>
Cc: Enke Chen <[email-masked]>, Rohit Dube <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Fri, 27 Nov 1998 17:59:27 -0800

> Date:    Fri, 27 Nov 1998 18:37:52 -0500
> From:    Zheng Wang <[email-masked]>
> To:      Enke Chen <[email-masked]>
> CC:      Rohit Dube <[email-masked]>, [email-masked], [email-masked]
om,
	   [email-masked]

> 
> 
> Enke Chen wrote:
>  
> > After checking the new version of the document, it ***has***
> > indeed be corrected:
> > 
> >    When a RR reflects a route, 
> 
> I would suggest that we change the above sentence to:
> 
> When a RR reflects a route to a non-client, ...
> 
> I think a CLUSTER_ID needs to be added only when a route is leaving
> the cluster. 

No, it is needed to deal with mis-configurations within a cluster.
You can easily come with several senarios.

-- Enke

> 
> >    it must append the local CLUSTER_ID to
> >    the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it must create a new
> >    one. Using this attribute an RR can identify if the routing
> >    information is looped back to the same cluster due to mis-
> >    configuration. If the local CLUSTER_ID is found in the cluster-list,
> >    the advertisement received will be ignored.
>  
> Cheers
> Zheng
> --
> Zheng Wang
> http://www.bell-labs.com/user/zhwang

Date: Fri, 27 Nov 1998 18:37:52 -0500
From: Zheng Wang <[email-masked]>
Organization: Bell Labs
To: Enke Chen <[email-masked]>
CC: Rohit Dube <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt
Sender: [email-masked]

Enke Chen wrote:
 
> After checking the new version of the document, it ***has***
> indeed be corrected:
> 
>    When a RR reflects a route, 

I would suggest that we change the above sentence to:

When a RR reflects a route to a non-client, ...

I think a CLUSTER_ID needs to be added only when a route is leaving
the cluster. 

>    it must append the local CLUSTER_ID to
>    the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it must create a new
>    one. Using this attribute an RR can identify if the routing
>    information is looped back to the same cluster due to mis-
>    configuration. If the local CLUSTER_ID is found in the cluster-list,
>    the advertisement received will be ignored.
 
Cheers
Zheng
--
Zheng Wang
http://www.bell-labs.com/user/zhwang

To: Enke Chen <[email-masked]>
cc: Rohit Dube <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt 
Date: Wed, 25 Nov 1998 17:47:58 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Wed, 25 Nov 1998 14:02:55 -0800 [email-masked] writes:
=>Rohit,
=>After checking the new version of the document, it ***has***
=>indeed be corrected:
=>
=>   When a RR reflects a route, it must append the local CLUSTER_ID to
=>   the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it must create a new
=>   one. Using this attribute an RR can identify if the routing
=>   information is looped back to the same cluster due to mis-
=>   configuration. If the local CLUSTER_ID is found in the cluster-list,
=>   the advertisement received will be ignored.
=>
=>You were talking about rfc1966. I thought that you were talking about
=>this revision.

Ahh ok. Sorry for the confusion - I was indeed looking at RFC 1966 and didn't
see the update on this section.

--rohit.

To: Rohit Dube <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt 
Date: Wed, 25 Nov 1998 14:02:55 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Rohit,
After checking the new version of the document, it ***has***
indeed be corrected:

   When a RR reflects a route, it must append the local CLUSTER_ID to
   the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it must create a new
   one. Using this attribute an RR can identify if the routing
   information is looped back to the same cluster due to mis-
   configuration. If the local CLUSTER_ID is found in the cluster-list,
   the advertisement received will be ignored.

You were talking about rfc1966. I thought that you were talking about
this revision.

-- Enke

> Date:    Wed, 25 Nov 1998 13:55:29 -0800
> From:    Enke Chen <[email-masked]>
> To:      Rohit Dube <[email-masked]>
> CC:      [email-masked], [email-masked], [email-masked], enkechen

> Rohit,
> 
> > Date:    Wed, 25 Nov 1998 16:00:47 -0500
> > From:    Rohit Dube <[email-masked]>
> > To:      [email-masked]
> > CC:      [email-masked], [email-masked]
> 
> > On Wed, 25 Nov 1998 11:35:02 -0800 [email-masked] writes:
> > =>you can ftp the file draft-ietf-idr-route-reflect-v2-00.txt 
> > 
> > Since IDR is looking at an update to the Route Reflection RFC,
> > I would like to suggest that the wording in section of RFC 1966
> > 
> >    When a RR reflects a route from its Clients to a Non-Client peer, it
> >    must append the local CLUSTER_ID to the CLUSTER_LIST. If the
> >    CLUSTER_LIST is empty, it must create a new one. Using this attribute
> >    an RR can identify if the routing information is looped back to the
> >    same cluster due to mis-configuration. If the local CLUSTER_ID is
> >    found in the cluster-list, the advertisement will be ignored.
> > 
> > be changed to 
> > 
> >    When a RR reflects a route, it
> 
> This is correct. Thanks for catching it. I have made several similar
> revisions and this one slipped through. I will make the correction.
> 
> -- Enke
> 
> >    must append the local CLUSTER_ID to the CLUSTER_LIST. If the
> >    CLUSTER_LIST is empty, it must create a new one. Using this attribute
> >    an RR can identify if the routing information is looped back to the
> >    same cluster due to mis-configuration. If the local CLUSTER_ID is
> >    found in the cluster-list, the advertisement will be ignored.
> > 
> > 
> > The change here is an unconditional addition of a reflectors cluster-id to
> > the cluster-list whenever a route is reflected (instead of reflection only
> > from client to non-client). I can't see any obvious disadvantage of this 
> > (besides the use of a wee bit more memory and processing). The advantage is
 
> > that it makes tracking down and debugging of prefixes flowing inside an AS
> > using reflection much easier.
> > 
> > For example in the following diagram, rr1 and rr2 are reflectors in differe
nt
> > clusters. 
> > 
> > 	[rr1]------[rr2]
> >           |          |
> >           |          |
> >           |          |
> >          [r1]       [r2]
> > 
> > A prefix flowing up from r1 to rr1 and then to rr2 and r2 currently will 
> > contain only the cluster-id of rr1 in the cluster-list.
> > 
> > With the suggested change, it would have the exact cluster-path traversed -
> > cluster-id(rr1) and cluster-id(rr2).
> > 
> > If r2 doesn't understand reflection, no harm is done as the attribute in
> > question is optional. On the other hand if r2 understands reflection (even
> > if it not a reflector) we have the ability to see exactly how we learned 
> > this route.
> > 
> > --rohit.

To: Rohit Dube <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt 
Date: Wed, 25 Nov 1998 13:55:29 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Rohit,

> Date:    Wed, 25 Nov 1998 16:00:47 -0500
> From:    Rohit Dube <[email-masked]>
> To:      [email-masked]
> CC:      [email-masked], [email-masked]

> On Wed, 25 Nov 1998 11:35:02 -0800 [email-masked] writes:
> =>you can ftp the file draft-ietf-idr-route-reflect-v2-00.txt 
> 
> Since IDR is looking at an update to the Route Reflection RFC,
> I would like to suggest that the wording in section of RFC 1966
> 
>    When a RR reflects a route from its Clients to a Non-Client peer, it
>    must append the local CLUSTER_ID to the CLUSTER_LIST. If the
>    CLUSTER_LIST is empty, it must create a new one. Using this attribute
>    an RR can identify if the routing information is looped back to the
>    same cluster due to mis-configuration. If the local CLUSTER_ID is
>    found in the cluster-list, the advertisement will be ignored.
> 
> be changed to 
> 
>    When a RR reflects a route, it

This is correct. Thanks for catching it. I have made several similar
revisions and this one slipped through. I will make the correction.

-- Enke

>    must append the local CLUSTER_ID to the CLUSTER_LIST. If the
>    CLUSTER_LIST is empty, it must create a new one. Using this attribute
>    an RR can identify if the routing information is looped back to the
>    same cluster due to mis-configuration. If the local CLUSTER_ID is
>    found in the cluster-list, the advertisement will be ignored.
> 
> 
> The change here is an unconditional addition of a reflectors cluster-id to
> the cluster-list whenever a route is reflected (instead of reflection only
> from client to non-client). I can't see any obvious disadvantage of this 
> (besides the use of a wee bit more memory and processing). The advantage is 
> that it makes tracking down and debugging of prefixes flowing inside an AS
> using reflection much easier.
> 
> For example in the following diagram, rr1 and rr2 are reflectors in different
> clusters. 
> 
> 	[rr1]------[rr2]
>           |          |
>           |          |
>           |          |
>          [r1]       [r2]
> 
> A prefix flowing up from r1 to rr1 and then to rr2 and r2 currently will 
> contain only the cluster-id of rr1 in the cluster-list.
> 
> With the suggested change, it would have the exact cluster-path traversed -
> cluster-id(rr1) and cluster-id(rr2).
> 
> If r2 doesn't understand reflection, no harm is done as the attribute in
> question is optional. On the other hand if r2 understands reflection (even
> if it not a reflector) we have the ability to see exactly how we learned 
> this route.
> 
> --rohit.

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-route-reflect-v2-00.txt 
Date: Wed, 25 Nov 1998 16:00:47 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Wed, 25 Nov 1998 11:35:02 -0800 [email-masked] writes:
=>you can ftp the file draft-ietf-idr-route-reflect-v2-00.txt 

Since IDR is looking at an update to the Route Reflection RFC,
I would like to suggest that the wording in section of RFC 1966

   When a RR reflects a route from its Clients to a Non-Client peer, it
   must append the local CLUSTER_ID to the CLUSTER_LIST. If the
   CLUSTER_LIST is empty, it must create a new one. Using this attribute
   an RR can identify if the routing information is looped back to the
   same cluster due to mis-configuration. If the local CLUSTER_ID is
   found in the cluster-list, the advertisement will be ignored.

be changed to 

   When a RR reflects a route, it
   must append the local CLUSTER_ID to the CLUSTER_LIST. If the
   CLUSTER_LIST is empty, it must create a new one. Using this attribute
   an RR can identify if the routing information is looped back to the
   same cluster due to mis-configuration. If the local CLUSTER_ID is
   found in the cluster-list, the advertisement will be ignored.

The change here is an unconditional addition of a reflectors cluster-id to
the cluster-list whenever a route is reflected (instead of reflection only
from client to non-client). I can't see any obvious disadvantage of this 
(besides the use of a wee bit more memory and processing). The advantage is 
that it makes tracking down and debugging of prefixes flowing inside an AS
using reflection much easier.

For example in the following diagram, rr1 and rr2 are reflectors in different
clusters. 

	[rr1]------[rr2]
          |          |
          |          |
          |          |
         [r1]       [r2]

A prefix flowing up from r1 to rr1 and then to rr2 and r2 currently will 
contain only the cluster-id of rr1 in the cluster-list.

With the suggested change, it would have the exact cluster-path traversed -
cluster-id(rr1) and cluster-id(rr2).

If r2 doesn't understand reflection, no harm is done as the attribute in
question is optional. On the other hand if r2 understands reflection (even
if it not a reflector) we have the ability to see exactly how we learned 
this route.

--rohit.

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: draft-ietf-idr-route-reflect-v2-00.txt
Date: Wed, 25 Nov 1998 11:35:02 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
A revised route reflection document has been submitted 
as an Internet Draft. It may not got published on time
as the submission missed the deadline. In the meantime,
you can ftp the file draft-ietf-idr-route-reflect-v2-00.txt 
from ftp-eng.cisco.com:enkechen/

Your comments and feedback are welcome.
Thanks.

-- Enke

To: [email-masked]
Subject: meeting dates
Date: Sat, 14 Nov 1998 15:23:10 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

We have two slots:

	Thursday, December 10 at 1300-1500

	Friday, December 11 at 0900-1130

Yakov.

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: route selection and local(AS) routes
Date: Sat, 07 Nov 1998 06:27:08 PST
Sender: [email-masked]

Hi,
  Could you clarify how routes originated by the AS figure in
  the route selection process. Or does it matter if the implementation
  always gives precdence to local routes over any other route?

Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-dube-route-reflection-harmful-00.txt 
Date: Fri, 06 Nov 1998 09:43:29 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Thu, 5 Nov 1998 13:03:42 -0800 (PST) [email-masked] writes:
=>|  >This should certainly be fully documented, if only for truth in
=>|  >advertising.
=>|  
=>|  You mean, emphasized in RFC 1966?  Yup.
=>
=>
=>Yes, exactly.
=>
=>
=>|  >I believe that an appropriate way of addressing this comment would be a
=>|  >update of RFC 1966.
=>|  
=>|  What's the next step for doing that?
=>
=>
=>I believe that the authors should be given first shot at doing this update,
=>perhaps with a gentle nudge from the WG co-chairs.

Tony,

First, thanks for your comments. I'll go over them in detail.

About the next step - this is something I had discussed with the Co-author
(John) before we submitted the draft and we had hoped to take the draft 
(after appropriate discussion and ammendments) to an Informational RFC. 
Ofcourse, the actual decision is really up to the WG chairs.

--rohit.

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-dube-route-reflection-harmful-00.txt 
Date: Fri, 06 Nov 1998 06:33:47 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Tony,

> |  >I believe that an appropriate way of addressing this comment would be a
> |  >update of RFC 1966.
> |  
> |  What's the next step for doing that?
> 
> 
> I believe that the authors should be given first shot at doing this update,
> perhaps with a gentle nudge from the WG co-chairs.

I think this is an excellent idea. Your point about "a gentle nudge"
is well taken.

Yakov.

Date: Thu, 5 Nov 1998 13:03:42 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: draft-dube-route-reflection-harmful-00.txt
Sender: [email-masked]

|  That's a better characterization than ours, thank you.  Our guidelines 
|  (such as they were) were merely meant to indicate one class of 
|  configurations that are safe, we didn't mean to say that we had fully 
|  characterized all safe classes of configuration.  Do you believe that "the 
|  restriction is that clusters need to be concave" does this?

No, it's not sufficient.  It's a stronger characterization, but not a
requirement.  One might note that if all clusters make exactly the same
decision, there is no topology restriction at all.  So there is a spectrum
of answers depending on the particular flexibility that the RRs have in
computing routes.

I hypothesize (but no stronger ;-) that concavity is sufficient for
completely flexible route calculations.  Note that this is interesting
because concavity in practice means that you end up with clusters which map
pretty closely to confederations.

|  >This should certainly be fully documented, if only for truth in
|  >advertising.
|  
|  You mean, emphasized in RFC 1966?  Yup.

Yes, exactly.

|  >I believe that an appropriate way of addressing this comment would be a
|  >update of RFC 1966.
|  
|  What's the next step for doing that?

I believe that the authors should be given first shot at doing this update,
perhaps with a gentle nudge from the WG co-chairs.

Tony

Date: Thu, 5 Nov 1998 15:33:30 -0500
To: Tony Li <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: draft-dube-route-reflection-harmful-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:18 PM -0800 11/5/98, Tony Li wrote:
>As you note, there are route reflector configurations that are not tenable.
>This should have been noted.  However, your avoidance guidelines for this
>problem, if I understand them correctly, are overly restrictive.  In
>particular, in your example, you can see that the IBGP session between
>route reflectors is safe if the membership of R3 and R4 is reversed.  More
>generally, the restriction is that clusters need to be concave: that is,
>the IGP must never compute a path that exits a cluster and then returns to
>that same cluster.

That's a better characterization than ours, thank you.  Our guidelines 
(such as they were) were merely meant to indicate one class of 
configurations that are safe, we didn't mean to say that we had fully 
characterized all safe classes of configuration.  Do you believe that "the 
restriction is that clusters need to be concave" does this?

>Also, it probably should have been emphasized that route reflectors do not
>compute the same results as a full IBGP mesh.  I believe that this is and
>was widely known, and that there are many other opportunities to observe
>this in addition to scenarios similar to the one described in your draft.
>This should certainly be fully documented, if only for truth in
>advertising.

You mean, emphasized in RFC 1966?  Yup.

>My final comment is about the title of this draft.  While I'm well aware of
>the history of the genre that sparked this title, one of the implications
>of the title is the surface impression that you are trying to discourage
>others from employing route reflectors.  I don't believe that you actually
>hold that viewpoint, given the contents of section 7, so I think that this
>choice of title was somewhat unfortunate.

You're right.  Thanks for not saying "juvenile."  My fault.

>I believe that an appropriate way of addressing this comment would be a
>update of RFC 1966.

What's the next step for doing that?

Regards,

--John
--
John Scudder                        email:  [email-masked]
Internet Engineering Group, LLC     phone:  (734) 213-4939 x14
122 S. Main, Suite 280              fax:    (734) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com

Date: Thu, 5 Nov 1998 12:18:15 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: draft-dube-route-reflection-harmful-00.txt
Sender: [email-masked]

Rohit, John,

Thank you very much for your recent draft.  I believe that it points out
two important points that are not dealt with adequately in RFC 1966.

As you note, there are route reflector configurations that are not tenable.
This should have been noted.  However, your avoidance guidelines for this
problem, if I understand them correctly, are overly restrictive.  In
particular, in your example, you can see that the IBGP session between
route reflectors is safe if the membership of R3 and R4 is reversed.  More
generally, the restriction is that clusters need to be concave: that is,
the IGP must never compute a path that exits a cluster and then returns to
that same cluster.

Also, it probably should have been emphasized that route reflectors do not
compute the same results as a full IBGP mesh.  I believe that this is and
was widely known, and that there are many other opportunities to observe
this in addition to scenarios similar to the one described in your draft.
This should certainly be fully documented, if only for truth in
advertising.

My final comment is about the title of this draft.  While I'm well aware of
the history of the genre that sparked this title, one of the implications
of the title is the surface impression that you are trying to discourage
others from employing route reflectors.  I don't believe that you actually
hold that viewpoint, given the contents of section 7, so I think that this
choice of title was somewhat unfortunate.

I believe that an appropriate way of addressing this comment would be a
update of RFC 1966.

Regards,
Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: 4.8.3 draft-ietf-idr-route-damp-04
Date: Mon, 02 Nov 1998 16:42:04 PST
Sender: [email-masked]

Hi,
  Section 4.8.3 seems to imply :

  if the route is not suppressed (yet) *and*
       figure-of-merit < reuse 
        suppress the route
  
  I think the route should not be suppressed under this case.
  Pl. clarify this.
  (The condition route_not_suppressed *and* f-o-m < reuse will
   fall under else - or am i taking this too literally)

Thanks,
-Jaihari.

  

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com