Subject: Re: Comments on IDRPv2
From: Paul Traina <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: 30 Oct 1996 09:45:31 -0800

Tony,
Thanks for your comments.  Sorry to be slow getting back to you, but at the
moment I'm swamped.  I'll sit down with Yakov and try to hash some of these
things out.

Some quick notes from memory cells that haven't been touched in a year:

	It was never our intention for the BIS ID to be random, and
	if the managed object has been set, it should take to the managed
	object.  If it has been defaulted, then it's sufficient for it
	to be unique, pick any consistent way to set it (e.g. encoded
	domain name if available).

	The loss of the RI was deliberate.  Every IDRP implementor
	present at the meeting made a pitch for killing it because of
	the pains it caused them over the increased bandwidth utilization.
	I think (stale memory) withdrawn NRLI also contains a RIB tag
	which should handle the scope problem, but I'll look at it when
	I have a few free cycles.

	We'll try to clarify RIB/FIB tag usage.

the rest one of us will answer soon...
- - - - - - - - - - - - - - - - -

To: IETF-Announce:;
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rdc-config-01.txt
Date: Tue, 29 Oct 1996 10:47:02 -0500
Sender: [email-masked]

--NextPart

 A Revised 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     : Configuring IDRP Confederations                         
       Author(s) : R. Govindan
       Filename  : draft-ietf-idr-rdc-config-01.txt
       Pages     : 5
       Date      : 10/28/1996

In the Inter-Domain Routing Protocol (IDRP), all border routers (border 
intermediate systems (BISs) in ISO terminology) of a routing domain 
confederation (RDC) must be configured with the identity of all RDCs that 
overlap or enclose that RDC. This draft describes some minor modifications 
to IDRP specification that removes this requirement.                       

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-idr-rdc-config-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-rdc-config-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.a                
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-idr-rdc-config-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rdc-config-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-idr-rdc-config-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--
- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: Mon, 28 Oct 1996 18:15:10 -0500
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Comments on IDRPv2
Sender: [email-masked]

>>>>> "John" == John Scudder <[email-masked]> writes:

    John> Tony Whyman <[email-masked]> writes: [...]

    >> Generally, I know of no implementation difficulties with IDRPv1's
    >> Route Identifier. It's compact and efficient and avoids
    >> ambiguity. It should be preferred over the BGP-4 approach.

    John> I don't have time to respond to Tony's whole epistle at the
    John> moment, but I didn't want to let this comment go unremarked.
    John> Speaking from my experience working on Merit's IDRP
    John> implementation, I strongly disagree with the "no implementation
    John> difficulties" claim.  It was my sense that the Route Identifier
    John> was a big pain to code vis-a-vis withdraw-by- prefix.

In my experience, adding the route identifier support was an effort.
But I don't think the implementation cost is the real issue.
The real issue is how much extra resources in memory and processing
costs are required to keep track of exactly what nlri have 
been bundled in specific advertisements. 

Regards, Dave Jacobson
- - - - - - - - - - - - - - - - -

From: John Scudder <[email-masked]>
Subject: Re: Comments on IDRPv2
To: [email-masked]
Date: Fri, 25 Oct 1996 13:57:48 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Tony Whyman <[email-masked]> writes:
[...]
> 6. Page 27, Withdrawn Routes
[...]
> Generally, I know of no implementation difficulties with IDRPv1's Route 
> Identifier. It's compact and efficient and avoids ambiguity. It should be 
> preferred over the BGP-4 approach.

I don't have time to respond to Tony's whole epistle at the moment, but
I didn't want to let this comment go unremarked.  Speaking from my
experience working on Merit's IDRP implementation, I strongly disagree
with the "no implementation difficulties" claim.  It was my sense that
the Route Identifier was a big pain to code vis-a-vis withdraw-by-
prefix.

I'll try to follow up on this in more detail in the future.  I guess
Sue H. might also want to comment.

Regards,

--John
- - - - - - - - - - - - - - - - -

Date: Fri, 25 Oct 1996 15:42:42 EDT
Reply-To: [email-masked]
From: [email-masked] (Tony Whyman)
To: [email-masked]
Subject: Comments on IDRPv2
Sender: [email-masked]

Hi there,

I have recently woken up to work that's going on here on IDRPv2 and the 
continuing work on BGP-4 and have being going through the publically 
available documents. As a result I have a number of comments to make on IDRP 
v2, which are given below. I suspect that some of the things that I have 
noticed on IDRPv2 have already been discussed, and may I apologise in advance 
for inadvertantly covering old ground.

For those who don't remember or recognise my name, I did have some 
involvement in the development of IDRPv1 and am still actively involved in 
the implementation and deployment of IDRP. My original involvement with IDRP 
was under contract to the Eurocontrol Agency and that's where the continuing 
work has been done on IDRP - although these comments are more of a personal 
interest. Over the last couple of years we successfully interworked three 
implementations of IDRP: the Merit Code, the Retix/Vertel portable IDRP 
product and another implementation developed for Eurocontrol by ESG of 
Germany. This is in both the lab and pre-operational trials. We also have a 
simulation model looking, in particular, at route convergence in complex 
topologies with various policies. Right now, policy driven Route Aggregation 
and Route Information Reduction is being added to the Retix/Vertel code.

Hopefully, I can feed back some of the experienced gained here into IDRPv2. 
One thing I would say is that IDRPv1 provides a very good base from which to 
start. Implementation experience says that there are only a few defects in 
the text and the implementors were able to follow it without too much 
trouble.

Regards

