headers
Yakov Rekhter | 3 Dec 19:08
Favicon

draft-lefaucheur-idr-v4nlri-v6nh-00.txt

Folks,

May I suggest that before adopting this as a WG document the authors
would produce a revised document that would reflect the comments
they received.

Yakov.
------- Forwarded Message

Date:    Mon, 20 Nov 2006 08:57:56 -0800
From:    Yakov Rekhter <yakov <at> juniper.net>
To:      idr <at> ietf.org

Folks,

Please comment on the attached. The deadline for comments is
Dec 1, 2006.

Yakov.
- ------- Forwarded Message

Date:    Fri, 17 Nov 2006 12:47:36 -0500
From:    Eric Rosen <erosen <at> cisco.com>
To:      idr <at> ietf.org
Subject: [Idr] draft-lefaucheur-idr-v4nlri-v6nh-00.txt

At  the  IDR  WG  meeting  last  week,  we  discussed  draft-lefaucheur-idr-
v4nlri-v6nh.  I would like to propose now  that this be adopted as an IDR WG
document.  Your feedback is invited.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bruno Rijsman | 7 Dec 12:30
Favicon

New "BFD session down" error sub-code for the BGP Cease NOTIFICATION message.

I would like to propose to allocate a new "BFD session down" error subcode
(value 9) for the BGP Cease NOTIFICATION message.

Since BGP error subcodes are allocated using the "early IANA allocation"
process [RFC4020] which requires a proposed standards I-D, I have posted a
very small draft at
http://tools.ietf.org/wg/bfd/draft-rijsman-bfd-down-subcode-00.txt

Comments on the subcode itself or on the procedure for allocating it are
welcome.

-- Bruno

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Francois Le Faucheur IMAP | 7 Dec 17:28
Picon
Favicon

Re: draft-lefaucheur-idr-v4nlri-v6nh-00.txt

Yes, will do Yakov.

On 3 Dec 2006, at 19:08, Yakov Rekhter wrote:

> Folks,
>
> May I suggest that before adopting this as a WG document the authors
> would produce a revised document that would reflect the comments
> they received.
>
> Yakov.
> ------- Forwarded Message
>
> Date:    Mon, 20 Nov 2006 08:57:56 -0800
> From:    Yakov Rekhter <yakov <at> juniper.net>
> To:      idr <at> ietf.org
>
> Folks,
>
> Please comment on the attached. The deadline for comments is
> Dec 1, 2006.
>
> Yakov.
> - ------- Forwarded Message
>
> Date:    Fri, 17 Nov 2006 12:47:36 -0500
> From:    Eric Rosen <erosen <at> cisco.com>
> To:      idr <at> ietf.org
> Subject: [Idr] draft-lefaucheur-idr-v4nlri-v6nh-00.txt
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Matthew | 7 Dec 18:05

draft-ietf-idr-as-pathlimit-02 - Private ASes

Hi Folks

Why does the draft indicate that private AS numbers should not be 
counted when determining the path length?

In order to facilitate the decision process BGP already maintains a 
count that satisfies the other requirements (counting AS_SET as one, 
ditching confederation ASes).  Does explicitly referring to private ASes 
imply another counter?

Setting aside the validity of mixing private and public ASes, what 
happens if an AS_SET contains one or more private ASes?  Does this still 
count as 1 or is it 0?

Cheers

Neil

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Erblichs | 8 Dec 00:16
Picon
Favicon

Re: New "BFD session down" error sub-code for the BGP CeaseNOTIFICATION message.

Bruno,

	Can I ask "1" stupid question? 

	Does this mean that the state variable "bfd.SessionState"
	is Down or AdminDown? Or both?

	Mitchell Erblich
	-------------------

	

Bruno Rijsman wrote:
> 
> I would like to propose to allocate a new "BFD session down" error subcode
> (value 9) for the BGP Cease NOTIFICATION message.
> 
> Since BGP error subcodes are allocated using the "early IANA allocation"
> process [RFC4020] which requires a proposed standards I-D, I have posted a
> very small draft at
> http://tools.ietf.org/wg/bfd/draft-rijsman-bfd-down-subcode-00.txt
> 
> Comments on the subcode itself or on the procedure for allocating it are
> welcome.
> 
> -- Bruno
> 
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Rijsman | 8 Dec 16:03
Favicon

RE: New "BFD session down" error sub-code for the BGP CeaseNOTIFICATION message.

MitchellErblich> Does this mean that the state variable
"bfd.SessionState" is Down or AdminDown? Or both?

That is actually a very good question.

The cease notification with subcode "BFD session down" should be sent
when the BFD session transitions from "Up" to "Down".

In other words, the notification indicates that the session *went*
operationally "Down" and not that the session *is* operationally "Down".

