Subject: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

From: Yakov Rekhter <[email-masked]>
Date: Mon, 17 Jan 2005 07:52:37 -0800

Folks,

This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last
call ends on Feb 1 at midnight UTC.

Yakov.

P.S. this is a combined last call with the L3VPN WG.

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 27 Jan 2005 13:24:55 -0500

Yakov,

I'll try to find a bit of time to review this in detail, but the
IANA considerations of both this and the 2547bis section caught
my attention.

I understand the reasoning as to why they'd want their SAFI values to
not move, but this begs a broader question:

a) IDR has requested IANA to leave SAFIs 128+ as private use.
   A non-IDR group is requesting holes get poked in that policy.
b) Some quick googling shows a number of SAFI values being used that
   are going to be having the same problems.

Why exactly are they using private SAFI's (which were known to have
possible collision issues) instead of either requesting a first-come,
first-server allocation or requesting a value in the WG consensus
space?

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jan 2005 18:03:37 -0500

I have a concern with regards to the MP-BGP nexthops for this draft:

This draft ties the MP-BGP nexthop associated with VPN-IPv6 reachability
to the BGP Speaker's transport session type.  I.e. an IPv6 transport session
will require IPv6 VPN-IPv6 nexthops and an IPv4 transport session will
require IPv4 VPN-IPv4 nexthops.

Why is this a SHALL?

MP-BGP allows for different address families to be carried across
the same BGP session regardless of the form of the transport session.
When carrying information for a different address family (e.g.
an ipv4 transport session carrying ipv6 reachability) it is necessary
to configure additional information about the endpoints of the session
for reachability calculations.  This draft appears to try to preclude
this option in some capacities for VPN-IPv6.

I would suspect that regardless of the transport session type, as
long as it was clear if the nexthop was v4 or v6 that as long as
a label-switched path could be established between the two BGP speakers
it shouldn't matter what kind of transport session is being used.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 31 Jan 2005 18:03:37 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: Ross Callon <[email-masked]>, [email-masked], [email-masked], [email-masked], Ronald Bonica <[email-masked]>
Sender: [email-masked]

I have a concern with regards to the MP-BGP nexthops for this draft:

This draft ties the MP-BGP nexthop associated with VPN-IPv6 reachability
to the BGP Speaker's transport session type.  I.e. an IPv6 transport session
will require IPv6 VPN-IPv6 nexthops and an IPv4 transport session will
require IPv4 VPN-IPv4 nexthops.

Why is this a SHALL?

MP-BGP allows for different address families to be carried across
the same BGP session regardless of the form of the transport session.
When carrying information for a different address family (e.g.
an ipv4 transport session carrying ipv6 reachability) it is necessary
to configure additional information about the endpoints of the session
for reachability calculations.  This draft appears to try to preclude
this option in some capacities for VPN-IPv6.

I would suspect that regardless of the transport session type, as
long as it was clear if the nexthop was v4 or v6 that as long as
a label-switched path could be established between the two BGP speakers
it shouldn't matter what kind of transport session is being used.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 31 Jan 2005 11:55:38 -0500
From: Jeffrey Haas <[email-masked]>
To: "Francois Le Faucheur (flefauch)" <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, "Eric Rosen \(erosen\)" <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Re: comment on draft-ietf-l3vpn-bgp-ipv6-04
Sender: [email-masked]

Fracois,

On Mon, Jan 31, 2005 at 05:48:34PM +0100, Francois Le Faucheur (flefauch) wrote:
> But I guess your comment is more addressed at newer SAFI values being
> defined more recently than the "MPLS-labeled VPN address" SAFI.

Exactly.

While we are unlikely to be able to get things changed at this late
stage, we should correct our procedure as quickly as possible. 

> Francois

-- 
Jeff Haas 
NextHop Technologies

Content-class: urn:content-classes:message
Date: Mon, 31 Jan 2005 17:48:34 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>, "Eric Rosen \(erosen\)" <[email-masked]>
Subject: [Idr] RE: comment on draft-ietf-l3vpn-bgp-ipv6-04
Sender: [email-masked]

Hello Jeffrey,

Thanks for your comment.

As far as <draft-ietf-l3vpn-bgp-ipv6-04> is concerned, the natural thing
to do is of course just to use the same "MPLS-labeled VPN address" SAFI
value as defined in 2547bis.

As far as 2547bis is concerned, authors of that document are in a better
position than me to comment, but considering the huge implementation and
deployment base using SAFI=128 today, changing the private range from
128+ to 129+ seems to me like the right thing to do.

But I guess your comment is more addressed at newer SAFI values being
defined more recently than the "MPLS-labeled VPN address" SAFI.

Thanks

Francois

>> Date:    Thu, 27 Jan 2005 13:24:55 -0500
>> From:    Jeffrey Haas <[email-masked]>
>> To:      Yakov Rekhter <[email-masked]>, Alex Zinin 
>> <[email-masked]>
>> cc:      [email-masked], Ross Callon <[email-masked]>,
>> 	 Ronald Bonica <[email-masked]>, [email-masked],
>> 	 [email-masked]
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> Yakov,
>> 
>> - -- 
>> ------- End of Forwarded Message
>> 

To: [email-masked]
Date: Mon, 31 Jan 2005 08:00:09 -0800
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] IDR WG agenda
Sender: [email-masked]

Folks,
 
Its about time to start thinking about agenda items for the next
IETF. Please forward any IDR agenda items you might have to me and Sue.

Sue & Yakov.

content-class: urn:content-classes:message
Date: Mon, 31 Jan 2005 10:40:08 -0500
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: Bill Fenner <[email-masked]>, [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>, [email-masked]
Subject: [Idr] Last call on draft-ooms-v6ops-bgp-tunnel-04.txt 
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============0619640591==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C507AB.245A1976"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C507AB.245A1976
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

The last call is for moving the following document to

Proposed Standard:=20

=20

draft-ooms-v6ops-bgp-tunnel-04.txt
<http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-04.txt>

=20

 "Connecting IPv6 Islands over IPv4 MPLS

  using IPv6 Provider Edge Routers (6PE)"

=20

By J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur

=20

draft-ooms-v6ops-bgp-tunnel-04.txt
<http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-04.txt>

This last call will start today 1/31, and go for

2 weeks ending on 2/14.=20

=20

This document was created in another working group,

and forwarded by the Routing ADs for review by the

IDR working group.=20

=20

This Last call is not for the document to become an=20

IDR document.

=20

Please send comments to the list.

=20

Sue Hares and Yakov Rekhter

=20

=20

------_=_NextPart_001_01C507AB.245A1976
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The last call is =
for moving the
following document to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Proposed Standard: =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-0=
4.txt">draft-ooms-v6ops-bgp-tunnel-04.txt</a><br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&#8220;</span></font><font =
face=3D"Courier New"><span
style=3D'font-family:"Courier New"'>Connecting IPv6 <st1:place =
w:st=3D"on">Islands</st1:place>
over IPv4 MPLS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;using IPv6 Provider Edge Routers =
(6PE)&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>By J. De Clercq, D. Ooms, S. Prevost, F. Le =
Faucheur<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-0=
4.txt">draft-ooms-v6ops-bgp-tunnel-04.txt</a><br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This last call will start today 1/31, and go =
for<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>2 weeks ending on 2/14. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This document was created in another working =
group,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>and forwarded by the Routing ADs for review =
by the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>IDR working group. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This Last call is not for the document to =
become an <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>IDR document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Please send comments to the =
list.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Sue Hares and Yakov =
Rekhter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C507AB.245A1976--

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

--===============0619640591==--

content-class: urn:content-classes:message
Subject: RE: [Idr] MInutes for IDR
Date: Fri, 28 Jan 2005 11:48:45 -0500
From: "Susan Hares" <[email-masked]>
To: "Francois Le Faucheur (flefauch)" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], Bill Fenner <[email-masked]>, Pekka Savola <[email-masked]>
Sender: [email-masked]

Francis:

Did you create an implementation report on this document? 

Sue

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Friday, January 28, 2005 11:02 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]; [email-masked]; Bill Fenner; Francois Le Faucheur (flefauch); Pekka Savola
Subject: RE: [Idr] MInutes for IDR

Hello Susan and Yakov,

If I am mistaken and we did not agree to issue Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt, could you let me know and remind me of the reasons and what needs to be done for that to happen?
If I am not mistaken and we did agree to that, could we do that Last Call?