Tony Whyman             McCallum Whyman Associates Ltd  Tel +44 1962 735580
                                                        FAX +44 1962 735581
                        Internet: [email-masked]
                        Compuserve: 100041,315

-----------------------------------------------------------
COMMENTS ON IDRPV2 - June 1996 draft

Please note that the comments are in no particular order of importance.

1. Page 18, 7.1

The fixed header layout is as the ISO text less the protocol identifier. Is 
there an intention to modify the presentation order into the more normal IETF 
32-bit word layout?

2. Page 21, Version

If the protocol is version 2 then prehaps this field should take the value 2, 
especially as it is set to one in IDRPv1.

3. Page 21, BIS Identifier

"The value of the BIS Identifier is determined on startup" - this could be 
mis-read as implying that _any_ of the BIS's IP Addresses could be used as 
the BIS Identifier and one is chosen at random on startup. This would not 
help the peer BISs authenticate it. The BIS Identifier should be a Managed 
Object Attribute value and I don't think there is any reason to even demand 
that it is an IP Address assigned to an interface. It could be an IPv6 
anycast address or just a unique IP address assigned as a name to the BIS. By 
the way, the text refers to a BIS Speaker rather than an IDRP Speaker.

4. Page 26, et al

The FIB tag field is defined here, while 6.7 defines a RIB tag. I think that 
they are one and the same. However, the two terms are both used later on in 
the text and there seems to be a need to get the term consistent.

5. Page 12, 6.7 RIB tag

I assume that the RIB tag replaces the RIB_Att and the concept of 
Distinguishing Path Attributes. It looks a very good idea that generalises 
the concept and appears to make it more flexible. At the moment, it seems to 
be a placeholder for future development and I think that there are a number 
of issues about its correct interpretation in this version and in ensuring 
that future development is not compromised:

a. What is the definition of the Null RIB tag? I can't find it in this 
document. I assume that it equates to the IDRPv1 empty set of DPAs and hence 
applies to the attributes defined in IDRPv2. 

b. Is the Null RIB Tag's value zero (e.g. in an UPDATE PDU)?

c. When does a new RIB tag have to be defined? Is it when one or more path 
attributes that pass QoS or Security information are defined and present in 
the route?

d. Who is responsible for assigning new Rib tag values? Are they globally 
unique, or are they of purely local significance? As new Rib Tags may well be 
defined by future versions on the standard, should a sub-range be reserved 
for standardised use, with the remainder available for local use?

6. Page 27, Withdrawn Routes

The BGP-4 notion of using the NLRI has been chosen here in preference to the 
IDRP use of a Route Identifier. There are two reasons why I think that this 
is wrong:

a. With IPv4, the address prefixes are never going to be that big 
individually and with BGP-4 this may not be such an issue. However, with IPv6 
(or even CLNP) the addresses are much bigger and I am concerned about the 
overhead that is implied here. As a side issue, I would also point to a 
concern I have about the way IPv6 has embedded IPv4 addresses as the 
rightmost 32-bits of the address. This will lead to a large number of long 
address prefixes from IPv4 domains for which there is almost no possibility 
of Route Information Reduction on Route Aggregation.

b. Ambiguity with overlapping routes. When an address prefix occurs in a 
Withdrawn Routes list that had previously been advertised in two overlapping 
routes, then there is an ambiguity as to which one is affected. In many 
cases, this may not be an issue. However, if a scope control attribute, such 
as the Communities attribute is present and differs between the two original 
routes, then the ambiguity is potentially more serious and may even lead to 
routing black holes.

One way out of this problem may be to demand that such a withdrawal was 
advertised together with a re-advertisement of the unaffected route. However, 
what if there were three overlapping routes and only one was affected?

Generally, I know of no implementation difficulties with IDRPv1's Route 
Identifier. It's compact and efficient and avoids ambiguity. It should be 
preferred over the BGP-4 approach.

7. Page 29, 7.3.1.2

I agree with changing the name of EXT_INFO, but I don't like INCOMPLETE_PATH 
as an alternative. EXT_INFO was a vague name and never readily understood by 
implementors in my experience. However, INCOMPLETE_PATH is also going to 
cause confusion. It could, for example, be mis-read as implying that the 
destination is unreachable, or that the incompleteness is in the middle of 
the route rather than at the source. I would suggest that something like 
ROUTE_SOURCE would be a more descriptive title and then enumerating the 
possible alternatives as its value i.e.:

Internal Systems MO (default)
Other Systems Management
Intra-domain/IGP
EGP
Other Inter-domain routing protocol

This has the advantage of being more descriptive and provides more 
information for local policies and, as long as absence implies the source is 
the Internal Systems MO, should not result additional usage.

8. Page 32, 7.3.1.5, 3rd line

"the IP Address of the BIS...". I think that this should be BIS Identifier.

Page 33, 7.3.1.10

The COMMUNITIES attribute is another new idea that I fully support. If this 
had been in IDRPv1 then we would be making use of it today. It appears to 
replace DIST_LIST_INCL and EXCL (which I agree with - the only real use was 
for INCL with one or more RDCs as its parameter. Scope control is almost 
always defined in an inclusive rather than exclusive sense and enumerating 
RDs, rather than RDCs is inflexible in comparison). However, it does open up 
many issues that need to be considered:

a. How many communities? It is clear from subsequent text that more than one 
community can be listed in the attribute. However, that is not completely 
clear from 7.3.1.10. The phrase "one or more" could be usefully added in 
respect of the tuple <community,scope>.

b. What are the aggregation rules for this attribute?

