Subject: [Idr] MInutes for IDR

From: "Susan Hares" <[email-masked]>
Date: Fri, 10 Dec 2004 11:25:03 -0500

Please send in comments on the minutes for IETF 61.

Sue

 

Sue Hares and Yakov Rekhter co-chaired the meeting. Yakov issued an 

initial OPEN, but a transmission failure of the microphone system 

caused his transport entity to time out. He retransmitted the OPEN and 

successfully peered with the attendees.

Old Business

------------

Sue reviewed the status of the core BGP documents under revision: 

 - Border Gateway Protocol 4 (BGP-4) 

 - Definitions of Managed Objects for the Fourth Version of 

   Border Gateway Protocol (BGP-4) 

 - BGP-4 Protocol Analysis 

 - BGP Security Vulnerabilities Analysis 

 - Experience with the BGP-4 Protocol 

 - BGP MIB V1 implementation survey 

 - BGP 4 Implementation Report

There is no new internal WG progress or action 

required; these are awaiting IESG review.

Also in the approval process are Graceful Restart and Extended 

Communities, both as Proposed Standards, and Cease Subcodes, to be a 

Draft Standard.

The IESG is waiting for an implementation report on confederations.

There was nothing to report on cooperative route filtering, 4-octet AS 

numbers, AS-based ORF, MIB 2, and AS-wide identifiers.

New Business

------------

Equal Cost Multipath (Manav Bhatia, Joel Halpern)

-------------------------------------------------

This was a working report on differences, not a final. The problem 

that the ECMP proposal intends to solve is defining a mechanism by 

which an implementation that installs equal cost multipath routes, but 

only advertises one route, can readvertise the multiple routes without 

breaking policies. Its basic approach is to create synthetic AS-SETS 

in the readvertisements.

Potential benefits of the technique include avoiding certain cases of 

route reflector oscillation. The technique is consistent with 

multiprotocol extensions, using the AFI/SAFI relevant to the routes it 

is advertising: conventional IPv4 or VPN.  It is not intended for load 

splitting across different AS.

The consensus was that not enough WG members had read it for consensus.

IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)

---------------------------------------------------

The draft presents a technique, which will be coordinated with V6OPS 

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 

draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 

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.

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.

After the editorial changes are complete, the document will go out for 

last call and implementation survey.

AS Edge Confederations (Sue Hares)

----------------------------------

This was a discussion item; the I-D did not make the cutoff. The 

technique described is a method for using dynamic capabilities at the 

edge of AS confederations, with the confederation-AS typically in a 

ring topology. The example was given of a confederation of 

satellite-based confederation AS being accessed by an earth station.

While the technique both is ad hoc and involves mobility, it is 

different in applicability from MANET and mobile IP, since its quantum 

of mobility is the AS, not either subnet or host.

This would typically be used in a low-bandwidth applkication where the 

edge (i.e., non-confederation) AS lose connectivity with one AS in the 

ring, but transfer connectivity to a differfent confederation-AS, 

using dynamic capabilities exchange. As operational requirements 

dictate, the non-confederation AS might switch back to the original 

upstream AS.  Additional security may be required for this 

application.

Discussion followed.

John Scudder ():  If you expect this change, why wait for dynamic 

                  capabilities? Why not configure immediately?

Sue: We don't want to drop the associated peers

Peter Lothberg: Why not use an IGP? Sue answered that an IGP gives 

                insufficient policy control.

John Scudder:  Pointed out that you cannot nest confederations, 

               limitiing applicability. Sue reitierated this is neither
MANET nor 

               mobile IP.

Chandra -- is confederation AS too small a level 

      of granularity? He asked why there could be additional security 

      requirements, and Sue pointed out that TCP neither encrypts nor 

      authenticates, and regular BGP security may be insufficient for
some 

      tactical applications.

Peter Lothberg:  Is the policy for inter-AS links, AS, or AS 

                 confederation? WHat is the requirement?  Sue replied
the policy was 

                 for the confederation.

Russ White:  Suggested avoided the security  cookie. He felt it might 

             be too ad hoc, and a general solution would be better.

John Scudder: agrees ad hoc may not be desirable -- worried about cloned
AS.

Parantep (MCI): "neither confirm or deny IGP is aware", agreed to 

                   by Sue. Application may involve multiple IGP.

Peter Lothberg:  Asked Sue to confirm this proposal is to solve a real 

                 problem, not just to demonstrate what could be done.

Dampening

---------

Sue suggested there be WG list discussion of updates.

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

---

From: "Bhatia, Manav" <[email-masked]>
Date: Sun, 12 Dec 2004 22:49:22 -0800

Hi,

> Equal Cost Multipath (Manav Bhatia, Joel Halpern)

[clipped]

> splitting across different AS.

This is incorrect. It *is* intended for load splitting across different ASes.

Manav

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Mon, 13 Dec 2004 12:38:52 +0100

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/

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.

	 
	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