Thank you

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 17 janvier 2005 16:39
>> To: Susan Hares
>> Cc: [email-masked]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hello Susan,
>> 
>> Did I miss the updated IDR Minutes?
>> Could we go ahead with the Last Call on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt?
>> 
>> Thanks
>> 
>> Francois
>> 
>> >> -----Original Message-----
>> >> From: Francois Le Faucheur (flefauch) 
>> >> Sent: lundi 13 décembre 2004 12:39
>> >> To: Susan Hares
>> >> Cc: [email-masked]; Francois Le Faucheur (flefauch); 
>> [email-masked]
>> >> Subject: RE: [Idr] MInutes for IDR
>> >> 
>> >> Hi Sue,
>> >>  
>> >> Comments on the minutes re bgp-tunnel:
>> >> 
>> >> 
>> >> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> >> 	---------------------------------------------------
>> >> Right spelling for my name is "Francois Le Faucheur"
>> >> I suggest listing the draft being discussed 
>> >> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> >> 
>> >> 	The draft presents a technique, which will be 
>> >> coordinated with V6OPS 
>> >> 
>> >> s/which will be/which has been/
>> >> 
>> >> 	through the ADs, for providing IPv6 service over an 
>> >> existing IPv4 MPLS 
>> >> 	cloud, without the cloud needing to be V6-aware. The 
>> >> proposed solution 
>> >> 	is intended to require no protocll extensions (see 
>> >> 
>> >> s/is intented to require no/does not require any/
>> >> 
>> >> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> >> 
>> >> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> >> above. The stamement about not requiring protocol extensions 
>> >> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> >> 
>> >> 	requiriemens are stated in 
>> >> 	 
>> >> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> >> 	 
>> >> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> >> terminology, 
>> >> 	expand on the inter-AS cases, and add additional detail 
>> >> on security.
>> >> 
>> >> There is some confusion here. The 03-->04 changes related to 
>> >> the bgp-tunnel draft (not to isp-scenario). These changes 
>> >> have already been done in bgp-tunnel-04. 
>> >> So the above should read:
>> >> "bgp-tunnel-04 includes the following changes over the 
>> >> previous version: clarify some MUST/SHOULD terminology, 
>> >> expand on the inter-AS cases, and add additional detail 
>> on security."
>> >> 
>> >> 	Publication of this specification will involve 
>> >> coordinated documents 
>> >> 	between V6OPS and IDR, consistent where possible and 
>> >> different where 
>> >> 	necessary. For example, the V6OPS document will carry 
>> >> label SAFI/AFI 
>> >> 	while the IDR document will carry VPN SAFI/AFI.
>> >> 
>> >> This paragraph mixes everything up. It should read:
>> >> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> >> global IPv6 reachability services while 
>> >> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> >> VPN services. The two documents are consistent wherever they 
>> >> can be and are only different where needed (eg bgp-tunnel 
>> >> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> >> "VPN-IPv6" AFI/SAFI).
>> >> 	 
>> >> 	After the editorial changes are complete, the document 
>> >> will go out for 
>> >> 	last call and implementation survey.
>> >> 	 
>> >> I believe what was agreed was that the document was ready 
>> >> for Last Call and the Last Call was going to be issued right 
>> >> after Wash IETF. So I suggest replacing previous paragraph 
>> >> with something like:
>> >> "The document will go out for Last Call after this meeting".
>> >> 
>> >> Thank you
>> >> 
>> >> Francois
>> >> 
>> >> 
>> 

Content-class: urn:content-classes:message
Subject: RE: [Idr] MInutes for IDR
Date: Fri, 28 Jan 2005 17:01:52 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: "Susan Hares" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>, Bill Fenner <[email-masked]>, Pekka Savola <[email-masked]>
Sender: [email-masked]

Hello Susan and Yakov,

If I am mistaken and we did not agree to issue Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt, could you let me know and remind me of the reasons and what needs to be done for that to happen?
If I am not mistaken and we did agree to that, could we do that Last Call?

Thank you

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 17 janvier 2005 16:39
>> To: Susan Hares
>> Cc: [email-masked]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hello Susan,
>> 
>> Did I miss the updated IDR Minutes?
>> Could we go ahead with the Last Call on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt?
>> 
>> Thanks
>> 
>> Francois
>> 
>> >> -----Original Message-----
>> >> From: Francois Le Faucheur (flefauch) 
>> >> Sent: lundi 13 décembre 2004 12:39
>> >> To: Susan Hares
>> >> Cc: [email-masked]; Francois Le Faucheur (flefauch); 
>> [email-masked]
>> >> Subject: RE: [Idr] MInutes for IDR
>> >> 
>> >> Hi Sue,
>> >>  
>> >> Comments on the minutes re bgp-tunnel:
>> >> 
>> >> 
>> >> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> >> 	---------------------------------------------------
>> >> Right spelling for my name is "Francois Le Faucheur"
>> >> I suggest listing the draft being discussed 
>> >> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> >> 
>> >> 	The draft presents a technique, which will be 
>> >> coordinated with V6OPS 
>> >> 
>> >> s/which will be/which has been/
>> >> 
>> >> 	through the ADs, for providing IPv6 service over an 
>> >> existing IPv4 MPLS 
>> >> 	cloud, without the cloud needing to be V6-aware. The 
>> >> proposed solution 
>> >> 	is intended to require no protocll extensions (see 
>> >> 
>> >> s/is intented to require no/does not require any/
>> >> 
>> >> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> >> 
>> >> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> >> above. The stamement about not requiring protocol extensions 
>> >> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> >> 
>> >> 	requiriemens are stated in 
>> >> 	 
>> >> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> >> 	 
>> >> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> >> terminology, 
>> >> 	expand on the inter-AS cases, and add additional detail 
>> >> on security.
>> >> 
>> >> There is some confusion here. The 03-->04 changes related to 
>> >> the bgp-tunnel draft (not to isp-scenario). These changes 
>> >> have already been done in bgp-tunnel-04. 
>> >> So the above should read:
>> >> "bgp-tunnel-04 includes the following changes over the 
>> >> previous version: clarify some MUST/SHOULD terminology, 
>> >> expand on the inter-AS cases, and add additional detail 
>> on security."
>> >> 
>> >> 	Publication of this specification will involve 
>> >> coordinated documents 
>> >> 	between V6OPS and IDR, consistent where possible and 
>> >> different where 
>> >> 	necessary. For example, the V6OPS document will carry 
>> >> label SAFI/AFI 
>> >> 	while the IDR document will carry VPN SAFI/AFI.
>> >> 
>> >> This paragraph mixes everything up. It should read:
>> >> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> >> global IPv6 reachability services while 
>> >> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> >> VPN services. The two documents are consistent wherever they 
>> >> can be and are only different where needed (eg bgp-tunnel 
>> >> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> >> "VPN-IPv6" AFI/SAFI).
>> >> 	 
>> >> 	After the editorial changes are complete, the document 
>> >> will go out for 
>> >> 	last call and implementation survey.
>> >> 	 
>> >> I believe what was agreed was that the document was ready 
>> >> for Last Call and the Last Call was going to be issued right 
>> >> after Wash IETF. So I suggest replacing previous paragraph 
>> >> with something like:
>> >> "The document will go out for Last Call after this meeting".
>> >> 
>> >> Thank you
>> >> 
>> >> Francois
>> >> 
>> >> 
>> 

Date: Thu, 27 Jan 2005 14:08:22 -0500
From: Jeffrey Haas <[email-masked]>
To: Rajesh Potti <[email-masked]>
Subject: Re: [Idr] ORF
Cc: [email-masked]
Sender: [email-masked]

Rajesh,

On Thu, Jan 27, 2005 at 01:50:28PM -0500, Rajesh Potti wrote:
> With community ORF,  if i need to deny just one community, say 1:1, and 
> accept everything else, including those routes with no communities, is 
> it possible? A wildcard is not specified in the  route-filter draft.

Once upon a draft (specifically -07 and before), the mechanism was
"this set of communities" with a scope of "normal" or "exact".

The type of policy you desire (forbid this, allow everything else) is no
longer possible.

> Rajesh

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 27 Jan 2005 13:50:28 -0500
From: Rajesh Potti <[email-masked]>
Organization: Nortel Networks
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] ORF
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Haas wrote:

>Rajesh,
>
>On Thu, Jan 27, 2005 at 01:04:58PM -0500, Rajesh Potti wrote:
>  
>
>>If the intersection is not empty, it is either denied or permitted,
>>according to the Match component. If the resulting set is empty, is the
>>route filtered.
>>    
>>
>
>And therefore an implicit deny.
>

 With community ORF,  if i need to deny just one community, say 1:1, and 
accept everything else, including those routes with no communities, is 
it possible? A wildcard is not specified in the  route-filter draft.

Rajesh

>
>  
>
>>If ORF capability for community ORF was not negotiated, the
>>route would not have been filtered.
>>    
>>
>
>And therefore an implicit permit.
>
>  
>
>>If the route is
>>Filtered on the intersection being empty, would it try to look at other ORFs
>>such as prefix list ORF or ASPATH ORF, which were negotiated.
>>    
>>
>
>:    If a BGP speaker maintains multiple ORFs of different ORF-Types for a
>:    particular peer, then the decision by the speaker to advertise a
>:    route to the peer is determined by passing the route through each
>:    such ORF, and and-ing the results (and-ing of PERMIT and DENY results
>:    in DENY).
>
>  
>
>>Rajesh
>>    
>>
>
>  
>

-- 
Rajesh Potti.

Date: Thu, 27 Jan 2005 13:24:55 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>, Alex Zinin <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: Ross Callon <[email-masked]>, [email-masked], [email-masked], [email-masked], Ronald Bonica <[email-masked]>
Sender: [email-masked]

Yakov,

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 27 Jan 2005 13:16:04 -0500
From: Jeffrey Haas <[email-masked]>
To: Rajesh Potti <[email-masked]>
Subject: Re: [Idr] ORF
Cc: [email-masked]
Sender: [email-masked]

Rajesh,

On Thu, Jan 27, 2005 at 01:04:58PM -0500, Rajesh Potti wrote:
> If the intersection is not empty, it is either denied or permitted,
> according to the Match component. If the resulting set is empty, is the
> route filtered.

And therefore an implicit deny.

> If ORF capability for community ORF was not negotiated, the
> route would not have been filtered.

And therefore an implicit permit.

> If the route is
> Filtered on the intersection being empty, would it try to look at other ORFs
> such as prefix list ORF or ASPATH ORF, which were negotiated.

:    If a BGP speaker maintains multiple ORFs of different ORF-Types for a
:    particular peer, then the decision by the speaker to advertise a
:    route to the peer is determined by passing the route through each
:    such ORF, and and-ing the results (and-ing of PERMIT and DENY results
:    in DENY).

> Rajesh

-- 
Jeff Haas 
NextHop Technologies

From: "Rajesh Potti" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>
Subject: RE: [Idr] ORF
Date: Thu, 27 Jan 2005 13:04:58 -0500
Cc: [email-masked]
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1090139849==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5049A.B6C47E14"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5049A.B6C47E14
Content-Type: text/plain

Hi Jefrrey,

 My comments inline.

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 27, 2005 11:45 AM
To: Potti, Rajesh [BL60:SF21:EXCH]
Cc: [email-masked]
Subject: Re: [Idr] ORF

Rajesh,

>From the draft:
:   The remote peer should consider only those routes whose Communities
:   attribute has at least one Community in common with the Communities
:   list specified in the ORF.

Thus, if the route has no communities, it can not have any communities in
common (at least one) with the ORF.

Put a different way, this is an set intersection operation.  If the
resulting set of the route's communities intersected with the community orf
is the empty set, it doesn't match.

If the intersection is not empty, it is either denied or permitted,
according to the Match component. If the resulting set is empty, is the
route filtered. If ORF capability for community ORF was not negotiated, the
route would not have been filtered. If the route is
Filtered on the intersection being empty, would it try to look at other ORFs
such as prefix list ORF or ASPATH ORF, which were negotiated. I mean, it
does not match any community ORF entry, but it matches a prefix-list ORF
entry from the neighbor.

Rajesh

On Mon, Jan 24, 2005 at 05:27:07PM -0500, Rajesh Potti wrote:
> 
> The draft "cooperative Route Filtering Capability for BGP-4"
> 
> (draft-ietf-idr-route-filter-11.txt) does not specify the action - 
> PERMIT or DENY, if the to be
> Advertised route  Does not have a community, or if the route has a
community
> which 
> does not match any Of the community ORF entries received. The prefix-list
> ORF filter draft 
> specifies a wildcard Match, which is not the case with the community orf.

> Rajesh

<https://www1.ietf.org/mailman/listinfo/idr> 

-- 
Jeff Haas 
NextHop Technologies

------_=_NextPart_001_01C5049A.B6C47E14
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Idr] ORF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Jefrrey,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;My comments inline.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Jeffrey Haas [</FONT><A =
HREF=3D"mailto:[email-masked]"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">mailto:[email-masked]</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Arial">] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Thursday, January 27, 2005 =
11:45 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Potti, Rajesh =
[BL60:SF21:EXCH]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [Idr] ORF</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rajesh,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From the draft:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; The remote peer should =
consider only those routes whose Communities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; attribute has at least =
one Community in common with the Communities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; list specified in the =
ORF.</FONT>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Arial">Thus, if the route has no =
communities, it can not have any communities in common (at least one) =
with the ORF.</FONT></I>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Arial">Put a different way, this is an set =
intersection operation.&nbsp; If the resulting set of the route's =
communities intersected with the community orf is the empty set, it =
doesn't match.</FONT></I></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">If the intersection is not empty, it =
is either denied or permitted, according to the Match component. If the =
resulting set is empty, is the route filtered. If ORF capability for =
community ORF was not negotiated, the route would not have been =
filtered. If the route is</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Filtered on the intersection being =
empty, would it try to look at other ORFs such as prefix list ORF or =
ASPATH ORF, which were negotiated. I mean, it does not match any =
community ORF entry, but it matches a prefix-list ORF entry from the =
neighbor.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rajesh</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Mon, Jan 24, 2005 at 05:27:07PM =
-0500, Rajesh Potti wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The draft &quot;cooperative =
Route Filtering Capability for BGP-4&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
(draft-ietf-idr-route-filter-11.txt) does not specify the action - =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PERMIT or DENY, if the to =
be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Advertised route&nbsp; Does not =
have a community, or if the route has a community</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; which </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; does not match any Of the =
community ORF entries received. The prefix-list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ORF filter draft </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; specifies a wildcard Match, =
which is not the case with the community orf.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Rajesh</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Idr mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/idr"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">https://www1.ietf.org/mailman/=
listinfo/idr</FONT></U></A>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Jeff Haas </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NextHop Technologies</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5049A.B6C47E14--

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