IDRPv2 appears to be silent on this issue, whilst RFC 1997 suggests that 
aggregation can be simply additive. Firstly, this is a scope control 
attribute and if you simply aggregate by merging the list of communities then 
by aggregating you potentially widen (or decrease) the scope of the 
distribution beyond that of the component routes. On its own this can give 
rise to unexpected and undesirable route propagation that varies according to 
the availability of other routes, and may even give rise to routing black 
holes (see below). At the very least, there needs to be some text stating 
that aggregation of the communities attribute is dependent upon the policy of 
the community and should only take place when explicitly permitted and does 
not give rise to a different distribution scope from that of the component 
routes.

c. Route Information Reduction for Communities

In order to facilitate the above, there may well be a case for replacing the 
different communities listed in component routes by a new community 
identifier. This would certainly ensure that the distribution scope is 
unaffected by the aggregation.

d. Route with identical NLRI and different Communities

We have been using (mis-using?) the IDRPv1 Security attribute for both 
controlling route distribution and route usage. In our case, we not only use 
the Security Attribute in the same sense as the Communities attribute to 
control distribution scope, but it also impacts upon the forwarding decision. 
I can see the same issue arising with ISPs, where the community may relate to 
interconnection agreements and cost sharing. In such cases, it will be 
important to control not only the distribution scope but also the traffic 
that follows each route, as transfer charges (and bottom line profit) may 
well depend upon traffic volumes.

It is therefore quite possible that an ISP may wish to filter traffic and 
send some packets over one route and others over another, even to the same 
destination. The decision as to which packets go where could depend upon the 
source address, a flow identifier or some other information in the packet 
header.

However, the important issue for IDRPv2, is that in this case, the choice 
between  two routes with identical NLRI, but different communities 
attributes, cannot be made by the phase 1/2 decision processes. All such 
routes have to go forward to the loc-RIB, where they are available for use in 
the FIB. They then must be aggregated by phase 3 before external 
distribution. A further complication exists with internal distribution, as 
such routes have to be aggregated by the phase 1 decision process prior to 
internal distribution to other BISs, as one will otherwise appear to replace 
the other.

In IDRPv1, the Security attribute had these properties, although not fully 
worked out. In IDRPv2, the Communities attribute has similar properties, but 
may perhaps be better identified as being properties of a class of IDRP 
attributes that control route distribution scope and route usage (call them 
Route Control attributes). Such attributes appear to have the following 
properties:

- aggregation of routes with Route Control attributes and dissimilar NLRI can 
only take place according to explicit policy rules with aggregation of the 
Route Control attribute values according to policy rather than an algorithm 
in the IDRP standard.

- routes with identical NLRI but different Route Control attribute values 
must all be selected by the phase 1 routing decision process and aggregated 
before internal distribution. In this case, the algorithm is algorithmic and 
typically by merging the attribute values.

- routes with identical NLRI but different Route Control attribute values 
must all be selected by the phase 2 routing decision process and entered into 
the appropriate loc-RIB. This may thus result with two or more routes to the 
same destination in the same loc-RIB but differing in the value of a Route 
Control attribute value.

- routes with identical NLRI but different Route Control attribute values, 
when selected for advertisement to a given BIS by the phase 3 route decision 
process, must be aggregated prior to advertisement.

- when routes with identical NLRI but different Route Control attribute 
values occur in the same Loc-RIB, local policy may choose which route is 
appropriate for which packets on a packet by packet basis.

We have also found that the procedures for use of the 
minRouteAdvertisementInterval are affected by such attributes. Specifically, 
when components of aggregated routes are withdrawn including those that are 
formed from routes with identical NLRI, then the 
minRouteAdvertisementInterval timer has to be overridden if routing black 
holes are not to exist, preventing the use of any other feasible routes that 
may exist downstream of the aggregation point.

e. Communities and RDCs

I have used RDCs for two distinct purposes. One is for scaleability i.e. 
defining boundaries at which typically Route Aggregation and Route 
Information Reduction take place, and the other is for controlling route 
distribution scope. In the former case, the RDCs are almost always nested, 
whilst in the latter, they are often overlapping.

RDCs are generally very simple except for the RD_Path rules where RDCs are 
overlapping. I remember several papers being exchanged on this issue for 
IDRPv1 and the result was a complex set of rules and is the one area where 
implementors have had serious difficulties in interpreting the standard.

I am thinking here that it may be possible to use the Community attribute as 
a way to remove the need for overlapping RDCs and hence to simplify the 
RD_Path rules considerably. I would propose that the RDC is restricted to 
nested relationships only and that the community is evolved to replace RDCs 
for overlapping relationships. I suppose that the issue here is how important 
do you think is having path information for the community.

9. Page 58, note 12

This note was original more of a nod in the direction of NLSP rather than 
anything else. In fact, if you don't reset the sequences numbers each time a 
connection is established (and demand that the other end does the same), and 
use a good enough digital signature over the whole BISPDU as the type 2 
authentication algorithm, then you do get a protection against replay.

10. Page 64, 8.9

This appears to repeat 8.7, except in less detail and potentially confusing 
type 1 and 3 authentication. At the very least a reference to 8.7 should be 
provided.

11. Page 69, second para (d)

The first sentence refers to a "non-transitive" attribute and then a 
"transitive" attribute in the 3rd line. I think that both references should 
be to non-transitve.

There then rises the question as to what is the difference between 
"propagating a non-transitive attribute" and destroying the received 
attribute and then creating a new copy of the same attribute type? This 
certainly has implications for not modifying the partial bit. In fact, would 
a BIS propagate a non-transitive attribute that it did not recognise? I would 
have said that the PARTIAL bit was always zero in a non-transitive attribute.

12. Page 83, 8.15, 3rd para