I should probably rename the subcode to "BFD session lost" or "BFD
session went down" to clarify this.

Just to give some background information: all BFD for BGP
implementations which I am familiar with (include one from another major
vendor) work as follows:

(1) When the BGP session reaches state established (or sometimes
earlier), a BFD session is initiated to the address of the BGP neighbor.

(2) If the BFD session fails to come up (e.g. because BFD is not
configured on the remote side) the BGP session is still allowed to stay
in state established. So, the fact that the BFD session is "Down" at
this point does *not* trigger BGP to send a notification.

(3) Let's assume that the BFD session does come "Up" at some point in
time.

(4) If the BFD session goes "Down" after that, the BGP session will be
(Continue reading)

Permalink | Reply | 501 comments |
headers
Joe Abley | 8 Dec 20:15

Re: draft-ietf-idr-as-pathlimit-02 - Private ASes

Hi Neil,

On 7-Dec-2006, at 12:05, Neil Matthew wrote:

> Why does the draft indicate that private AS numbers should not be  
> counted when determining the path length?
>
> In order to facilitate the decision process BGP already maintains a  
> count that satisfies the other requirements (counting AS_SET as  
> one, ditching confederation ASes).  Does explicitly referring to  
> private ASes imply another counter?
>
> Setting aside the validity of mixing private and public ASes, what  
> happens if an AS_SET contains one or more private ASes?  Does this  
> still count as 1 or is it 0?

These are excellent questions, but since that text was Tony's, I'd  
prefer to leave him to address your questions. He's a little tied up  
right now, but tells me that he will be back on-deck in the next  
little while, with more time to spend on IETF stuff.

Joe

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Erblichs | 11 Dec 21:50
Picon
Favicon

Re: New "BFD session down" error sub-code for the BGP CeaseNOTIFICATION message.

Bruno Rijsman,

	You seem to separate the message notfication from the
	actual  status of the link....

> The cease notification with subcode "BFD session down" should be sent
> when the BFD session transitions from "Up" to "Down".
> 
> In other words, the notification indicates that the session *went*
> operationally "Down" and not that the session *is* operationally "Down".
> 
	
	Which seems to be opposite of
	6.7.5. Detecting Failures with the Echo Function.

	IMO,,

	1) If the local BFD doesn't see an echo, it should somehow
	   generate a local BFD session down and get the error sub-code
	   to the local BGP. This is a guranteed deliverable msg.

	2) It would seem here that if the session "went" operationally
	   down then it "is" operationally down. At least until we see
	   a new echo / hello / alive type pkt.

	--
	This is when the endpoint can only REALLY state that I am here, by
	the sending of echos / hellos / alive pkts.

	So, the problem I see is that if you timers are functionally correct
(Continue reading)

Permalink | Reply | 501 comments |
headers
JUAN-JOSE.ADAN | 12 Dec 12:53
Picon

Draft on "Tunneled Inter-domain Routing", version 01

Hi,

I have sent a new version of the draft on "Tunneled Inter-domain
Routing" (TIDR): draft-adan-idr-tidr-01.txt.

TIDR allows us to classify prefixes into "identifier prefixes"
and "locator prefixes". Considering that in a full TIDR-aware
Internet transit packet forwarding would be based only on locators
the need to make sure that an autonomous system is authorized
to announce a "locator prefix" is crucial. In my proposal, I
show a way to achieve this by using (1) a specific IP address
range assigned per AS; (2) the LOCATOR attribute to digitally
sign the announcement; and (3) the AS_PATH.

I have included in a new section on "Security Considerations"
these ideas on the authentication of identifier prefixes and
locator prefixes.

Any comments will be appreciated.

Thanks,
Juanjo

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 12 Dec 21:50
Picon
Favicon

I-D ACTION:draft-ooms-v6ops-bgp-tunnel-07.txt

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		: Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)
	Author(s)	: J. De Clercq, et al.
	Filename	: draft-ooms-v6ops-bgp-tunnel-07.txt
	Pages		: 14
	Date		: 2006-12-12
	
This document explains how to interconnect IPv6 islands over a Multi-
   Protocol Label Switching (MPLS)-enabled IPv4 cloud.  This approach
   relies on IPv6 Provider Edge routers (6PE) which are Dual Stack in
   order to connect to IPv6 islands and to the MPLS core which is only
   required to run IPv4 MPLS.  The 6PE routers exchange the IPv6
   reachability information transparently over the core using the Multi-
   Protocol Border Gateway Protocol (MP-BGP) over IPv4.  In doing so,
   the BGP Next Hop field is used to convey the IPv4 address of the 6PE
   router so that dynamically established IPv4-signaled MPLS Label
   Switched Paths (LSPs) can be used without explicit tunnel
   configuration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane