Subject: Re: AS_SETs
From: Tony Li <[email-masked]>
To: [email-masked] (Douglas Jardine)
Cc: [email-masked]
Date: 29 Jul 1997 21:30:28 -0700

[email-masked] (Douglas Jardine) writes:

> I was going thru the latest BGP-4 draft and came across the following
> paragraph (page 46, Section 9.2.4.1)
> 
>   An AS_SET implies that the destinations listed in the NLRI can be
>   reached through paths that traverse at least some of the
>   constituent autonomous systems. AS_SETs provide sufficient
>   information to avoid routing information looping; however their
>   use may prune potentially feasible paths, since such paths are no
>   longer listed individually as in the form of AS_SEQUENCEs.  In
>   practice this is not likely to be a problem, since once an IP
>   packet arrives at the edge of a group of autonomous systems, the
>   BGP speaker at that point is likely to have more detailed path
>   information and can distinguish individual paths to destinations.
>   ^^^^^^^^^^^
> My question is on the 'detailed information' which the BGP speaker may 
> use to find better paths to the destination - where does this 
> information
> come from? Isn't it true that if all bgp speakers use AS_SETs instead
> of sequences, then no such detailed information would exist? Am I 
> missing something?

Presumably the AS_SET is formed when aggregating a number of NLRI into a
shorter prefix.  The longer prefixes are learned via BGP and suppressed at
the point of aggregation.  Thus, when the packet reaches the aggregation
point, it either matches a longer prefix or is blackholed.

Tony

From: "Douglas Jardine" <[email-masked]>
To: [email-masked]
Subject: AS_SETs
Date: Tue, 29 Jul 1997 18:37:01 PDT
Sender: [email-masked]

Hi,

I was going thru the latest BGP-4 draft and came across the following
paragraph (page 46, Section 9.2.4.1)

  An AS_SET implies that the destinations listed in the NLRI can be
  reached through paths that traverse at least some of the
  constituent autonomous systems. AS_SETs provide sufficient
  information to avoid routing information looping; however their
  use may prune potentially feasible paths, since such paths are no
  longer listed individually as in the form of AS_SEQUENCEs.  In
  practice this is not likely to be a problem, since once an IP
  packet arrives at the edge of a group of autonomous systems, the
  BGP speaker at that point is likely to have more detailed path
  information and can distinguish individual paths to destinations.
  ^^^^^^^^^^^
My question is on the 'detailed information' which the BGP speaker may 
use to find better paths to the destination - where does this 
information
come from? Isn't it true that if all bgp speakers use AS_SETs instead
of sequences, then no such detailed information would exist? Am I 
missing something?

TIA.
-dj

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

From: [email-masked]
Date: Tue, 22 Jul 1997 23:09:52 -0400 (EDT)
To: [email-masked]
Subject: Meeting agenda
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The IDR Working group will have two sessions 
at the 39th IETF in Munich.  The sessions will
be on

Date:     time             Subject ma 
------------------------------------
Monday   9:30am - 11:30am  IPv4 based topics
8/11
 
Tuesday  9:30am - 11:30am  IPv6 seesion     
8/12

The Agenda for Monday 8/11 on IPv6 based topics
is:

	BGP-4++ 
        multicast policy routing
	capability negotation in bgp-4

The Tuesday Meeting is an IDR meeting to focus
on IPv6 issues:

	Status report on: bgp-4++ work for IPv6 
	IDRPv6 - revised specification
 	Call for Additional Specifications
		for IPv6 for Inter-Domain Routing

Yakov will be handling the Monday session, and I will
be handling the IPv6 session.    Please let us know
if there are additional items for the agenda.

Susan Hares

Date: Tue, 22 Jul 1997 16:11:26 -0400
From: Nirav_Shah <[email-masked]>
Organization: NetEdge Systems Inc.
To: [email-masked]
Subject: Interpretation of timer jitter criteria in BGP-4 RFC 1771 - Repost
Sender: [email-masked]

Following is a passage from section 9.2.3.3 of RFC 1771:

> The amount of jitter to be introduced shall be determined by multiplying
> the base value of the appropriate timer by a random factor which is
> uniformly distributed in the range from 0.75 to 1.0.

Assume that the nominal or base value of a timer is T.
One interpretation of the passage quote above would be that instead of
firing a timer at its nominal value, you would fire it at anywhere from
75% to 100% of its nominal value, i.e. from 0.75T to T.
This would be jitter in the range of -25% to 0.
Using jitter only in the negative range would cause drift over a period
of time.

This is quite different from another interpretation which would
introduce jitter in the range of -25% to +25%, i.e. timer value can
range from
0.75T to 1.25T.  In this interpretation, there would not be a drift over
time.

My question is, what interpretation was intended in RFC 1771?

Thanks.

-- 
Nirav Shah                   E-Mail: [email-masked]     
NetEdge Systems, Inc.        Voice:  508-670-7309
Billerica, Massachusetts     Web:    http://www.netedge.com

To: [email-masked] (BHAVESH R PATHAK)
cc: [email-masked]
Subject: Re: AGGREGATOR's use
From: Tony Li <[email-masked]>
Date: 22 Jul 1997 11:12:07 -0700
Lines: 28
Sender: [email-masked]

[email-masked] (BHAVESH R PATHAK) writes:

> 1.
>   RFC1771 says that if a BGP speaker aggregates a route, he has to set a 
>   ATOMIC_AGGREGATOR  attribute and set a AGGREGATOR (this is otional).
>   I am not able to undestand why "AGGREGATOR" attribute is required? 
>   In the rfc1771 there is no mention about how the receiver of AGGREGATOR
>   attribute is suppose to use it.

The primary use for the aggregator attribute is debugging.  Making it human
readable is the logical thing to do with it.

> 2.
>   If BGP gateway has three interfaces with IP address as IP1, IP2, IP3.
>   And BGP speaker is talking to three external ASs, i.e. AS1, AS2, AS3.
> 
>   BGP speaker is using IP1 as local IP address for taking to AS1, IP2 as
>   local IP address for talking to AS2, and IP3 as local IP address
>   for talking to AS3.
>  
>       If above BGP speaker aggregates a roure what address should be
>   used for generation of the AGGREGATOR attribute?

Doesn't really matter.

Tony

From: Andrew Partan <[email-masked]>
Subject: Re: AGGREGATOR's use
To: [email-masked] (BHAVESH R PATHAK)
Date: Tue, 22 Jul 1997 13:45:50 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

>   In the rfc1771 there is no mention about how the receiver of AGGREGATOR
>   attribute is suppose to use it.

It is for use by us network operators track down problems.

>       If above BGP speaker aggregates a roure what address should be
>   used for generation of the AGGREGATOR attribute?

Pick one.
	[email-masked] (Andrew Partan)

From: [email-masked] (BHAVESH R PATHAK)
Subject: AGGREGATOR's use
To: [email-masked]
Date: Tue, 22 Jul 1997 16:11:17 -0530 (IST)
Sender: [email-masked]