It is certainly important to recognise routing loops when they come in and 
reject them. However, we found in our simulation work, that it is also 
extremely important not to advertise routes that will be detected as routing 
loops on reception. This is because, in complex topologies, the lack of such 
a "look ahead" procedure will result in false routes that persist for the 
minRouteAdvertisementInterval, and hence slow convergence on route loss.

The reason is that if such a potentially looping route is queued for 
advertisement and is a change to an existing non-looping route, then it will 
be held for up to the minRouteAdvertisementInterval before it is advertised 
to an adjacent BIS. This prevents the adjacent BIS from recognising the route 
loss until the looping route is received. I have a paper available that 
discusses this in more detail if people are interested.

13. Page 85, 8.15.2 (c)

"specified in 95". The cross-referencing seems to have gone wrong here and in 
many other cases further on.

14. Page 86, 8.15.2.1

A BGP speaker has slipped into the second paragraph, and there are two IDRP 
Identifiers (whatever they may be) near the bottom of the page.

15. Page 96, last sentence of 8.16.2.1

It should really be explicitly stated that the UPDATE PDU used is one that re-
advertises the updated aggregated route, as the alternative is route flap.

16. Pahe 104, 8.13.3 (n)

NOTIFICATION PDU? (actually this is an error that was in 10747 and was never 
corrected)

17. Section 9

"This" rather than "The"

18. Section 10.

Is the sudden change to the first person plural necessary? Given the style of 
the rest of the document it gives a perhaps unintended emphasis.

19. Routing Policies

It is probably worth discussing in more detail, in IPRDv2, where and when 
Routing Policy is applied, and here are some ideas. 

Firstly, we have identified the following different points in IDRP where 
policy is applied:

- determining Route Preference
- choosing routes for advertisement/aggregation
- Route Information Reduction
- Constructing the FIB.

We have also introduced a taxonomy for some of the different types of rules 
involved. For example, in the second case, we have type 1 and type 2 rules. 

Every route selected by a given type 1 rule is aggregated to form a single 
route, whilst each route selected by a type 2 rule is a separately installed 
route in the associated Adj-RIB-out.

We have also introduced type 2a and 2b rules as a sub-division of type 2, 
where type 2a rules are simply static rules applying the same filter each 
time, whilst type 2b rules are conditional in their application upon dynamic 
information (e.g. the existance in the corresponding Adj-RIB-in of a selected 
route to a particular destination). This is useful in maintaining Route 
Servers and may be a way of maintaining bi-directional paths.

For Route Information Reduction, we have type A and type B rules. In the 
former case, if a given set of address prefixes is found in the NLRI then 
they are replaced by a single shorter address prefix specified by the rule. 
In the latter case, if _any_ members of a set of address prefixes are found 
in the NLRI, then they are replaced by a single shorter address prefix 
specified by the rule.

The type B rule appears to be very important for scaleability and information 
hiding. For example, it is natural for many Routing Domains to not advertise 
internal changes in availability, and the same may be true of many RDCs.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Wed, 23 Oct 96 14:58:24 -0400
From: "Acee Lindem" <[email-masked]>
Sender: [email-masked]

>>
>>    Am I mistaken or did the draft not get posted?  I saw the diffs but
>>    not a pointer to the new copy of the draft.
>>
>> ftp://ftp.juniper.net/pub/bgp/proposed-draft
>>
>
> This hostname wasn't resolvable via my hierarchy of name servers but I
> found it at the old name:
>
>  ftp://ftp.jnx.com/pub/bgp/proposed-draft

Opps - today ftp.juniper.net is resolvable. Sorry for the confusion. 

Acee 
- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Draft changes 
Date: Wed, 23 Oct 96 14:53:40 -0400
From: "Acee Lindem" <[email-masked]>
Sender: [email-masked]

Tony Li <[email-masked]>  writes:

> 
>    Am I mistaken or did the draft not get posted?  I saw the diffs but
>    not a pointer to the new copy of the draft.
> 
> ftp://ftp.juniper.net/pub/bgp/proposed-draft
> 

This hostname wasn't resolvable via my hierarchy of name servers but I
found it at the old name:  

  ftp://ftp.jnx.com/pub/bgp/proposed-draft 

Acee
- - - - - - - - - - - - - - - - -

Date: Wed, 23 Oct 1996 11:31:48 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Draft changes
Sender: [email-masked]

   Am I mistaken or did the draft not get posted?  I saw the diffs but
   not a pointer to the new copy of the draft.

ftp://ftp.juniper.net/pub/bgp/proposed-draft

Tony

- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Draft changes 
Date: Wed, 23 Oct 1996 14:17:45 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> Curtis,
> 
>    1) I though it was still discretionary becasue to be mandatory it must
>    be required for both IBGP and EBGP as stated in another diff chunk.  
> 
> Please define your reference to 'it'.  LOCAL_PREF?  Yes, this is a
> liberty.  I note that there was already a discussion about reclassification
> and additional definitions.  I didn't see good consensus.  I don't like my
> solution either.
> 
>    2) I really don't like
>    your pseudocode description of route selection and I'd rather see a
>    more consise description.  
> 
> Not mine.  Copied verbatim.  I don't like using pseudo-code in a spec,
> either (it's the semanticist in me), so I added a (hopefully equivalent)
> English description too.
> 
>    I think there was consensus on other changes so I'll go through the
>    mail and resend the changes so we can discuss them again, particularly
>    ones that got positive comments.
> 
> Thanks!
> 
>    > ! email: [email-masked]
> 
>    .net ?
> 
> This is correct.  juniper.com was taken.  In addition, because it was taken
> by someone who is also in the networking area (a systems integrator), it
> _appears_ that we'll be doing a name change anyway.  Stay tuned...  Film at
> 11.  ;-)
> 
> Tony