--===============1090139849==--

Date: Thu, 27 Jan 2005 11:45:13 -0500
From: Jeffrey Haas <[email-masked]>
To: Rajesh Potti <[email-masked]>
Subject: Re: [Idr] ORF
Cc: [email-masked]
Sender: [email-masked]

Rajesh,

>From the draft:
:   The remote peer should consider only those routes whose Communities
:   attribute has at least one Community in common with the Communities
:   list specified in the ORF.

Thus, if the route has no communities, it can not have any communities
in common (at least one) with the ORF.

Put a different way, this is an set intersection operation.  If the
resulting set of the route's communities intersected with the community
orf is the empty set, it doesn't match.

On Mon, Jan 24, 2005 at 05:27:07PM -0500, Rajesh Potti wrote:
> 
> The draft "cooperative Route Filtering Capability for BGP-4" 
> 
> (draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or
> DENY, 
> if the to be 
> Advertised route  Does not have a community, or if the route has a community
> which 
> does not match any Of the community ORF entries received. The prefix-list
> ORF filter draft 
> specifies a wildcard Match, which is not the case with the community orf.  
> 
> Rajesh

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Subject: Re: [Idr] AS deletion and reording in the AS_PATH
Date: Tue, 25 Jan 2005 11:06:26 -0500
From: Curtis Villamizar <[email-masked]>
Cc: 
Reply-To: [email-masked]
Sender: [email-masked]

A clarification.  Obviously I misread Sandy's second point in her
original email.  See below.  My mistake.

Curtis

------- Forwarded Message

Message-Id: <[email-masked]>
To: Sandy Murphy <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] AS deletion and reording in the AS_PATH 
In-reply-to: Your message of "Mon, 24 Jan 2005 17:44:04 EST."
             <[email-masked]> 
Date: Mon, 24 Jan 2005 22:57:00 -0500
From: Curtis Villamizar <[email-masked]>

In message <[email-masked]>
Sandy Murphy writes:
>  
> (Private response)
>  
> I asked:
>  
> >> Second:  would those on the list agree that any manipulation other than
> >> "prepends its own AS number" is allowed, on the basis of there being "no
> >> mention" of the alternate manipulation?
>  
> You said:
>  
> >The text says that the AS Path is updated "as follows".  It does not
> >say "as follows or in any other arbitrary way".
>  
> which would say that you did NOT AGREE that any manipulation ... is allowed

Right.  Arbitrary manipulations are not allowed.

> Then you say:
>  
> >I agree with the second point.
>  
> which says you AGREE that "any manipulation ... is allowed"

OK.  So I disagree.  Your wording got me on the first read.

> Then you say:
>  
> >The intent is to prohibit any
> >modification of the AS path, except when aggregating, other than the
> >modification specificly described above.
>  
> which would seem to imply that you do NOT AGREE that "any manipulation 
> ... is allowed

That's right.

> I'm guessing that "I agree with the second point" means "No, I would
> not agree that any manipulation ... is allowed".
>  
> But strictly speaking it doesn't say that.

That's what I meant.  Someone must have a confusing double negative in
a sentence somewhere or something but we seem to be on the same
wavelength.  Arbitrary manipulation is not intended to be allowed.

> If "I agree with the second point" means what I think it means,
> could you clarify for the list?
>  
> --Sandy

OK

Curtis

------- End of Forwarded Message

From: "Rajesh Potti" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 24 Jan 2005 17:27:07 -0500
Cc: [email-masked]
Subject: [Idr] ORF
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1377475171==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50263.2A15383E"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50263.2A15383E
Content-Type: text/plain

The draft "cooperative Route Filtering Capability for BGP-4" 

(draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or
DENY, 
if the to be 
Advertised route  Does not have a community, or if the route has a community
which 
does not match any Of the community ORF entries received. The prefix-list
ORF filter draft 
specifies a wildcard Match, which is not the case with the community orf.  

Rajesh

------_=_NextPart_001_01C50263.2A15383E
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>ORF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>The draft &quot;cooperative Route Filtering Capability for BGP-4&quot; </FONT>
</P>

<P><FONT SIZE=2>(draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or DENY, </FONT>
<BR><FONT SIZE=2>if the to be </FONT>
<BR><FONT SIZE=2>Advertised route&nbsp; Does not have a community, or if the route has a community which </FONT>
<BR><FONT SIZE=2>does not match any Of the community ORF entries received. The prefix-list ORF filter draft </FONT>
<BR><FONT SIZE=2>specifies a wildcard Match, which is not the case with the community orf.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Rajesh</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50263.2A15383E--

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

--===============1377475171==--

To: Sandy Murphy <[email-masked]>
Subject: Re: [Idr] prepending one's own AS on the AS_PATH 
Date: Mon, 24 Jan 2005 17:26:56 -0500
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Sandy Murphy writes:
>  
> On the rpsec list, Russ White has made two interesting observations.
>  
> >On searching the document for all occurances of the words: "as_path," or: 
> >"as path," I found only a few instances. The one I _believe_ is relevant is 
> >here, on page 25:
> >
> >         b) When a given BGP speaker advertises the route to an external
> >         peer, then the advertising speaker updates the AS_PATH attribute
> >         as follows:
> >
> >            1) if the first path segment of the AS_PATH is of type
> >            AS_SEQUENCE, the local system prepends its own AS number as the
> >            last element of the sequence (put it in the leftmost position
> >            with respect to the position of octets in the protocol mes-
> >            sage). If the act of prepending will cause an overflow in the
> >            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
> >            new segment of type AS_SEQUENCE and prepend its own AS number
> >            to this new segment.
> >
> >When I examine this text, I find two interesting things:
>  
> >...
>  
> >-- Second, when describing the operation of a BGP speaker, the draft 
> >doesn't say the speaker MUST prepend its own AS number as the last element 
> >of the sequence, it says it "will." In my experience, when a draft means 
> >"MUST," it uses "MUST," rather than "will." This implies the writers of 
> >this specification (if you refer to page 7, you'll find I'm listed as a 
> >contributor) believed there were valid situations when a BGP speaker would 
> >not follow the operational procedure described here.
>  
> Good catch, Russ!!!
>  
> This has been discussed many times in idr meetings.
>  
> I actually softenend the language in the vulnerabilities draft when
> talking about prepending your AS to the AS_PATH, because (I was told)
> the newest draft said that prepending your own AS on the AS_PATH was
> required.  I missed the absence of the "MUST" language.
>  
> So - was the MUST removed because there are circumstances in which one
> would not prepend one's own AS?  (Route reflectors I remember as being
> mentioned in this regard at times.)  Or was this an oversight and the
> MUST language was intended?
>  
> Note: if legitimate incoming AS_PATHs might not have the peer's AS
> appended, then the implementations can't check for this, and bogus
> AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
> of what happens if implementations don't do the checking, so I think
> there's no additional vulnerability.  It's just that the vulnerability
> would be due to design, not implementation weakness.
>  
> --Sandy

Sandy,

I don't think that was the intent at all.  The "prepends" rather than
a "MUST prepend" is an oversight.  If what Russ stated was intended
the word "SHOULD" would appear there, not "prepends".  The word "will"
is used in the phrase "If the act of prepending will cause an
overflow".  That sentence contains a "SHOULD".

In practice, removing duplicates might be an alternative here (where
som other AS has done AS padding to affect AS path length).  Dropping
the advertisement would be another alternative.  If the "SHOULD" is
violated, as in all cases where SHOULD is specified, it may be at some
peril.  Care is advised.

Curtis

To: Sandy Murphy <[email-masked]>
Subject: Re: [Idr] AS deletion and reording in the AS_PATH 
Date: Mon, 24 Jan 2005 17:18:13 -0500
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Sandy Murphy writes:
>  
> On the rpsec list, Russ White has made two interesting observations.
> The first concerns deleting or reordering the AS's in an AS_PATH when
> creating the AS_PATH for an UPDATE:
>  
> >On searching the document for all occurances of the words: "as_path," or: 
> >"as path," I found only a few instances. The one I _believe_ is relevant is 
> >here, on page 25:
> >
> >         b) When a given BGP speaker advertises the route to an external
> >         peer, then the advertising speaker updates the AS_PATH attribute
> >         as follows:
> >
> >            1) if the first path segment of the AS_PATH is of type
> >            AS_SEQUENCE, the local system prepends its own AS number as the
> >            last element of the sequence (put it in the leftmost position
> >            with respect to the position of octets in the protocol mes-
> >            sage). If the act of prepending will cause an overflow in the
> >            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
> >            new segment of type AS_SEQUENCE and prepend its own AS number
> >            to this new segment.
> >
> >When I examine this text, I find two interesting things:
> >
> >-- First, there is no mention of any conditions under which information may 
> >be removed from the AS Path, or the AS Path is reordered. I believe, based 
> >on reading of the specification (without outside reference to operational 
> >or implementation experience), this means the AS Path may be reordered, or 
> >information may be removed from the AS Path. Let me at least say neither of 
> >these are strictly prohibited.
>  
>  
> First: would those on the list agree that deleting or reordering the AS's
> in an AS_PATH is an OK thing to do?
>  
> Second:  would those on the list agree that any manipulation other than
> "prepends its own AS number" is allowed, on the basis of there being "no
> mention" of the alternate manipulation?
>  
> --Sandy

The text says that the AS Path is updated "as follows".  It does not
say "as follows or in any other arbitrary way".

The reality has always been that violations of the spec do occur when
someone considers it in their interest to do so and when it doesn't
mess up interoperability or cause operational problems.  The IETF
doesn't have any means of enforcement and that's probably a good thing.

Chopping the middle could create loops.  Reordering probably doesn't
have any adverse consequence unless someone else policy is based on a
sequence of AS in a particular order.  Since it has a negative
consequence and no benefit, reordering is at the very least a bad
idea.

Therefore deleting is definitely a bad thing to do.  Reordering is
also a bad thing to do.

I agree with the second point.  The intent is to prohibit any
modification of the AS path, except when aggregating, other than the
modification specificly described above.

Curtis

Date: Mon, 24 Jan 2005 13:00:34 -0800
From: Robert Raszuk <[email-masked]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Sandy Murphy <[email-masked]>
Subject: Re: [Idr] prepending one's own AS on the AS_PATH
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

An interesting observation is that the latest draft does not prohibit 
one from also prepending someone else's AS# to the AS_PATH. In fact on 
one of the past RIPE meetings I saw a very interesting presentation from 
William Norton where he showed what kind of tricks folks do with AS_PATH 
to get a better peering agreements ;).

http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-art-peering/

Cheers,
R.

 > Sandy Murphy wrote:
 >
> On the rpsec list, Russ White has made two interesting observations.
> 
> 
>>On searching the document for all occurances of the words: "as_path," or: 
>>"as path," I found only a few instances. The one I _believe_ is relevant is 
>>here, on page 25:
>>
>>        b) When a given BGP speaker advertises the route to an external
>>        peer, then the advertising speaker updates the AS_PATH attribute
>>        as follows:
>>
>>           1) if the first path segment of the AS_PATH is of type
>>           AS_SEQUENCE, the local system prepends its own AS number as the
>>           last element of the sequence (put it in the leftmost position
>>           with respect to the position of octets in the protocol mes-
>>           sage). If the act of prepending will cause an overflow in the
>>           AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>>           new segment of type AS_SEQUENCE and prepend its own AS number
>>           to this new segment.
>>
>>When I examine this text, I find two interesting things:
> 
> 
>>...
> 
> 
>>-- Second, when describing the operation of a BGP speaker, the draft 
>>doesn't say the speaker MUST prepend its own AS number as the last element 
>>of the sequence, it says it "will." In my experience, when a draft means 
>>"MUST," it uses "MUST," rather than "will." This implies the writers of 
>>this specification (if you refer to page 7, you'll find I'm listed as a 
>>contributor) believed there were valid situations when a BGP speaker would 
>>not follow the operational procedure described here.
> 
> 
> Good catch, Russ!!!
> 
> This has been discussed many times in idr meetings.
> 
> I actually softenend the language in the vulnerabilities draft when
> talking about prepending your AS to the AS_PATH, because (I was told)
> the newest draft said that prepending your own AS on the AS_PATH was
> required.  I missed the absence of the "MUST" language.
> 
> So - was the MUST removed because there are circumstances in which one
> would not prepend one's own AS?  (Route reflectors I remember as being
> mentioned in this regard at times.)  Or was this an oversight and the
> MUST language was intended?
> 
> Note: if legitimate incoming AS_PATHs might not have the peer's AS
> appended, then the implementations can't check for this, and bogus
> AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
> of what happens if implementations don't do the checking, so I think
> there's no additional vulnerability.  It's just that the vulnerability
> would be due to design, not implementation weakness.
> 
> --Sandy
> 

Date: Mon, 24 Jan 2005 13:01:50 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] prepending one's own AS on the AS_PATH
Sender: [email-masked]

On the rpsec list, Russ White has made two interesting observations.

>On searching the document for all occurances of the words: "as_path," or: 
>"as path," I found only a few instances. The one I _believe_ is relevant is 
>here, on page 25:
>
>         b) When a given BGP speaker advertises the route to an external
>         peer, then the advertising speaker updates the AS_PATH attribute
>         as follows:
>
>            1) if the first path segment of the AS_PATH is of type
>            AS_SEQUENCE, the local system prepends its own AS number as the
>            last element of the sequence (put it in the leftmost position
>            with respect to the position of octets in the protocol mes-
>            sage). If the act of prepending will cause an overflow in the
>            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>            new segment of type AS_SEQUENCE and prepend its own AS number
>            to this new segment.
>
>When I examine this text, I find two interesting things:

>...

>-- Second, when describing the operation of a BGP speaker, the draft 
>doesn't say the speaker MUST prepend its own AS number as the last element 
>of the sequence, it says it "will." In my experience, when a draft means 
>"MUST," it uses "MUST," rather than "will." This implies the writers of 
>this specification (if you refer to page 7, you'll find I'm listed as a 
>contributor) believed there were valid situations when a BGP speaker would 
>not follow the operational procedure described here.

Good catch, Russ!!!

This has been discussed many times in idr meetings.

I actually softenend the language in the vulnerabilities draft when
talking about prepending your AS to the AS_PATH, because (I was told)
the newest draft said that prepending your own AS on the AS_PATH was
required.  I missed the absence of the "MUST" language.

So - was the MUST removed because there are circumstances in which one
would not prepend one's own AS?  (Route reflectors I remember as being
mentioned in this regard at times.)  Or was this an oversight and the
MUST language was intended?

Note: if legitimate incoming AS_PATHs might not have the peer's AS
appended, then the implementations can't check for this, and bogus
AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
of what happens if implementations don't do the checking, so I think
there's no additional vulnerability.  It's just that the vulnerability
would be due to design, not implementation weakness.

--Sandy

Date: Mon, 24 Jan 2005 12:47:36 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] AS deletion and reording in the AS_PATH
Sender: [email-masked]

On the rpsec list, Russ White has made two interesting observations.
The first concerns deleting or reordering the AS's in an AS_PATH when
creating the AS_PATH for an UPDATE:

>On searching the document for all occurances of the words: "as_path," or: 
>"as path," I found only a few instances. The one I _believe_ is relevant is 
>here, on page 25:
>
>         b) When a given BGP speaker advertises the route to an external
>         peer, then the advertising speaker updates the AS_PATH attribute
>         as follows:
>
>            1) if the first path segment of the AS_PATH is of type
>            AS_SEQUENCE, the local system prepends its own AS number as the
>            last element of the sequence (put it in the leftmost position
>            with respect to the position of octets in the protocol mes-
>            sage). If the act of prepending will cause an overflow in the
>            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>            new segment of type AS_SEQUENCE and prepend its own AS number
>            to this new segment.
>
>When I examine this text, I find two interesting things:
>
>-- First, there is no mention of any conditions under which information may 
>be removed from the AS Path, or the AS Path is reordered. I believe, based 
>on reading of the specification (without outside reference to operational 
>or implementation experience), this means the AS Path may be reordered, or 
>information may be removed from the AS Path. Let me at least say neither of 
>these are strictly prohibited.

First: would those on the list agree that deleting or reordering the AS's
in an AS_PATH is an OK thing to do?

Second:  would those on the list agree that any manipulation other than
"prepends its own AS number" is allowed, on the basis of there being "no
mention" of the alternate manipulation?

--Sandy

To: [email-masked]
Date: Mon, 17 Jan 2005 07:52:37 -0800
From: Yakov Rekhter <[email-masked]>
Cc: Ross Callon <[email-masked]>, Ronald Bonica <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Sender: [email-masked]

Folks,

Yakov.

Content-class: urn:content-classes:message
Subject: RE: [Idr] MInutes for IDR
Date: Mon, 17 Jan 2005 16:39:14 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: "Susan Hares" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Hello Susan,

Did I miss the updated IDR Minutes?
Could we go ahead with the Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt?

Thanks

Francois

>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) 
>> Sent: lundi 13 décembre 2004 12:39
>> To: Susan Hares
>> Cc: [email-masked]; Francois Le Faucheur (flefauch); [email-masked]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hi Sue,
>>  
>> Comments on the minutes re bgp-tunnel:
>> 
>> 
>> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> 	---------------------------------------------------
>> Right spelling for my name is "Francois Le Faucheur"
>> I suggest listing the draft being discussed 
>> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> 
>> 	The draft presents a technique, which will be 
>> coordinated with V6OPS 
>> 
>> s/which will be/which has been/
>> 
>> 	through the ADs, for providing IPv6 service over an 
>> existing IPv4 MPLS 
>> 	cloud, without the cloud needing to be V6-aware. The 
>> proposed solution 
>> 	is intended to require no protocll extensions (see 
>> 
>> s/is intented to require no/does not require any/
>> 
>> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> 
>> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> above. The stamement about not requiring protocol extensions 
>> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> 
>> 	requiriemens are stated in 
>> 	 
>> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> 	 
>> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> terminology, 
>> 	expand on the inter-AS cases, and add additional detail 
>> on security.
>> 
>> There is some confusion here. The 03-->04 changes related to 
>> the bgp-tunnel draft (not to isp-scenario). These changes 
>> have already been done in bgp-tunnel-04. 
>> So the above should read:
>> "bgp-tunnel-04 includes the following changes over the 
>> previous version: clarify some MUST/SHOULD terminology, 
>> expand on the inter-AS cases, and add additional detail on security."
>> 
>> 	Publication of this specification will involve 
>> coordinated documents 
>> 	between V6OPS and IDR, consistent where possible and 
>> different where 
>> 	necessary. For example, the V6OPS document will carry 
>> label SAFI/AFI 
>> 	while the IDR document will carry VPN SAFI/AFI.
>> 
>> This paragraph mixes everything up. It should read:
>> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> global IPv6 reachability services while 
>> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> VPN services. The two documents are consistent wherever they 
>> can be and are only different where needed (eg bgp-tunnel 
>> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> "VPN-IPv6" AFI/SAFI).
>> 	 
>> 	After the editorial changes are complete, the document 
>> will go out for 
>> 	last call and implementation survey.
>> 	 
>> I believe what was agreed was that the document was ready 
>> for Last Call and the Last Call was going to be issued right 
>> after Wash IETF. So I suggest replacing previous paragraph 
>> with something like:
>> "The document will go out for Last Call after this meeting".
>> 
>> Thank you
>> 
>> Francois
>> 
>>