Hi all,

  I have two questions regarding AGGREGATOR attribute, mentioned in rfc1771.

1.
  RFC1771 says that if a BGP speaker aggregates a route, he has to set a 
  ATOMIC_AGGREGATOR  attribute and set a AGGREGATOR (this is otional).
  I am not able to undestand why "AGGREGATOR" attribute is required? 
  In the rfc1771 there is no mention about how the receiver of AGGREGATOR
  attribute is suppose to use it.

2.
  If BGP gateway has three interfaces with IP address as IP1, IP2, IP3.
  And BGP speaker is talking to three external ASs, i.e. AS1, AS2, AS3.

  BGP speaker is using IP1 as local IP address for taking to AS1, IP2 as
  local IP address for talking to AS2, and IP3 as local IP address
  for talking to AS3.
 
      If above BGP speaker aggregates a roure what address should be
  used for generation of the AGGREGATOR attribute?

with regards,
bhavesh
[email-masked]

To: "John W. Stewart III" <[email-masked]>
Cc: "Timothy O'Connor" <[email-masked]>, [email-masked]
Subject: Re: checking for empty AS_PATH 
Date: Fri, 18 Jul 97 14:16:58 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> are you assuming that the presence of a MP_REACH_NLRI
> attribute means that NLRI is present?  because if you
> mean to ignore the path attributes when the "standard"
> NLRI field is empty, then you could end up dropping
> legitimate multi-protocol NLRI on the floor
> 
> it's well possible that i'm being overly zealous in my
> interpretation of this thread, but given the novel use
> of attributes to carry NLRI, we've got to make sure
> that the base spec doesn't end up suggesting a way to
> implement that precludes them...

For a BGP speaker that supports multiprotocol extensions
the presence of a MP_REACH_NLRI attribute means that NLRI
is present.

Yakov.

To: Yakov Rekhter <[email-masked]>
Cc: "Timothy O'Connor" <[email-masked]>, [email-masked]
Subject: Re: checking for empty AS_PATH 
From: "John W. Stewart III" <[email-masked]>
Date: Fri, 18 Jul 1997 17:07:21 -0400
Sender: [email-masked]

are you assuming that the presence of a MP_REACH_NLRI
attribute means that NLRI is present?  because if you
mean to ignore the path attributes when the "standard"
NLRI field is empty, then you could end up dropping
legitimate multi-protocol NLRI on the floor

it's well possible that i'm being overly zealous in my
interpretation of this thread, but given the novel use
of attributes to carry NLRI, we've got to make sure
that the base spec doesn't end up suggesting a way to
implement that precludes them...

/jws

 > Tim,
 > 
 > > > we should probably make the check even stronger by checking
 > > > whether the most recent AS in the AS_PATH is the same as the
 > > > AS of the external peer. 
 > > 
 > > Any opinion on the case of whether a non-zero AS path is allowed
 > > in an UPDATE containing only unreachable routes? Should the spec
 > > say that the contents of the Path is ignored in this case, or
 > > should it say that there must be no Path information at all?
 > 
 > I think that saying that when an UPDATE contains only unreachable
 > routes the contents of the Path message shall be ignored is
 > a fine idea.
 > 
 > Yakov.

To: "Timothy O'Connor" <[email-masked]>
Cc: [email-masked]
Subject: Re: checking for empty AS_PATH 
Date: Fri, 18 Jul 97 13:06:37 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Tim,

> > we should probably make the check even stronger by checking
> > whether the most recent AS in the AS_PATH is the same as the
> > AS of the external peer. 
> 
> Any opinion on the case of whether a non-zero AS path is allowed
> in an UPDATE containing only unreachable routes? Should the spec
> say that the contents of the Path is ignored in this case, or
> should it say that there must be no Path information at all?

I think that saying that when an UPDATE contains only unreachable
routes the contents of the Path message shall be ignored is
a fine idea.

Yakov.

To: [email-masked]
Subject: re: checking for empty AS_PATH
Date: Fri, 18 Jul 97 15:50:37 -0400
From: "Timothy O'Connor" <[email-masked]>
Sender: [email-masked]

Yakov wrote

> we should probably make the check even stronger by checking
> whether the most recent AS in the AS_PATH is the same as the
> AS of the external peer. 

Any opinion on the case of whether a non-zero AS path is allowed
in an UPDATE containing only unreachable routes? Should the spec
say that the contents of the Path is ignored in this case, or
should it say that there must be no Path information at all?

This actually showed up as a bug between BBN routers and another
router. We were sending a length-1 AS Path containing AS "0" and
the other router rejected the Path information even though there
were no reachable NLRI in the UPDATE. We originally coded it this
way for compatibility with some older routers that always expected
a non-zero AS Path length! You can't win.

Tim O'Connor <[email-masked]>
BBN Systems & Technologies
Cambridge, Massachusetts

From: "John G. Scudder" <[email-masked]>
Subject: Re: checking for empty AS_PATH
To: [email-masked] (Scott W Brim)
Date: Fri, 18 Jul 1997 15:37:54 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Scott W Brim writes:
> Alternatively -- or in addition, actually -- in the AS_PATH definition,
> have it be "one or more" AS path segments, not just "a sequence".

This won't work -- empty AS_PATHs are commonly (and correctly) sent
around in IBGP.

BTW, the proposed change is fine with me.

Regards,

--John

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

Date: Fri, 18 Jul 1997 15:25:59 -0400
To: Yakov Rekhter <[email-masked]>
From: Scott W Brim <[email-masked]>
Subject: Re: checking for empty AS_PATH
Cc: [email-masked]
Sender: [email-masked]

At 11:24 7/18/97 PDT, Yakov Rekhter wrote:
>   If an UPDATE was received from an external peer, and the UPDATE
>   contains non-empty NLRI, the local system checks whether the
>   AS_PATH attribute is empty. If that is the case, then the Error
>   Subcode is set to Malformed AS_PATH.

Alternatively -- or in addition, actually -- in the AS_PATH definition,
have it be "one or more" AS path segments, not just "a sequence".

...Scott

--
Scott Brim, Newbridge Networks Inc.	tel: +1.607.273.5472
<[email-masked]>		fax: +1.607.273.5485

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: checking for empty AS_PATH 
From: "John W. Stewart III" <[email-masked]>
Date: Fri, 18 Jul 1997 15:05:52 -0400
Sender: [email-masked]

your suggested change sounds fine to me

 > P.S. In fact, we should probably make the check even stronger by checking
 > whether the most recent AS in the AS_PATH is the same as the AS of the
 > external peer. 

this requires a particular way to implement "external route
servers" (i.e., that the route server's AS *must* appear in
the AS path).  while i don't really care how it's done, i
don't remember if the IDR group has ever explicitly talked
about this particular protocol detail and its impact on the
operation of route servers

/jws

To: [email-masked]
Subject: capability negotiation with BGP
Date: Fri, 18 Jul 97 11:39:26 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

fyi
------- Forwarded Message