Tony,

Am I mistaken or did the draft not get posted?  I saw the diffs but
not a pointer to the new copy of the draft.

Curtis
- - - - - - - - - - - - - - - - -

Date: Mon, 21 Oct 1996 18:44:14 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Draft changes
Sender: [email-masked]

Curtis,

   1) I though it was still discretionary becasue to be mandatory it must
   be required for both IBGP and EBGP as stated in another diff chunk.  

Please define your reference to 'it'.  LOCAL_PREF?  Yes, this is a
liberty.  I note that there was already a discussion about reclassification
and additional definitions.  I didn't see good consensus.  I don't like my
solution either.

   2) I really don't like
   your pseudocode description of route selection and I'd rather see a
   more consise description.  

Not mine.  Copied verbatim.  I don't like using pseudo-code in a spec,
either (it's the semanticist in me), so I added a (hopefully equivalent)
English description too.

   I think there was consensus on other changes so I'll go through the
   mail and resend the changes so we can discuss them again, particularly
   ones that got positive comments.

Thanks!

   > ! email: [email-masked]

   .net ?

This is correct.  juniper.com was taken.  In addition, because it was taken
by someone who is also in the networking area (a systems integrator), it
_appears_ that we'll be doing a name change anyway.  Stay tuned...  Film at
11.  ;-)

Tony

- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Draft changes 
Date: Fri, 18 Oct 1996 20:17:32 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Hi Tony,

Just a quick scan of the diffs for now.  1) I though it was still
discretionary becasue to be mandatory it must be required for both
IBGP and EBGP as stated in another diff chunk.  2) I really don't like
your pseudocode description of route selection and I'd rather see a
more consise description.  I'll read the whole draft and see how it
fits together.  Here are some comments for now.

I think there was consensus on other changes so I'll go through the
mail and resend the changes so we can discuss them again, particularly
ones that got positive comments.

Curtis

> ***************
> *** 3223,3229 ****
>   3260 Jay St.
>   Santa Clara, CA 95051
>   (408) 327-1906
> ! email: [email-masked]
>   .fi
>   .sp
>   
> --- 3244,3250 ----
>   3260 Jay St.
>   Santa Clara, CA 95051
>   (408) 327-1906
> ! email: [email-masked]
>   .fi
>   .sp

.net ?

- - - - - - - - - - - - - - - - -

Date: Thu, 17 Oct 1996 13:51:09 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Subject: Draft proposal
Sender: [email-masked]

Folks,

First, I would like to apologize.  Due to the change in my employment
status, I was off the mailing list for most of the recent discussion.  ;-(

I _think_ I've caught up and have revised the draft accordingly.  I've also
made a number of editorial changes.  If I've left out Your Favorite Change,
it's because I didn't gauge the group consensus correctly.  Gentle,
private, abuse will probably suffice to remedy this.  ;-)

Diffs to the nroff source will follow in the next message.  Formatted text,
full nroff source, and the nroff diffs are available at
ftp://ftp.juniper.net/pub/bgp/

Thanks,
Tony
- - - - - - - - - - - - - - - - -

Date: Thu, 17 Oct 1996 13:51:39 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Subject: Draft changes
Sender: [email-masked]

*** bgp.ms	1996/10/17 04:42:49	1.1
--- bgp.ms	1996/10/17 07:19:29
***************
*** 51,57 ****
  .sp
  .in 0
  .ne 4
! 1. Acknowledgements
  .sp
  .in 3
  This document was originally published as RFC 1267 in October 1991,
--- 51,57 ----
  .sp
  .in 0
  .ne 4
! 1. Acknowledgments
  .sp
  .in 3
  This document was originally published as RFC 1267 in October 1991,
***************
*** 132,138 ****
   
  BGP runs over a reliable transport protocol.  This eliminates the
  need to implement explicit update fragmentation, retransmission,
! acknowledgement, and sequencing.  Any authentication scheme used by
  the transport protocol may be used in addition to BGP's own
  authentication mechanisms.  The error notification mechanism used in
  BGP assumes that the transport protocol supports a "graceful" close,
--- 132,138 ----
   
  BGP runs over a reliable transport protocol.  This eliminates the
  need to implement explicit update fragmentation, retransmission,
! acknowledgment, and sequencing.  Any authentication scheme used by
  the transport protocol may be used in addition to BGP's own
  authentication mechanisms.  The error notification mechanism used in
  BGP assumes that the transport protocol supports a "graceful" close,
***************
*** 207,213 ****
  with each other.  Alternately the interior routing protocol can
  pass BGP information among routers within an AS, taking care not to
  lose BGP attributes that will be needed by EBGP speakers if transit
! connectivity is being providided.  For the purpose of discussion,
  it is assumed that BGP information is passed within an AS using
  IBGP.  Care must be taken to ensure that the interior routers have
  all been updated with transit information before the EBGP speakers
--- 207,213 ----
  with each other.  Alternately the interior routing protocol can
  pass BGP information among routers within an AS, taking care not to
  lose BGP attributes that will be needed by EBGP speakers if transit
! connectivity is being provided.  For the purpose of discussion,
  it is assumed that BGP information is passed within an AS using
  IBGP.  Care must be taken to ensure that the interior routers have
  all been updated with transit information before the EBGP speakers
***************
*** 824,830 ****
  e) LOCAL_PREF (Type Code 5):
  .in 12
   
