headers
Bill Fenner | 6 Nov 17:48
Picon

TCP Authentication discussion: tcpm wg, Thursday 1300-1500


Hi,

  I'd like to draw your attention to the tcpm working group
agenda; it begins with a discussion of draft-bellovin-tcpsec,
whose abstract reads:

   The TCP-MD5 option, commonly used to secure BGP sessions between
   routers, has many serious deficiencies.  We present here
   justifications for designing a new, more capable version of that
   option; we also discuss some of the design criteria for one.

I'd encourage those with thoughts and experience in this area to attend
if you can.

Thanks,
  Bill

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Francois Le Faucheur | 6 Nov 23:11
Picon
Favicon

Re: Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard

Hello,

In order to help reach closure on that one, below is a proposal (that  
a few of us converged on) for tweaking the wording of 2858bis:

Replace:
>
>       Address Family Identifier (AFI):
>
>          This field in combination with the Subsequent Address Family
>          Identifier field identifies the Network Layer protocol
>          associated with the Network Address of Next Hop and the
>          semantics of the Network Layer Reachability Information that
>          follows.

with:

>       Address Family Identifier (AFI):
>
> 	 This field in combination with the Subsequent Address
> 	 Family Identifier field identifies the set of Network Layer
> 	 protocols to which the address carried in the Next Hop field
> 	 must belong, the way in which the address of the next hop
> 	 is encoded, and the semantics of the Network Layer
> 	 Reachability Information that follows. If the Next Hop is
> 	 allowed to be from more than one Network Layer protocol,
> 	 the encoding of the Next Hop MUST provide a way to determine
> 	 its Network Layer protocol.

Replace:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 7 Nov 18:08
Favicon

fixing wording in 2858bis

Folks,

The goal of the text proposed by Francois below is to clarify the
initial intent and more accurately reflect the current use of 2858bis.
In other words the goal of this change is to eliminate a mismatch
between the current of use 2858bis (as specified in such documents
as draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, and
draft-ietf-l2vpn-vpls-bgp, RFC4659, and draft-ooms-v6ops-bgp-tunnel)
and the current text of 2858bis.

Please comment on the proposed wording. The deadline for comments
is Nov 17,2006.

Yakov.
------- Forwarded Message

Date:    Mon, 06 Nov 2006 14:11:37 -0800
From:    Francois Le Faucheur <flefauch <at> cisco.com>
To:      idr <at> ietf.org
Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using
	   IPv6 Provider Edge Routers (6PE)' to Proposed Standard

Hello,

In order to help reach closure on that one, below is a proposal (that  
a few of us converged on) for tweaking the wording of 2858bis:

Replace:
>
>       Address Family Identifier (AFI):
(Continue reading)

Permalink | Reply | 501 comments |
headers
JUAN-JOSE.ADAN | 8 Nov 11:31
Picon

Draft on "Tunneled Inter-domain Routing"


Hi,

I sent a draft in October on "Tunneled Inter-domain Routing" (TIDR):
draft-adan-idr-tidr-00.txt.

TIDR is a proposal to modify the way in which traffic is routed to
"stub networks". The meaning of "stub network" is not the same for
inter-domain routing than for intra-domain routing.

For BGP a "stub network" is simply a leaf autonomous system, whether
it be single- or multi-homed. ISPs would add a new transitive BGP
attribute called LOCATOR to a client prefix so as to specify how other
autonomous systems can send tunneled traffic for that client prefix.
The tunnel type is left open in TIDR (we can use several types), but
the best way to understand TIDR is to think on multipoint GRE tunnels.

This LOCATOR attribute will eventually allow us to move client prefixes
from the global RIB to a new table called "Tunnel Information Base" (TIB).
And this move provides many benefits, e.g. client prefixes instabilities
will affect only the TIB, not the RIB.

ISP prefixes used for TIDR tunnels endpoints will be stored in the RIB
and they will act as true locators for the client prefixes. And client
prefixes will be stored in the TIB and will be used as identifiers.

When routing a packet to a leaf AS, the TIB will be search to perform
locator imposition, and the RIB will be used for actual routing. The
ISP that added the LOCATOR attribute will de-tunnel the traffic before
delivering it to its cliet.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 8 Nov 19:44
Picon

Re: fixing wording in 2858bis

On Tue, 7 Nov 2006, Yakov Rekhter wrote:
> The goal of the text proposed by Francois below is to clarify the
> initial intent and more accurately reflect the current use of 2858bis.
> In other words the goal of this change is to eliminate a mismatch
> between the current of use 2858bis (as specified in such documents
> as draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, and
> draft-ietf-l2vpn-vpls-bgp, RFC4659, and draft-ooms-v6ops-bgp-tunnel)
> and the current text of 2858bis.
> 
> Please comment on the proposed wording. The deadline for comments
> is Nov 17,2006.

Does this require revisiting the implementation report for 2858bis?

