Subject: [Idr] Document Action: 'Reclassification of RFC 1863 to Historic' to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 29 Apr 2005 17:59:50 -0400

The IESG has approved the following document:

- 'Reclassification of RFC 1863 to Historic '
   <draft-ietf-idr-rfc1863-historic-00.txt> as an Informational RFC

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Bill Fenner and Alex Zinin.

Technical Summary
 
   This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative
   to a full mesh routing, to Historic status.

   Implementations of RFC 1863 route servers do not exist, and are not
   used as an alternative to full mesh routing.
 
Working Group Summary
 
   The Working Group had consensus to reclassify RFC 1863.
 
Protocol Quality
 
   Bill Fenner reviewed this document for the IESG.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Fri, 29 Apr 2005 17:59:50 -0400
Cc: idr chair <[email-masked]>, idr mailing list <[email-masked]>, idr chair <[email-masked]>, Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>
Subject: [Idr] Document Action: 'Reclassification of RFC 1863 to Historic'  to Informational RFC 
Sender: [email-masked]

The IESG has approved the following document:

- 'Reclassification of RFC 1863 to Historic '
   <draft-ietf-idr-rfc1863-historic-00.txt> as an Informational RFC

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Bill Fenner and Alex Zinin.

Technical Summary
 
   This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative
   to a full mesh routing, to Historic status.

   Implementations of RFC 1863 route servers do not exist, and are not
   used as an alternative to full mesh routing.
 
Working Group Summary
 
   The Working Group had consensus to reclassify RFC 1863.
 
Protocol Quality
 
   Bill Fenner reviewed this document for the IESG.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Sat, 23 Apr 2005 04:19:46 +0100 (BST)
From: Acharya <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Jeff,

--- Jeffrey Haas <[email-masked]> wrote:
> Acharya,
> 
> On Mon, Feb 28, 2005 at 02:48:20AM +0000, Acharya
> wrote:
> > Infact, since the latest versions of BSD, and
> Linux
> > since the start, allow IF-address configuration as
> in:
> > eth1 = 10.10.10.1/24 and eth2 = 10.10.10.2/24, its
> > next to imppossible to actually detect, on the
> RUT,
> > whether two Nbrs have direct connectivity or not.
> 
> In ipv4, in the above configuration, you are
> declaring that both
> of the above interfaces are on the same logical
> subnet.  If they
> don't share a common physical subnet, this is a
> configuration 
> error.
> 

They need not share a common physical subnet and it
actually makes no difference whether they do share a
common physical subnet or not. One may say certain
aspects of the network may be undefined but as its
today with linux/netbsd, it is configurable and valid
since both interfaces come up fine and one can ping
and do the "regular stuff".

> In ipv6, for ipv6 link-local addresses, this would
> be different.

Configuring overlapping addresses on different
physical I/Fs was allowed in dual-stack Linux/Netbsd
basically because of the L-Local IPv6 addresses all
having the same subnet mask by default. So v6 LLocal
is no strange scenario or in any way different. So in
the dual-stack kernels, other a-families (non-LLocal)
have just been made to fall inline with the same
checks in code.

> However, RFC 2545 mandates that a global address be
> sent with
> the nexthop.  As such, it is possible for two global
> addresses
> be configured on the subnet as above.  For purposes
> of first
> vs. third party nexthop behavior, the check is
> against the
> global address since it is a nonsensical check
> against the
> link-local address.
> 

If one configures LLocal neighbors, there is no way
the NHop can be Global. (Also see the following
comment)

> [elided]
> > The above statement makes the provision of a
> command
> > akin to "nexthop-self" mandatory.
> > 
> > This would become a requirement if both TR2 and
> TR1,
> > in Cleary's example, are IPv6-Link-local neighbors
> > which donot have direct reachability to each
> other.
> > Then its impossible for the RUT to check whether
> "the
> > router" is reachable for the neighbor!
> 
> There was a proposal a while back for utilizing
> link-local peering
> sessions.  In this proposal, only a link-local
> address was exchanged
> in the MP-BGP nexthop field.  I don't believe this
> proposal ever
> gained traction in the IDR WG.