! LOCAL_PREF is a well-known discretionary attribute that is
  a four octet non-negative integer. It is used by a BGP speaker
  to inform other internal peers 
  of the originating speaker's degree of preference for an
--- 824,830 ----
  e) LOCAL_PREF (Type Code 5):
  .in 12
   
! LOCAL_PREF is a well-known mandatory attribute that is
  a four octet non-negative integer. It is used by a BGP speaker
  to inform other internal peers 
  of the originating speaker's degree of preference for an
***************
*** 1121,1127 ****
  The same attribute cannot appear more than once within the Path
  Attributes field of a particular UPDATE message.
  
! The manditory category refers to a field which must be present in
  both IBGP and EBGP exchanges.  Attributes classified as optional
  for the purpose of the protocol extension mechanism may be purely
  discretionary, or discretionary, required, or disallowed in certain
--- 1121,1127 ----
  The same attribute cannot appear more than once within the Path
  Attributes field of a particular UPDATE message.
  
! The mandatory category refers to a field which must be present in
  both IBGP and EBGP exchanges.  Attributes classified as optional
  for the purpose of the protocol extension mechanism may be purely
  discretionary, or discretionary, required, or disallowed in certain
***************
*** 1133,1139 ****
        NEXT_HOP           mandatory               mandatory
        MULTI_EXIT_DISC    discretionary           discretionary
        LOCAL_PREF         disallowed              required
!       ATOMIC_AGGREGATE   discretionary           discretionary
        AGGREGATOR         discretionary           discretionary

--- 1133,1139 ----
        NEXT_HOP           mandatory               mandatory
        MULTI_EXIT_DISC    discretionary           discretionary
        LOCAL_PREF         disallowed              required
!       ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
        AGGREGATOR         discretionary           discretionary

***************
*** 1240,1246 ****
  shares a common subnet with the NEXT_HOP address.  This is a second
  form of "third party" NEXT_HOP attribute.
  
! Normally the NEXT_HOP attribute is choosen such that the shortest
  available path will be taken.  A BGP speaker must be able to support
  disabling advertisement of third party NEXT_HOP attributes to handle
  imperfectly bridged media.
--- 1240,1246 ----
  shares a common subnet with the NEXT_HOP address.  This is a second
  form of "third party" NEXT_HOP attribute.
  
! Normally the NEXT_HOP attribute is chosen such that the shortest
  available path will be taken.  A BGP speaker must be able to support
  disabling advertisement of third party NEXT_HOP attributes to handle
  imperfectly bridged media.
***************
*** 1269,1277 ****
  is a four octet unsigned number which is called a metric.  All other
  factors being equal, the exit or entry point with lower metric
  should be preferred.  If received over external links, the MULTI_EXIT_DISC
! attribute may be propagated over internal links to other
  BGP speakers within the same AS.  The MULTI_EXIT_DISC attribute received
! from an internal peer shall never be propagated to external peers.
   
  .sp
  .in 0
--- 1269,1288 ----
  is a four octet unsigned number which is called a metric.  All other
  factors being equal, the exit or entry point with lower metric
  should be preferred.  If received over external links, the MULTI_EXIT_DISC
! attribute MAY be propagated over internal links to other
  BGP speakers within the same AS.  The MULTI_EXIT_DISC attribute received
! from a neighboring AS MUST NOT be propagated to other neighboring ASs.
!  
! A BGP speaker MUST IMPLEMENT a mechanism based on local configuration which
! allows the MULTI_EXIT_DISC attribute to be removed from a route.  This MAY
! be done either prior to or after determining the degree of preference of
! the route and performing route selection (decision process phases 1 and 2).
! 
! An implementation MAY also (based on local configuration) alter the
! value of the MULTI_EXIT_DISC attribute received over an external link.
! If it does so, it shall do so prior to determining the degree of
! preference of the route and performing route selection (decision
! process phases 1 and 2).
  
  .sp
  .in 0
***************
*** 1280,1297 ****
  .sp
  .in 3
   
! LOCAL_PREF is a well-known discretionary attribute that shall be
  included in all UPDATE messages that a given BGP speaker sends to the
  other internal peers. A BGP
! speaker shall calculate the degree of preference for each external
  route and include the degree of preference when advertising a route
! to its internal peers. The higher degree of preference should be
  preferred. A BGP speaker shall use the degree of preference learned
  via LOCAL_PREF in its decision process (see section 9.1.1).
   
! A BGP speaker shall not include this attribute in UPDATE messages that
  it sends to external peers.  If it is contained in an UPDATE message
! that is received from an external peer, then this attribute shall be
  ignored by the receiving speaker.
   
  .sp
--- 1291,1308 ----
  .sp
  .in 3
   
! LOCAL_PREF is a well-known mandatory attribute that SHALL be
  included in all UPDATE messages that a given BGP speaker sends to the
  other internal peers. A BGP
! speaker SHALL calculate the degree of preference for each external
  route and include the degree of preference when advertising a route
! to its internal peers. The higher degree of preference MUST be
  preferred. A BGP speaker shall use the degree of preference learned
  via LOCAL_PREF in its decision process (see section 9.1.1).
   
! A BGP speaker MUST NOT include this attribute in UPDATE messages that
  it sends to external peers.  If it is contained in an UPDATE message
! that is received from an external peer, then this attribute MUST be
  ignored by the receiving speaker.
   
  .sp
***************
*** 1304,1316 ****
  ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
  speaker, when presented with a set of overlapping routes from one of
  its peers (see 9.1.4), selects the less specific route without
! selecting the more specific one, then the local system shall attach
  the ATOMIC_AGGREGATE attribute to the route when propagating it to
  other BGP speakers (if that attribute is not already present in the
  received less specific route). A BGP speaker that receives a route
! with the ATOMIC_AGGREGATE attribute shall not remove the attribute
  from the route when propagating it to other speakers. A BGP speaker
! that receives a route with the ATOMIC_AGGREGATE attribute shall not
  make any NLRI of that route more specific (as defined in 9.1.4) when
  advertising this route to other BGP speakers.  A BGP speaker that
  receives a route with the ATOMIC_AGGREGATE attribute needs to be
--- 1315,1327 ----
  ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
  speaker, when presented with a set of overlapping routes from one of
  its peers (see 9.1.4), selects the less specific route without
! selecting the more specific one, then the local system MUST attach
  the ATOMIC_AGGREGATE attribute to the route when propagating it to
  other BGP speakers (if that attribute is not already present in the
  received less specific route). A BGP speaker that receives a route
! with the ATOMIC_AGGREGATE attribute MUST NOT remove the attribute
  from the route when propagating it to other speakers. A BGP speaker
! that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT
  make any NLRI of that route more specific (as defined in 9.1.4) when
  advertising this route to other BGP speakers.  A BGP speaker that
  receives a route with the ATOMIC_AGGREGATE attribute needs to be
***************
*** 2122,2160 ****
  .sp
  .in 3
   
! In its Adj-RIBs-In a BGP speaker may have several routes to the
! same destination that have the same degree of preference. The local
! speaker can select only one of these routes for inclusion in the
! associated Loc-RIB. The local speaker considers all equally preferable
! routes, both those received from internal peers, and those received from
! external peers.
   
  The following tie-breaking procedure assumes that for each candidate
  route all the BGP speakers within an autonomous system can ascertain the
  cost of a path (interior distance) to the address depicted by the
! NEXT_HOP attribute of the route.  Ties shall be broken according to the
! following algorithm:
   
! .in 6
! a) If the local system is configured to take into account MULTI_EXIT_DISC,
! and the candidate routes differ in their MULTI_EXIT_DISC attribute, select
! the route that has the lowest value of the MULTI_EXIT_DISC attribute.
! A route with MULTI_EXIT_DISC shall be preferred to a route without
! MULTI_EXIT_DIST.
   
! b) Otherwise, select the route that has the lowest cost (interior distance)
! to the entity depicted by the NEXT_HOP attribute of the route.
! If there are several routes with the same cost, then the tie-breaking
! shall be broken as follows:
   
! .in 9
! - if at least one of the candidate routes was advertised by the external peer,
! select the route that was advertised by the
! external peer whose BGP Identifier has
! the lowest value among all other external peers;
   
! - otherwise, select the route that was advertised by the BGP speaker
! whose BGP Identifier has the lowest value.
   
  .sp
  .in 0
--- 2133,2211 ----
  .sp
  .in 3
   
! In its Adj-RIBs-In a BGP speaker may have several routes to the same
! destination that have the same degree of preference. The local speaker can
! select only one of these routes for inclusion in the associated
! Loc-RIB. The local speaker considers all routes with the same degrees of
! preference, both those received from internal peers, and those received
! from external peers.
  
  The following tie-breaking procedure assumes that for each candidate
  route all the BGP speakers within an autonomous system can ascertain the
  cost of a path (interior distance) to the address depicted by the
! NEXT_HOP attribute of the route.
   
! The tie-breaking algorithm begins by considering all equally preferable
! routes and then selects routes to be removed from consideration.  The
! algorithm terminates as soon as only one route remains in consideration.
! The criteria must be applied in the order specified.
! 
! Several of the criteria are described using pseudo-code.  Note that
! the pseudo-code shown was chosen for clarity, not efficiency.  It
! is not intended to specify any particular implementation.  BGP
! implementations MAY use any algorithm which produces the same
! results as those described here.
! 
! .in 6
! a) Remove from consideration routes with less-preferred MULTI_EXIT_DISC
! attributes.  MULTI_EXIT_DISC is only comparable between routes learned from
! the same neighboring AS.  Routes which do not have the MULTI_EXIT_DISC
! attribute are considered to have the highest possible MULTI_EXIT_DISC
! value.
  
! This is also described in the following procedure:
  
! .nf
!       for m = all routes still under consideration
!           for n = all routes still under consideration
!               if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
!                   remove route m from consideration
! .fi
! 
! In the pseudo-code above, MED(n) is a function which returns
! the value of route n's MULTI_EXIT_DISC attribute.  If route n
! has no MULTI_EXIT_DISC attribute, the function returns the
! highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.
! 
! Similarly, neighborAS(n) is a function which returns the
! neighbor AS from which the route was received.
! 
! b) Remove from consideration any routes with less-preferred interior cost.
! The interior cost of a route is determined by calculating the metric to the
! next hop for the route using the interior routing protocol(s).  If the next
! hop for a route is reachable, but no cost can be determined, then this step
! should be should be skipped (equivalently, consider all routes to have
! equal costs).
! 
! This is also described in the following procedure.  
! 
! .nf
!       for m = all routes still under consideration
!           for n = all routes in still under consideration
!               if (cost(n) is better than cost(m))
!                   remove m from consideration
! .fi
! 
! In the pseudo-code above, cost(n) is a function which returns the cost of
! the path (interior distance) to the address given in the NEXT_HOP attribute
! of the route.
! 
! c) If at least one of the candidate routes was received from an external
! peer in a neighboring autonomous system, remove from consideration all
! routes which were received from internal peers.
  