To: [email-masked]
Sender: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-chandra-bgp4-cap-neg-00.txt
Date: Fri, 18 Jul 1997 14:14:52 -0400

- --NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.

       Title     : Capabilities Negotiation with BGP-4
       Author(s) : R. Chandra, J. Scudder
       Filename  : draft-chandra-bgp4-cap-neg-00.txt
       Pages     : 4
       Date      : 07/17/1997

Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN
message with one or more unrecognized Optional Parameters, the speaker must
terminate BGP peering. This complicates introduction of new capabilities in
BGP.                                                       This document
defines new Optional Parameter, called Capabilities, that is expected to
facilitate introduction of new capabilities in BGP by providing graceful
capability negotiation.                                 The proposed
parameter is backward compatible - a router that supports the parameter can
maintain BGP peering with a router that doesn't support the parameter.

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-chandra-bgp4-cap-neg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-chandra-bgp4-cap-neg-00.txt

Internet-Drafts directories are located at:

     o  Africa:  ftp.is.co.za

     o  Europe:  ftp.nordu.net
		 ftp.nis.garr.it

     o  Pacific Rim: munnari.oz.au

     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-chandra-bgp4-cap-neg-00.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-chandra-bgp4-cap-neg-00.txt

- --OtherAccess
Content-Type:   Message/External-body;
	name="draft-chandra-bgp4-cap-neg-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: [email-masked]
Subject: checking for empty AS_PATH
Date: Fri, 18 Jul 97 11:24:47 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In 5.1.2:
 
   When a BGP speaker originates a route then:
 
     a) the originating speaker shall include its own AS number in
        the AS_PATH attribute of all UPDATE messages sent to an external
        peer.  (In this case, the AS number of the originating speaker's
        autonomous system will be the only entry in the AS_PATH attribute).

However, in 6.3 (Update message error handling):
 
    The AS_PATH attribute is checked for syntactic correctness.  If the
    path is syntactically incorrect, then the Error Subcode is set to
    Malformed AS_PATH.
 
Since an empty AS_PATH is *syntactically* correct, it seems that
a receiver would *never* check whether the AS_PATH is empty or not.

So, let me suggest that we'll add the following to 6.3:

   If an UPDATE was received from an external peer, and the UPDATE
   contains non-empty NLRI, the local system checks whether the
   AS_PATH attribute is empty. If that is the case, then the Error
   Subcode is set to Malformed AS_PATH.

Yakov.

P.S. In fact, we should probably make the check even stronger by checking
whether the most recent AS in the AS_PATH is the same as the AS of the
external peer. 

To: [email-masked] (Yakov Rekhter)
cc: [email-masked]
Subject: Re: Application of BGP ... draft
From: Tony Li <[email-masked]>
Date: 09 Jul 1997 17:08:58 -0700
Lines: 8
Sender: [email-masked]

[email-masked] (Yakov Rekhter) writes:

> The reference should list RFC1772. We'll fix the Internet Draft.

Master source fixed.  

Thanks,
Tony

Date: Wed, 9 Jul 1997 09:33:38 -0700
From: Cengiz Alaettinoglu <[email-masked]>
To: [email-masked]
Cc: Cengiz Alaettinoglu <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: rpsl comments ... 
Sender: [email-masked]

If nobody objects, I will change this in the draft to have an "and" in
there (minor change). 

This may happen after the current draft becomes a proposed
standard. This is OK since the time between proposed standard and
draft standard is for fixing this kind of errors. I also have minor
comments from several other people that will appear in the next
issue of the draft as well.

Curtis Villamizar ([email-masked]) on July 9:
> 
> In message <[email-masked]>, Cengiz Alaettinoglu writes:
> > 
> > Curtis Villamizar ([email-masked]) on July 8:
> > > > is what you need to specify. To make sense of it, please think of {
> > > > and } as set delimiters (as opposed to begin/end pairs, and the word
> > > > "except" as a set operator.
> > > 
> > > Except was intended to do an "AND NOT" and apply that to the first
> > > action and then do an "AND" and apply that to the second.
> > 
> > 
> > Curtis
> > 
> > On March 10th, we discussed this. I offered you two versions, one with
> > and one without "AND" in there. Both had advantages. You chose the
> > option that became the spec. Here is our correspondance.
> 
> I think we have a misunderstanding.
> 
> > Curtis Villamizar ([email-masked]) on March 10:
> > > 
> > > In message <[email-masked]>, Cengiz Alaettinoglu writes:
> > > > 
> > > > Curtis Villamizar ([email-masked]) on December 13:
> > > > > The other thing we need is nesting to avoid repeating large policy
> > > > > sets in filters.  This would put us on a par with the syntax ANS now
> > > > > uses.
> > > > > 
> > > > >    as-in: from <peering-1> [action <action-1>]
> > > > > 	  . . .
> > > > > 	  from <peering-N> [action <action-N>]
> > > > >       accept <filter> except {
> > > > > 	  as-in: from <peering-N+1> [action <action-N+1>]
> > > > > 	     accept <other-filter>
> > > > >       }
> > > > > 
> > > > 
> > > > Curtis,
> > > > 
> > > > Is the <other-filter> a subset of <filter> or arbitrary? Here is why I
> > > > am asking this question.
> > > 
> > > Its arbitrary.
> > > 
> > > > If <other-filter> is a subset of <filter>, the tools (think of
> > > > prtraceroute) would be faster, if the filter does not match a route no
> > > > need to check the exceptions.
> > > 
> > > If you have filter A and B, you could rewrite:
> > > 
> > > 	A->actionA except B->actionB
> > > 
> > > as
> > > 
> > > 	( A and not B )->actionA
> > > 	B->actionB
> > > 
> > > The second case is harder to write and involved evaluating B twice.
> 
> I took this to mean "you don't need an except in the language because
> you could always rewrite 'A->actionA except B->actionB' into '( A and
> not B )->actionA ; B->actionB'".  My reply to that was "The second
> case is harder to write and involved evaluating B twice".
> 
> > > > On the other hand, say 128.9/16 is an exception of AS226:
> > > > as-in: from ... accept AS226
> > > > 	except {
> > > > 		as-in: ... accept { 128.9/16 }
> > > > 	}
> > > > 
> > > > If 128.9/16 changes its origin, you would loose the policy for this
> > > > route (since <other-filter> is no longer a subset of <filter>). This
> > > > is probably OK, when somebody changes providers, routing will more
> > > > likely change too.
> > > > 
> > > > Cengiz
> > > 
> > > 
> > > The action is usually to list two providers for an interim period.
> > > Then one provider is dropped, the exception removed and the route
> > > object with the other AS deleted.  Of course with renumbering, this
> > > should become a withdrawn route object with a community to mark it as
> > > being in a renumbering grace period.
> > > 
> > > The other possibility is a permanently dual-homed prefix that is doing
> > > the multiple origin AS thing.
> > > 
> > > Curtis
> 
> My response was meant to say "Its OK for the exception to become a
> NOOP due to a zero intersection, in fact it happens all the time as in
> the example above and is the intended behavior".
> 
> > Curtis Villamizar ([email-masked]) on July 8:
> > > > > Now to hear from Cengiz on how he interpreted the requirement.
> > > > 
> > > >   Now to hear from Curtis on if my spec matches his requirement! :-)
> > > 
> > > Nope.  :(
> > 
> > I think the requirement changed. :(
> > 
> > Cengiz
> 
> Nope.  Its been the same all along.  We just weren't clear about it
> and I missed this in reviewing the draft.
> 
> Curtis
> 

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
(310) 822-1511                University of Southern California
http://www.isi.edu/~cengiz

To: Cengiz Alaettinoglu <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: rpsl comments ... 
Date: Wed, 09 Jul 1997 12:22:34 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Cengiz Alaettinoglu writes:
> 
> Curtis Villamizar ([email-masked]) on July 8:
> > > is what you need to specify. To make sense of it, please think of {
> > > and } as set delimiters (as opposed to begin/end pairs, and the word
> > > "except" as a set operator.
> > 
> > Except was intended to do an "AND NOT" and apply that to the first
> > action and then do an "AND" and apply that to the second.
> 
> 
> Curtis
> 
> On March 10th, we discussed this. I offered you two versions, one with
> and one without "AND" in there. Both had advantages. You chose the
> option that became the spec. Here is our correspondance.

I think we have a misunderstanding.

> Curtis Villamizar ([email-masked]) on March 10:
> > 
> > In message <[email-masked]>, Cengiz Alaettinoglu writes:
> > > 
> > > Curtis Villamizar ([email-masked]) on December 13:
> > > > The other thing we need is nesting to avoid repeating large policy
> > > > sets in filters.  This would put us on a par with the syntax ANS now
> > > > uses.
> > > > 
> > > >    as-in: from <peering-1> [action <action-1>]
> > > > 	  . . .
> > > > 	  from <peering-N> [action <action-N>]
> > > >       accept <filter> except {
> > > > 	  as-in: from <peering-N+1> [action <action-N+1>]
> > > > 	     accept <other-filter>
> > > >       }
> > > > 
> > > 
> > > Curtis,
> > > 
> > > Is the <other-filter> a subset of <filter> or arbitrary? Here is why I
> > > am asking this question.
> > 
> > Its arbitrary.
> > 
> > > If <other-filter> is a subset of <filter>, the tools (think of
> > > prtraceroute) would be faster, if the filter does not match a route no
> > > need to check the exceptions.
> > 
> > If you have filter A and B, you could rewrite:
> > 
> > 	A->actionA except B->actionB
> > 
> > as
> > 
> > 	( A and not B )->actionA
> > 	B->actionB
> > 
> > The second case is harder to write and involved evaluating B twice.

I took this to mean "you don't need an except in the language because
you could always rewrite 'A->actionA except B->actionB' into '( A and
not B )->actionA ; B->actionB'".  My reply to that was "The second
case is harder to write and involved evaluating B twice".

> > > On the other hand, say 128.9/16 is an exception of AS226:
> > > as-in: from ... accept AS226
> > > 	except {
> > > 		as-in: ... accept { 128.9/16 }
> > > 	}
> > > 
> > > If 128.9/16 changes its origin, you would loose the policy for this
> > > route (since <other-filter> is no longer a subset of <filter>). This
> > > is probably OK, when somebody changes providers, routing will more
> > > likely change too.
> > > 
> > > Cengiz
> > 
> > 
> > The action is usually to list two providers for an interim period.
> > Then one provider is dropped, the exception removed and the route
> > object with the other AS deleted.  Of course with renumbering, this
> > should become a withdrawn route object with a community to mark it as
> > being in a renumbering grace period.
> > 
> > The other possibility is a permanently dual-homed prefix that is doing
> > the multiple origin AS thing.
> > 
> > Curtis

My response was meant to say "Its OK for the exception to become a
NOOP due to a zero intersection, in fact it happens all the time as in
the example above and is the intended behavior".

> Curtis Villamizar ([email-masked]) on July 8:
> > > > Now to hear from Cengiz on how he interpreted the requirement.
> > > 
> > >   Now to hear from Curtis on if my spec matches his requirement! :-)
> > 
> > Nope.  :(
> 
> I think the requirement changed. :(
> 
> Cengiz

Nope.  Its been the same all along.  We just weren't clear about it
and I missed this in reviewing the draft.

Curtis

To: [email-masked]
cc: [email-masked]
Subject: Re: Application of BGP ... draft 
Date: Wed, 09 Jul 97 06:31:25 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rohit,

> The BGP-4 draft <draft-ietf-idr-bgp4-06.txt> (June 1997) refers to
> 
> [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
>    Protocol in the Internet", T.J. Watson Research Center, IBM Corp.,
>    MCI, Internet Draft.
> 
> The later doesn't seem to be listed in the internet-drafts index or
> at the working groups web page. 
> 
> Anybody have a copy of the document or a pointer to the replacement?

The reference should list RFC1772. We'll fix the Internet Draft.

Yakov.

From: [email-masked]
Date: Wed, 9 Jul 1997 09:22:10 -0400 (EDT)
To: [email-masked]
Subject: Application of BGP ... draft
Sender: [email-masked]

Hi,

The BGP-4 draft <draft-ietf-idr-bgp4-06.txt> (June 1997) refers to

[5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
   Protocol in the Internet", T.J. Watson Research Center, IBM Corp.,
   MCI, Internet Draft.

The later doesn't seem to be listed in the internet-drafts index or
at the working groups web page. 

Anybody have a copy of the document or a pointer to the replacement?

Thanks.

--rohit.
#include <stddisclaimer.h>

Date: Tue, 8 Jul 1997 18:39:40 -0700
Posted-Date: Tue, 8 Jul 1997 18:39:40 -0700
From: Cengiz Alaettinoglu <[email-masked]>
To: [email-masked]
Cc: Cengiz Alaettinoglu <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: rpsl comments ... 
Sender: [email-masked]

Curtis Villamizar ([email-masked]) on July 8:
> > is what you need to specify. To make sense of it, please think of {
> > and } as set delimiters (as opposed to begin/end pairs, and the word
> > "except" as a set operator.
> 
> Except was intended to do an "AND NOT" and apply that to the first
> action and then do an "AND" and apply that to the second.

Curtis

On March 10th, we discussed this. I offered you two versions, one with
and one without "AND" in there. Both had advantages. You chose the
option that became the spec. Here is our correspondance.

Curtis Villamizar ([email-masked]) on March 10:
> 
> In message <[email-masked]>, Cengiz Alaettinoglu writes:
> > 
> > Curtis Villamizar ([email-masked]) on December 13:
> > > The other thing we need is nesting to avoid repeating large policy
> > > sets in filters.  This would put us on a par with the syntax ANS now
> > > uses.
> > > 
> > >    as-in: from <peering-1> [action <action-1>]
> > > 	  . . .
> > > 	  from <peering-N> [action <action-N>]
> > >       accept <filter> except {
> > > 	  as-in: from <peering-N+1> [action <action-N+1>]
> > > 	     accept <other-filter>
> > >       }
> > > 
> > 
> > Curtis,
> > 
> > Is the <other-filter> a subset of <filter> or arbitrary? Here is why I
> > am asking this question.
> 
> Its arbitrary.
> 
> > If <other-filter> is a subset of <filter>, the tools (think of
> > prtraceroute) would be faster, if the filter does not match a route no
> > need to check the exceptions.
> 
> If you have filter A and B, you could rewrite:
> 
> 	A->actionA except B->actionB
> 
> as
> 
> 	( A and not B )->actionA
> 	B->actionB
> 
> The second case is harder to write and involved evaluating B twice.
> 
> > On the other hand, say 128.9/16 is an exception of AS226:
> > as-in: from ... accept AS226
> > 	except {
> > 		as-in: ... accept { 128.9/16 }
> > 	}
> > 
> > If 128.9/16 changes its origin, you would loose the policy for this
> > route (since <other-filter> is no longer a subset of <filter>). This
> > is probably OK, when somebody changes providers, routing will more
> > likely change too.
> > 
> > Cengiz
> 
> 
> The action is usually to list two providers for an interim period.
> Then one provider is dropped, the exception removed and the route
> object with the other AS deleted.  Of course with renumbering, this
> should become a withdrawn route object with a community to mark it as
> being in a renumbering grace period.
> 
> The other possibility is a permanently dual-homed prefix that is doing
> the multiple origin AS thing.
> 
> Curtis

Curtis Villamizar ([email-masked]) on July 8:
> > > Now to hear from Cengiz on how he interpreted the requirement.
> > 
> >   Now to hear from Curtis on if my spec matches his requirement! :-)
> 
> Nope.  :(

I think the requirement changed. :(

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
(310) 822-1511                University of Southern California
http://www.isi.edu/~cengiz

To: Cengiz Alaettinoglu <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: rpsl comments ... 
Date: Tue, 08 Jul 1997 21:13:40 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Cengiz Alaettinoglu writes:
> 
> >   from AS1 action pref=2; accept community.contains({3560,10}) AND AS1;
> >   from AS-ANY action pref=1; accept community.contains({3560,10}) AND NOT A
> S1;
> 
> not quite. what you get is:
> 
> from AS1 action pref=2; accept AS1;
> from AS-ANY action pref=1; accept community.contains({3560,10}) AND NOT AS1;

Oh oh.

> > The "except" allows you to defined what to do with some set and then
> > treat certain subsets differently.
> > 
> > There is actually a problem with the current syntax:
> > 
> >   {
> >     from ASn action pref = 1; accept as-macro ;
> >   } except {
> >     from ASn action pref = 2; accept as1 ;
> >   } except {
> >     from ASn action pref = 3; accept prefix1 ;
> >   } except {
> >     from ASn action pref = 4; accept as2 ;
> >   } except {
> >     from ASn action pref = 5; accept prefix2 ;
> >   }
> > 
> > The above is unclear.  It would be clear if arranged as follows:
> 
> above is equivalent to:
>      from ASn action pref = 5; accept prefix2 ;
>      from ASn action pref = 4; accept as2 and not prefix2;
>      from ASn action pref = 3; accept prefix1 and not (as2 or prefix2);
>      from ASn action pref = 2; accept as1 and not (prefix1 or as2 or prefix2)
> ;
>      from ASn action pref = 1; accept as-macro and not (as1 or prefix1 or as2
>  or prefix2);
> 
> Mostly likely it is not what you want. But it is not ambiguous at all.

This is what we wanted to avoid and why we currently use RIPE-181 as
the assembly language (many people have commented on how unreadable
our AS1673 aut-num is) and use our own source format.

> >   {
> >     from ASn action pref = 1; accept as-macro ;
> >     except {
> >       from ASn action pref = 2; accept as1 ;
> >       except {
> >         from ASn action pref = 3; accept prefix1 ;
> >       }
> >     }
> >     except {
> >       from ASn action pref = 4; accept as2 ;
> >       except {
> >         from ASn action pref = 5; accept prefix2 ;
> >       }
> >     }
> >   }
> 
> This is a syntax error:-) But you are very close:
> 
> { from ASn action pref = 1; accept as-macro ; }
>   except 
> {
>     { from ASn action pref = 2; accept as1 ; }
>       except 
>     { from ASn action pref = 3; accept prefix1 ; }
> 
>     { from ASn action pref = 4; accept as2 ; }
>       except
>     { from ASn action pref = 5; accept prefix2 ; }
> }

What I'm trying to tell you is that the syntax is not very clear due
to the placement of the delimiters and I'm asking you to change the
syntax.

> is what you need to specify. To make sense of it, please think of {
> and } as set delimiters (as opposed to begin/end pairs, and the word
> "except" as a set operator.

Except was intended to do an "AND NOT" and apply that to the first
action and then do an "AND" and apply that to the second.

The practical example is numerous providers who have AS macros of
their transit customers.  A few AS are dual homed so an exception is
needed.  A few prefixes within that AS have additional connectivity so
they need an exception to the exception.  In this case we need simple
left operator precedence.  In the example below, where there are two
AS, we need to be able to control the grouping.

> The 4 of the braces at column 3 are not needed, I put them for readability.
> 
> > You could even move the
> > semicolons and make it more clear.
> > 
> >   1    {
> >   2      from ASn action pref = 1; accept as-macro
> >   3      except {
> >   4        from ASn action pref = 2; accept as1
> >   5        except {
> >   6          from ASn action pref = 3; accept prefix1 ;
> >   7        };
> >   8      }
> >   9      except {
> >  10        from ASn action pref = 4; accept as2
> >  11        except {
> >  12          from ASn action pref = 5; accept prefix2 ;
> >  13        };
> >  14      };
> >  14    }
> > 
> > The "accept" on line 2 actually ends on line 14 after two "except"
> > statements, each "except" having another "except" nested within it.
> > I'm not sure that the outer brackets (line 1 and 14) serve any
> > purpose with this format.
> 
> In my example the set after the first except operator is completed by
> the last }.
> 
> > 
> > Now to hear from Cengiz on how he interpreted the requirement.
> 
>   Now to hear from Curtis on if my spec matches his requirement! :-)

Nope.  :(

> Cengiz

Curtis

Date: Tue, 8 Jul 1997 12:35:07 -0700
Posted-Date: Tue, 8 Jul 1997 12:35:07 -0700
From: Cengiz Alaettinoglu <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: rpsl comments ... 
Sender: [email-masked]

Curtis Villamizar ([email-masked]) on July 3:
> 
> In message <[email-masked]>, Antoni Przygienda writes:
> > 
> > > >          { from AS-ANY action pref = 1; accept community.contains({3560,1
> > 0});
> > > >          } except {
> > > >             from AS1 action pref=2; accept AS1;
> > > >          }
> > > >
> > 
> > boils down to 
> > 
> > from AS1 action pref=2; accept AS1;
> > from AS1 action pref=1; pref=2; accept community.contains({3560,10}) AND
> > NOT AS1;
> > 
> > or to 
> > 
> > from AS1 action pref=2; accept AS1;
> > from AS1 action pref=1; accept community.contains({3560,10}) AND NOT
> > AS1;
> 
> 
> Neither.  If the rhs in the first expression matches and rhs matches
> in the "except", the lhs of the first expression doesn't apply at all.
> If the rhs in the "except" doesn't match, then the first statement may
> apply.  One or the other (or neither) applies, not both.

I confirm. (This except business was Curtis's idea anyway, the refine
stuff is mine.)

> 
>   from AS1 action pref=2; accept community.contains({3560,10}) AND AS1;
>   from AS-ANY action pref=1; accept community.contains({3560,10}) AND NOT AS1;

not quite. what you get is:

from AS1 action pref=2; accept AS1;
from AS-ANY action pref=1; accept community.contains({3560,10}) AND NOT AS1;

> 
> The "except" allows you to defined what to do with some set and then
> treat certain subsets differently.
> 
> There is actually a problem with the current syntax:
> 
>   {
>     from ASn action pref = 1; accept as-macro ;
>   } except {
>     from ASn action pref = 2; accept as1 ;
>   } except {
>     from ASn action pref = 3; accept prefix1 ;
>   } except {
>     from ASn action pref = 4; accept as2 ;
>   } except {
>     from ASn action pref = 5; accept prefix2 ;
>   }
> 
> The above is unclear.  It would be clear if arranged as follows:

above is equivalent to:
     from ASn action pref = 5; accept prefix2 ;
     from ASn action pref = 4; accept as2 and not prefix2;
     from ASn action pref = 3; accept prefix1 and not (as2 or prefix2);
     from ASn action pref = 2; accept as1 and not (prefix1 or as2 or prefix2);
     from ASn action pref = 1; accept as-macro and not (as1 or prefix1 or as2 or prefix2);

Mostly likely it is not what you want. But it is not ambiguous at all.

> 
>   {
>     from ASn action pref = 1; accept as-macro ;
>     except {
>       from ASn action pref = 2; accept as1 ;
>       except {
>         from ASn action pref = 3; accept prefix1 ;
>       }
>     }
>     except {
>       from ASn action pref = 4; accept as2 ;
>       except {
>         from ASn action pref = 5; accept prefix2 ;
>       }
>     }
>   }

This is a syntax error:-) But you are very close:

{ from ASn action pref = 1; accept as-macro ; }
  except 
{
    { from ASn action pref = 2; accept as1 ; }
      except 
    { from ASn action pref = 3; accept prefix1 ; }

    { from ASn action pref = 4; accept as2 ; }
      except
    { from ASn action pref = 5; accept prefix2 ; }
}

is what you need to specify. To make sense of it, please think of {
and } as set delimiters (as opposed to begin/end pairs, and the word
"except" as a set operator.

The 4 of the braces at column 3 are not needed, I put them for readability.

> You could even move the
> semicolons and make it more clear.
> 
>   1    {
>   2      from ASn action pref = 1; accept as-macro
>   3      except {
>   4        from ASn action pref = 2; accept as1
>   5        except {
>   6          from ASn action pref = 3; accept prefix1 ;
>   7        };
>   8      }
>   9      except {
>  10        from ASn action pref = 4; accept as2
>  11        except {
>  12          from ASn action pref = 5; accept prefix2 ;
>  13        };
>  14      };
>  14    }
> 
> The "accept" on line 2 actually ends on line 14 after two "except"
> statements, each "except" having another "except" nested within it.
> I'm not sure that the outer brackets (line 1 and 14) serve any
> purpose with this format.

In my example the set after the first except operator is completed by
the last }.

> 
> Now to hear from Cengiz on how he interpreted the requirement.

  Now to hear from Curtis on if my spec matches his requirement! :-)

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
(310) 822-1511                University of Southern California
http://www.isi.edu/~cengiz

Date: Tue, 8 Jul 1997 11:59:48 -0700
Posted-Date: Tue, 8 Jul 1997 11:59:48 -0700
From: Cengiz Alaettinoglu <[email-masked]>
To: Tony Przygienda <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: rpsl comments ...
Sender: [email-masked]

Tony,

Sorry for a late reply. I was on travel last week. Here are some
clarifications.  As you said, most of these were discussed in the
working group.

Tony Przygienda ([email-masked]) on July 1:
> 1. it would be much easier to parse and deal with the objects if the 
>         grammar would allow for embedding of objects into some
> delimiters.

Believe me it is very easy w/o those delimiters as well. It takes 4
simple rules in lex, 
	\n[ \t]     treat it as white space (i.e. line continuation)
	\n#.*       line continuation which is a comment
	\n          end of attribute definition
	^\n         end of object definition

>         E.g.
> 
>         route-set {
>         name: rs-foo,
>         members: 128.9.0.0/16, 128.9.0.0/24
>         };
> 
>         instead of 
>  
>         route-set: rs-foo
>         members: 128.9.0.0/16, 128.9.0.0/24
> 
>         The first would be much easier to parse. Right now the grammar 
>         is somehow
>         context-dependent and not format-free (new-lines split different 
>         parts of an object specification and certain object attributes
>         introduce a context). I understand it's the historical baggage
> 	of RIPE.

Yes, we had to be compatible with the existing database software.

By the way, the language is context-free. And I can prove it too:-). I
have a lex/yacc based parser (lex/yacc can only parse LALR grammars
which are context-free).

> 
> 2. Policies based on a set of prefixes to be accepted and another set
>    to be refused seem to me to be rather bulky in terms of efficient
>    implementation when expressed inside rpsl.  There is no "refuse"
>    possiblity so one has to write rules for all the accepts "excepting"
>    or "refining" the ones to be refused and walk through all the rules.
>    Let me give an example for what I try to explain here:
> 
>         Someone tries to enforce the policy to flatly refuse from any AS
> 
>                 1.1.1.0/24^24-32
>                 1.2.1.0/24^24-32
>                 1.3.1.0/24^24-32
> 
>         and to accept 
>         
>                 from AS-1 accept 1.1.0.0/16^16-24 
>                 from AS-2 accept 2.1.0.0/16^16-24 
>                 from AS-3 accept 3.1.0.0/16^16-24        
>                 from AS-4 accept 4.1.0.0/16^16-24       
>                 from AS-5 accept 5.1.0.0/16^16-24       
>                 from AS-6 accept 6.1.0.0/16^16-24       
> 
>         The only way to express it in rpsl I see is to write 
> 
>         { 
>                 from AS-1 accept 1.1.0.0/16^16-24;
>                 from AS-2 accept 2.1.0.0/16^16-24;
>                 from AS-3 accept 3.1.0.0/16^16-24;               
>                 from AS-4 accept 4.1.0.0/16^16-24;              
>                 from AS-5 accept 5.1.0.0/16^16-24;      
>                 from AS-6 accept 6.1.0.0/16^16-24;      
>         
>         }
>                 refine
>                         {
>                                 from AS-ANY accept NOT {
> 1.1.1.0/24^24-32,
>                                                         
> 1.2.1.0/24^24-32,
>                                                         
> 1.3.1.0/24^24-32 };
>                         }          
> 
>         which will cause the policy to traverse 6
>         rules and for each of those check the 3 refined prefixes to see 
>         the match. This boils down to a very inefficient search that
> could be 
>         optimized if a "reject clause" existed. It could be expressed as
> 
>         from AS-ANY reject { 1.1.1.0/24^24-32,  
>                              1.2.1.0/24^24-32,
>                              1.3.1.0/24^24-32 };
>         from AS-1 accept
>                         1.1.0.0/16^16-24 AND AS-1; 
>         from AS-2 accept
>                         2.1.0.0/16^16-24 AND AS-2; 
>         from AS-3 accept
>                         3.1.0.0/16^16-24 AND AS-3;               
>         from AS-4 accept
>                         4.1.0.0/16^16-24 AND AS-4;              
>         from AS-5 accept
>                         5.1.0.0/16^16-24 AND AS-5;              
>         from AS-6 accept
>                         6.1.0.0/16^16-24 AND AS-6;      
> 
>         where the reject dumps the route immediately.
> 
>         I'd propose a reject clause in the language just flipping the 
>         semantics of "accept" but without actions. 
>         I admit I didn't think about the 
>         implications of "excepts" and "refines" when used with
> "rejects".
> 
>         An alternative would be to define AS-NONE as valid peering and
> if 
>         an accept strikes and peering is AS-NONE basically accept the
> route
>         but for no peers (reject it). IMHO it would give the language a
> nasty
> 	singularity in semantics though. 

Nick, the optimizations should be done by the tools, not by the
humans. One can pre-analyze the policies and rearrange them to make it
more efficient.

I acknowledge this is difficult to code. But if it needed to be
efficient, them it must have been important. In which case, it would
justify the cost.

By the way RAToolSet does this kind of optimization. In your example,
RAToolSet would take the cartesian product of the refine clause's both
sides and pre-evaluate each one of them into single radix tree per
peering. You can not beat that can you?

> 
> 3. I think one either doesn't want to allow in except cases 
>         for an <import-expression> that includes action clauses or the 
>         draft needs to explain semantics of action clauses in except 
>         statements. 

I guess the draft is not clear. It says:
The semantics for the except policy-set operator is as follows:  The  result
of an except operation is another  <import-term>.  The resulting policy  set
contains the policies of the right hand set unmodified.  The policies of the
left hand set are also contained  but their filters are modified to  exclude
the filters of the right hand set.  That is, the policies in the  right hand
set are exceptions to  the policies in the  left hand set.

>         Since the semantics of something like 
> 
>          { from AS-ANY action pref = 1; accept
> community.contains({3560,10});
>            from AS-ANY action pref = 2; accept
> community.contains({3560,20});
>          } except {
>             from AS1 action med=0; accept AS1;
>             from AS2 action med=1; accept AS2;
>             from AS3 action med=2; accept AS3;
>          }

is equivalent to:
from AS1 action med=0; accept AS1;
from AS2 action med=1; accept AS2;
from AS3 action med=2; accept AS3;
from AS-ANY action pref = 1; 
	accept community.contains({3560,10}) AND NOT (AS1 AS2 AS3);
from AS-ANY action pref = 2; 
	accept community.contains({3560,20}) AND NOT (AS1 AS2 AS3);

Please note that the filters are modified and the actions are not
copied verbatim.

Any suggestions to make the draft more clear?

> 
>    are unclear now. Furthermore, it's a little bit of a vicious circle
>    since    
> 
>         from AS-ANY action med = 0; accept {0.0.0.0/0^0-16};
>         } except {
>             from AS-ANY accept AS4; 
>             refine {
>               from AS1 at 7.7.7.1 action pref = 1; accept AS1;
>               from AS1            action pref = 2; accept AS1;
>             }
>           }
> 
>    does not make any sense for me either unless the draft explains what 
>    action statements in except clauses mean. 

from AS1 at 7.7.7.1 action pref = 1; accept AS1;
from AS1            action pref = 2; accept AS1;
from AS-ANY         action med = 0;  accept {0.0.0.0/0^0-16} AND NOT AS1;

so the preference are assigned to AS1's routes. And med is assinged to
other routes.

I hope I managed to answer all your questions.

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
(310) 822-1511                University of Southern California
http://www.isi.edu/~cengiz

From: [email-masked] (BHAVESH R PATHAK)
Subject: related to IPv4 and IPv6 in BGP5
To: [email-masked]
Date: Fri, 4 Jul 1997 11:36:13 -0530 (IST)
Sender: [email-masked]

Hi,
 I am new to this mailing list. I am not sure whether my query has
 been discussed before or not. If this is going to be a
 repeation for some of you please pardon me. 

    In the last mail I asked about IPv4 and IPv6 interoperation when one
    is implementing draft-bates-bgp4-multiprotocol-01.txt.  To be more
    specific about my question,

     ----------                          -----------
    |          |                        |           |
    |    R1    |                        |   R2      |
    |          |                        |           |
    | v4  v6   |                        |  v6   v4  |
    -------|----                        ---|-----|---
           |         BGP-5 conection       |     |
           ---------------------------------     |
                                                 |
                                                 | BGP-4 connection
                                                 |
                                                 |
                                                 |
                                                 |
                   --------------                |
                   |             |               |
                   |     R3      |               |
                   |          v4-----------------|
                   |             |
                   ---------------

    In the above situation,  Say router R2 wants to advertise to R1 
    that R3 which v4 router is reachable via R2. 

   Update message in the above situation,

     "Can it have a NEXT_HOP address as IPv6 address and MP_REACH_NLRI
       (or NLRI, I am not sure which should be used??) can contatin
      IPv6 and IPv4 address prefixes in AS_PATH attribute?"

   thanks in advance,
   bhavesh

   

To: [email-masked]
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: rpsl comments ... 
Date: Thu, 03 Jul 1997 17:51:52 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Antoni Przygienda writes:
> 
> > >          { from AS-ANY action pref = 1; accept community.contains({3560,1
> 0});
> > >          } except {
> > >             from AS1 action pref=2; accept AS1;
> > >          }
> > >
> 
> boils down to 
> 
> from AS1 action pref=2; accept AS1;
> from AS1 action pref=1; pref=2; accept community.contains({3560,10}) AND
> NOT AS1;
> 
> or to 
> 
> from AS1 action pref=2; accept AS1;
> from AS1 action pref=1; accept community.contains({3560,10}) AND NOT
> AS1;

Neither.  If the rhs in the first expression matches and rhs matches
in the "except", the lhs of the first expression doesn't apply at all.
If the rhs in the "except" doesn't match, then the first statement may
apply.  One or the other (or neither) applies, not both.

  from AS1 action pref=2; accept community.contains({3560,10}) AND AS1;
  from AS-ANY action pref=1; accept community.contains({3560,10}) AND NOT AS1;

The "except" allows you to defined what to do with some set and then
treat certain subsets differently.

There is actually a problem with the current syntax:

  {
    from ASn action pref = 1; accept as-macro ;
  } except {
    from ASn action pref = 2; accept as1 ;
  } except {
    from ASn action pref = 3; accept prefix1 ;
  } except {
    from ASn action pref = 4; accept as2 ;
  } except {
    from ASn action pref = 5; accept prefix2 ;
  }

The above is unclear.  It would be clear if arranged as follows:

  {
    from ASn action pref = 1; accept as-macro ;
    except {
      from ASn action pref = 2; accept as1 ;
      except {
        from ASn action pref = 3; accept prefix1 ;
      }
    }
    except {
      from ASn action pref = 4; accept as2 ;
      except {
        from ASn action pref = 5; accept prefix2 ;
      }
    }
  }

The first is ambiguous.  The second is clear and in effect represents
the rerquirement that I gave Cengiz.  You could even move the
semicolons and make it more clear.

  1    {
  2      from ASn action pref = 1; accept as-macro
  3      except {
  4        from ASn action pref = 2; accept as1
  5        except {
  6          from ASn action pref = 3; accept prefix1 ;
  7        };
  8      }
  9      except {
 10        from ASn action pref = 4; accept as2
 11        except {
 12          from ASn action pref = 5; accept prefix2 ;
 13        };
 14      };
 14    }

The "accept" on line 2 actually ends on line 14 after two "except"
statements, each "except" having another "except" nested within it.
I'm not sure that the outer brackets (line 1 and 14) serve any
purpose with this format.

Now to hear from Cengiz on how he interpreted the requirement.

Curtis

From: [email-masked] (BHAVESH R PATHAK)
Subject: IPv4 and IPv6 support for Multiprotocol BGP
To: [email-masked]
Date: Wed, 2 Jul 1997 19:45:16 -0530 (IST)
Sender: [email-masked]

Hi,

  I am interested in knowing what are the issues involved in
  implementation of draft-bates-multiprotocol-01.txt for IPv6 and 
  IPv4 interoperation.

bhavesh

[email-masked]

Date: Tue, 01 Jul 1997 12:49:48 -0400
From: Tony Przygienda <[email-masked]>
Organization: Fore Systems Inc.
To: [email-masked]
Subject: rpsl comments ...
Sender: [email-masked]

I'd like to ask several questions in respect to rpsl, some of which
may have been brought up already so bear with me please:

1. it would be much easier to parse and deal with the objects if the 
        grammar would allow for embedding of objects into some
delimiters.
        E.g.

        route-set {
        name: rs-foo,
        members: 128.9.0.0/16, 128.9.0.0/24
        };

        instead of 
 
        route-set: rs-foo
        members: 128.9.0.0/16, 128.9.0.0/24

        The first would be much easier to parse. Right now the grammar 
        is somehow
        context-dependent and not format-free (new-lines split different 
        parts of an object specification and certain object attributes
        introduce a context). I understand it's the historical baggage
	of RIPE.

2. Policies based on a set of prefixes to be accepted and another set
   to be refused seem to me to be rather bulky in terms of efficient
   implementation when expressed inside rpsl.  There is no "refuse"
   possiblity so one has to write rules for all the accepts "excepting"
   or "refining" the ones to be refused and walk through all the rules.
   Let me give an example for what I try to explain here:

        Someone tries to enforce the policy to flatly refuse from any AS

                1.1.1.0/24^24-32
                1.2.1.0/24^24-32
                1.3.1.0/24^24-32

        and to accept 
        
                from AS-1 accept 1.1.0.0/16^16-24 
                from AS-2 accept 2.1.0.0/16^16-24 
                from AS-3 accept 3.1.0.0/16^16-24        
                from AS-4 accept 4.1.0.0/16^16-24       
                from AS-5 accept 5.1.0.0/16^16-24       
                from AS-6 accept 6.1.0.0/16^16-24       

        The only way to express it in rpsl I see is to write 

        { 
                from AS-1 accept 1.1.0.0/16^16-24;
                from AS-2 accept 2.1.0.0/16^16-24;
                from AS-3 accept 3.1.0.0/16^16-24;               
                from AS-4 accept 4.1.0.0/16^16-24;              
                from AS-5 accept 5.1.0.0/16^16-24;      
                from AS-6 accept 6.1.0.0/16^16-24;      
        
        }
                refine
                        {
                                from AS-ANY accept NOT {
1.1.1.0/24^24-32,
                                                        
1.2.1.0/24^24-32,
                                                        
1.3.1.0/24^24-32 };
                        }          

        which will cause the policy to traverse 6
        rules and for each of those check the 3 refined prefixes to see 
        the match. This boils down to a very inefficient search that
could be 
        optimized if a "reject clause" existed. It could be expressed as

        from AS-ANY reject { 1.1.1.0/24^24-32,  
                             1.2.1.0/24^24-32,
                             1.3.1.0/24^24-32 };
        from AS-1 accept
                        1.1.0.0/16^16-24 AND AS-1; 
        from AS-2 accept
                        2.1.0.0/16^16-24 AND AS-2; 
        from AS-3 accept
                        3.1.0.0/16^16-24 AND AS-3;               
        from AS-4 accept
                        4.1.0.0/16^16-24 AND AS-4;              
        from AS-5 accept
                        5.1.0.0/16^16-24 AND AS-5;              
        from AS-6 accept
                        6.1.0.0/16^16-24 AND AS-6;      

        where the reject dumps the route immediately.

        I'd propose a reject clause in the language just flipping the 
        semantics of "accept" but without actions. 
        I admit I didn't think about the 
        implications of "excepts" and "refines" when used with
"rejects".

        An alternative would be to define AS-NONE as valid peering and
if 
        an accept strikes and peering is AS-NONE basically accept the
route
        but for no peers (reject it). IMHO it would give the language a
nasty
	singularity in semantics though. 

3. I think one either doesn't want to allow in except cases 
        for an <import-expression> that includes action clauses or the 
        draft needs to explain semantics of action clauses in except 
        statements. 
        Since the semantics of something like 

         { from AS-ANY action pref = 1; accept
community.contains({3560,10});
           from AS-ANY action pref = 2; accept
community.contains({3560,20});
         } except {
            from AS1 action med=0; accept AS1;
            from AS2 action med=1; accept AS2;
            from AS3 action med=2; accept AS3;
         }

   are unclear now. Furthermore, it's a little bit of a vicious circle
   since    

        from AS-ANY action med = 0; accept {0.0.0.0/0^0-16};
        } except {
            from AS-ANY accept AS4; 
            refine {
              from AS1 at 7.7.7.1 action pref = 1; accept AS1;
              from AS1            action pref = 2; accept AS1;
            }
          }

   does not make any sense for me either unless the draft explains what 
   action statements in except clauses mean. 

                                                        --- tony