Well, if NextHop.com does not support configuring BGP
peers with LLocal Addresses just because your belief
against it, doesnt mean the world will follow. Infact
the world  (Cisco & Junos) does allow configuring BGP
peers with LLocal addresses. So NextHop.com better
follow suite! Nothing personal here.

Infact, 2545 does not explicitly preclude the use of
LLocal NHop addresses with "MUST NOT"/"SHALL NOT"
(uppercase). Its terminology is more suggestive than
preclusive.

Acharya.

> -- 
> Jeff Haas 
> NextHop Technologies

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Harisreeprasad Gowda" <[email-masked]>
To: "Vijayanand C - CTD, Chennai." <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Idr] redistributing isis v6 routes into BGP
Date: Fri, 22 Apr 2005 14:15:50 -0400
Importance: Normal
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I think it should be the global address of the interface over which the IBGP
peering is established.

-Hari.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vijayanand C - CTD, Chennai.
Sent: Thursday, April 21, 2005 10:24 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Idr] redistributing isis v6 routes into BGP

Hello all,
I have a question regarding redistribution of IPv6 ISIS routes into BGP.

The v6 routes of ISIS have link local next hops.  So, when these are
redistributed into I-BGP( without route maps having next hop set clause),
what should be the value of global next hop v6 address to be sent in the
update message. Would it be the global address of the interface
corresponding to the link local next hop or the global address of the
interface over which the IBGP peering is established or something else.

Thanks in advance,
Regards,
Vijay

DISCLAIMER
This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies
and its customers. Contents may be privileged or otherwise protected by law.
The information is solely intended for the
individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to
read, forward, print, retain, copy or disseminate this message or any part
of it. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete it from
your computer.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Content-Class: urn:content-classes:message
From: "Vijayanand C - CTD, Chennai." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 21 Apr 2005 19:53:31 +0530
Cc: [email-masked], [email-masked]
Subject: [Idr] redistributing isis v6 routes into BGP
Sender: [email-masked]

Hello all,
I have a question regarding redistribution of IPv6 ISIS routes into BGP.

The v6 routes of ISIS have link local next hops.  So, when these are
redistributed into I-BGP( without route maps having next hop set clause),
what should be the value of global next hop v6 address to be sent in the
update message. Would it be the global address of the interface
corresponding to the link local next hop or the global address of the
interface over which the IBGP peering is established or something else.

Thanks in advance,
Regards,
Vijay

DISCLAIMER 
This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law.
The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to 
read, forward, print, retain, copy or disseminate this message or any part
of it. If you have received this e-mail in error, 
please notify the sender immediately by return e-mail and delete it from
your computer.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Mon, 18 Apr 2005 11:27:42 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked], Rick Wilder <[email-masked]>
Subject: [Idr] draft-ietf-l3vpn-rt-constrain-01.txt review
Sender: [email-masked]

Folks,

draft-ietf-l3vpn-rt-constrain-01.txt has completed last call in the
L3VPN WG. The area directors have asked for it to be reviewed by
the IDR WG.

The deadline for comments is May 2, 2005.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Date: Mon, 11 Apr 2005 16:29:18 -0400
Subject: [Idr] FW: draft-ietf-idr-bgp4-mibv2-04.txt Expired
Sender: [email-masked]

Resending since this didn't go through due to email address issues (mine)
...

-----Original Message-----
From: Chisholm, Sharon [CAR:5K50:EXCH] 
Sent: Monday, April 11, 2005 3:24 PM
To: [email-masked]'
Subject: draft-ietf-idr-bgp4-mibv2-04.txt Expired

hi

It seems that draft-ietf-idr-bgp4-mibv2-04.txt has expired.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Tue, 05 Apr 2005 15:32:50 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-05.txt
Sender: [email-masked]

--NextPart

A New 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		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-ietf-idr-bgp-identifier-05.txt
	Pages		: 5
	Date		: 2005-4-5
	
To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also 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-bgp-identifier-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-identifier-05.txt".
	
NOTE:	The mail server at ietf.org 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-bgp-identifier-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-identifier-05.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--