! d) Remove from consideration all routes other than the route that was
! advertised by the BGP speaker whose BGP Identifier has the lowest value.
  
  .sp
  .in 0
***************
*** 2248,2277 ****
  described by the overlap will still be reachable using the less specific
  route.
   
! If a BGP speaker receives overlapping routes, the Decision Process shall
! take into account the semantics of the overlapping routes. In particular,
! if a BGP speaker accepts the less specific route while rejecting the
! more specific route from the same peer, then the destinations
! represented by the overlap may not forward along the ASs listed in
! the AS_PATH attribute of that route. Therefore, a BGP speaker has
! the following choices:
   
! .in 6
! a)   Install both the less and the more specific routes
!  
! b)   Install the more specific route only
!  
! c)   Install the non-overlapping part of the less specific
!            route only (that implies de-aggregation)
!  
! d)   Aggregate the two routes and install the aggregated route
!  
! e)   Install the less specific route only
!  
! f)   Install neither route
!  
! .in 3
! If a BGP speaker chooses e), then it shall add ATOMIC_AGGREGATE
  attribute to the route. A route that carries ATOMIC_AGGREGATE
  attribute can not be de-aggregated. That is, the NLRI of this route
  can not be made more specific.  Forwarding along
--- 2299,2311 ----
  described by the overlap will still be reachable using the less specific
  route.
   
! If a BGP speaker receives overlapping routes, the Decision Process MUST
! consider both routes based on the configured acceptance policy.  If both a
! less and a more specific route are accepted, then the Decision Process MUST
! either install both the less and the more specific routes or it MUST
! aggregate the two routes and install the aggregated route.
  
! If a BGP speaker chooses to aggregate, then it MUST add ATOMIC_AGGREGATE
  attribute to the route. A route that carries ATOMIC_AGGREGATE
  attribute can not be de-aggregated. That is, the NLRI of this route
  can not be made more specific.  Forwarding along
***************
*** 2316,2338 ****
  message to other internal peers.
   
  When a BGP speaker receives a new route from an external peer,
! it shall advertise that route to
  all other internal peers by means of an UPDATE
! message if any of the following conditions occur:
!  
! .in 6
! 1) the degree of preference assigned to the newly received route
! by the local BGP speaker is higher than the degree of
! preference that the local speaker has assigned to other
! routes that have been received from external peers, or
!  
! 2) there are no other routes that have been received from 
! external peers, or
!  
! 3) the newly received route is selected as a result of breaking
! a tie between several routes which have the highest degree
! of preference, and the same destination (the tie-breaking
! procedure is specified in 9.2.1.1).
   
  .in 3
  When a BGP speaker receives an UPDATE message with a non-empty
--- 2350,2359 ----
  message to other internal peers.
   
  When a BGP speaker receives a new route from an external peer,
! it MUST advertise that route to
  all other internal peers by means of an UPDATE
! message if this routes has been installed in its Loc-RIB according to the
! route selection rules in 9.1.2.
  
  .in 3
  When a BGP speaker receives an UPDATE message with a non-empty
***************
*** 3046,3052 ****
   
  To avoid excessive route flapping a BGP speaker which needs to
  withdraw a destination and send an update about a more specific
! or less specific route shall combine them into the same UPDATE
  message.
   
  .sp
--- 3067,3073 ----
   
  To avoid excessive route flapping a BGP speaker which needs to
  withdraw a destination and send an update about a more specific
! or less specific route SHOULD combine them into the same UPDATE
  message.
   
  .sp
***************
*** 3223,3229 ****
  3260 Jay St.
  Santa Clara, CA 95051
  (408) 327-1906
! email: [email-masked]
  .fi
  .sp
  
--- 3244,3250 ----
  3260 Jay St.
  Santa Clara, CA 95051
  (408) 327-1906
! email: [email-masked]
  .fi
  .sp
  
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: IDR WG agenda
Date: Mon, 14 Oct 96 14:51:59 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As we're approaching the next IETF, I'd like to solicit your suggestions
for the discussion items for the WG meeting. Please try to do this
within the next couple of weeks.

Thanks in advance.

Yakov.
- - - - - - - - - - - - - - - - -

To: [email-masked]
cc: [email-masked] (John G. Scudder), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Intra/Inter - was Inet-II 
Date: Mon, 14 Oct 1996 13:52:14 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] writes:
> > 
> > >>BGP heir, has the same sets of problems.
> > >
> > Lacking another suggestion, at least an enumeration of specific problems
> > would be quite constructive.  (That is, I think that vague assertions are
> > not especially constructive.)
> > 
> > Perhaps Bill would like to send his specific critiques to the IDR mailing l
> ist.
> > 
> > Regards,
> > 
> > John Scudder                        email:  [email-masked]
> 
> 
> 	ftp://www.isi.edu/div7/ra/Publications/bgp_osc.ps.gz
> 
> 	is a good start.  And I think that the IDR folks have
> 
> 	been made aware of the issues.  I've seen them discussed
> 
> 	briefly on that list.
> 
> 
> -- 
> --bill

Bill,

The URL is ftp://www.isi.edu/ra/Publications/bgp_osc.ps.gz

It seems to me that this is a matter of implementation and somewhat
irresponsible administration of networks.  If a routing protocol
supports dynamic routing information, what can be done to prevent an
irresponsible end network from injecting "overly dynamic" junk?

It seems to me two things could be done:

  aggregate the irresponsible weenies into shorter prefixes that
  should remain more stable

  provide a damping mechanism that ignores a route if it remains
  unstable for a while

Any other suggestions would be most welcome.  I've moved this to IDR.

Curtis
- - - - - - - - - - - - - - - - -