> ------- Forwarded Message
> 
> Date:    Mon, 06 Nov 2006 14:11:37 -0800
> From:    Francois Le Faucheur <flefauch <at> cisco.com>
> To:      idr <at> ietf.org
> Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using
> 	   IPv6 Provider Edge Routers (6PE)' to Proposed Standard
> 
> Hello,
> 
> In order to help reach closure on that one, below is a proposal (that  
> a few of us converged on) for tweaking the wording of 2858bis:
> 
> Replace:
> >
> >       Address Family Identifier (AFI):
(Continue reading)

Permalink | Reply | 501 comments |
headers
Yakov Rekhter | 8 Nov 19:50
Favicon

Re: fixing wording in 2858bis

Pekka,

> On Tue, 7 Nov 2006, Yakov Rekhter wrote:
> > The goal of the text proposed by Francois below is to clarify the
> > initial intent and more accurately reflect the current use of 2858bis.
> > In other words the goal of this change is to eliminate a mismatch
> > between the current of use 2858bis (as specified in such documents
> > as draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, and
> > draft-ietf-l2vpn-vpls-bgp, RFC4659, and draft-ooms-v6ops-bgp-tunnel)
> > and the current text of 2858bis.
> > 
> > Please comment on the proposed wording. The deadline for comments
> > is Nov 17,2006.
> 
> Does this require revisiting the implementation report for 2858bis?

No.

Yakov.

> > ------- Forwarded Message
> > 
> > Date:    Mon, 06 Nov 2006 14:11:37 -0800
> > From:    Francois Le Faucheur <flefauch <at> cisco.com>
> > To:      idr <at> ietf.org
> > Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS u
sing
> > 	   IPv6 Provider Edge Routers (6PE)' to Proposed Standard
> > 
> > Hello,
(Continue reading)

Permalink | Reply | 0 comments |
headers
JUAN-JOSE.ADAN | 10 Nov 12:24
Picon

Rm: Draft on "Tunneled Inter-domain Routing"


Robert,

I have included my comments to your observations. I hope
they put more light on my proposal.

I will be out for a week. I will check later about the
possibility of having a meeting somewhere in Europe.
I will have to convince my boss first :-).

Regards,
Juanjo


----- Remitido por JUAN JOSE ADAN LUENGO/GISS/SEG-SOCIAL con fecha
10/11/2006 10:39 -----

Robert Raszuk <raszuk <at> cisco.com> escribió el 09/11/2006 00:56:33:

> Hi Juan,
>
> Below are my more detailed comments. You have a choice to ignore them or
> attempt to work together to simplify the current proposal to be much
> more easy to deploy both from vendor as well as customers point of view.
>
> Comments:
> ---------
>
> > I sent a draft in October on "Tunneled Inter-domain Routing" (TIDR):
> > draft-adan-idr-tidr-00.txt.
(Continue reading)

Permalink | Reply | 2 comments |
headers
JUAN-JOSE.ADAN | 10 Nov 12:18
Picon

Rm: Draft on "Tunneled Inter-domain Routing"


Robert,

Thank you very much for your comments.
You can find my comments below.

Regards,
Juanjo

----- Remitido por JUAN JOSE ADAN LUENGO/GISS/SEG-SOCIAL con fecha
10/11/2006 12:01 -----

Robert Raszuk <raszuk <at> cisco.com> escribió el 08/11/2006 14:48:08:

> Juan,
>
> Excellent doc !!!! I must say that I with few other folks from Cisco are
> also actively working on a very similar idea for about last 8 months. I
> am not sure if you would like to continue the individual work or would
> be willing for a joint collaboration.
>

The draft I sent to the IDR WG is based on a paper I tried to publish
in the journal of big networking company based on San Jose (California),
without success. Later, I rewrote the paper for the Global Internet
Symposium of INFOCOM-2006, but it was rejected. Therefore this is my
third attempt to get it. However I must say I am new. This is my
first research paper and I don't know if it could published as an
individual submission, after it is pulished by all of your comments
of course.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Raszuk | 10 Nov 16:17
Picon
Favicon

Re: Rm: Draft on "Tunneled Inter-domain Routing"

Hi Juan,

> I will be out for a week. I will check later about the
> possibility of having a meeting somewhere in Europe.
> I will have to convince my boss first :-).

Well we could have a sub-idr meeting for this project in Madrid then
discuss it more at next IETF in Prague ;-).

> The idea of having an IP address for an AS is something that
> I also considered but I think it is much more interesting to
> have a prefix so that we could even specify a specific entry
> point in the AS por traffic directed to a specific "identifier
> prefix". And a specific locator could be configured as an anycast
> IP address so that in case of a problem in an entry point, the
> tunneled traffic could be delivered through another entry point.
+
> Don't you think it is better to have several AS IPs instead of just
> one?.

I think we both agree on the anycasting model. I also think we all agree
on the need for more then one dst for end AS. Most practical need is
triggered for a prefix group based inbound traffic engineering.

The only disconnects are I think minor reg the allocation model of those
destinations and their choice of signaling.

> I think my proposal is much more general. Most of the value-added
> services are based on tunnels (mobility, VPNs, TE,...). I think
> there is a need for a richer routing paradigm, and in my opinion
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rosen | 17 Nov 18:47
Picon
Favicon

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. 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |

Gmane