Subject: [Idr] FW: idr minutes

From: "Susan Hares" <[email-masked]>
Date: Fri, 8 Aug 2003 09:59:20 -0400

IETF 57 IDR Minutes
Chairs: Yakov Rekhter, Sue Hares

ID Document Status (chairs)
------------------
- Base Spec done! Will post -21 after IETF.
- See slides

Avoid BGP Best Path Transition From one External to Another
	      draft-chen-bgp-avoid-transition-00.txt
-----------------------------------------------------------
-  BGP identifier used in last phases of BGP routes selection
-  Appear random
-  Subject to change
-  Reduces stability
-  Proposed solution: Don't eliminate either path due to BGP ID during path
selection
-      Exception: AS Confederations; parallel sessions
- Advantages: stability, reduce iBGP oscillation

- Request to adopt as WG draft, but WG is in closed status until base doc is
approved

Advertising Equal Cost Multipath Routes in BGP
              draft-bhatia-ecmp-routes-in-bgp-00
-------------------------------------------------
- Route reflector only advertises route that it installs
- May not be optimal for all RR clients or external peers
- May lead to route oscillation
- Advertise two paths to destination
- Proposal: ECMP-NEXT-HOP attribute
     If specified, second advertisement is not

CHEN: I don't think that this is adequate to prevent route oscillation.
Bhatia: It will because multiple paths are advertised
CHEN: How is this different from last presentation
Bhatia: Don't need to change encoding
CHEN: Advertising best external route also solves oscillation problem.
Without changing spec.
Marques: Draft should be named "How to advertise multiple paths in BGP".
Look at Alvero's draft.
Yakov: Also look at how MP-BGP addresses this

BGPv4 SAFI-Specific Attribute
              draft-kapoor-nalawade-idr-bgp-ssa-00
The Tunnel SAFI
              draft-nalawade-kapoor-tunnel-safi-00
--------------------------------------
- Exchange tunnel endpoint information
- avoid o(n^2) configuration problem
- Proposal: Use BGP to advertise tunnel endpoints
-          SAFI specific Attribute carries tunnel attributes
- SAFI specific attribute value contains TLVs
- TLV context determined by type field
- Negotiated capability

Hares: Whats the cookie for
kapoor: Its defined in l2tpv3.
Yakov: Need discussion on mailing list. Unbundle SAFI discussion from
discussion of whether we need a new attribute.
Yakov: How do we control type codes?
Kapoor: Options - IANA, WG consensus; we can talk about it
Yakov: Do you have concept of transitive or non-transitive TLV
Kapoor: Attribute is transitive. All TLV inherit.

Multiprotocol Next Hop Attribute
              draft-lefaucheur-mp-nh-00
--------------------------------------------
- need to advertise next hop different from AF of NLRI
- may need to advertise multiple next-hops for a prefix
- may need to advertise next-hop specific parameters (e.g., label per nh).

Yakov: Motivations; load balancing, v4 over v6. There are existing apps
where encoding of NLRI and Next hop are different.
Gargi: If we wanted to load balance across two next hops of different
type, we could not.

iBGP Auto Mesh
              draft-raszuk-idr-ibgp-auto-mesh-00
-----------------------
- motivation: Autodiscover iBGP peers
- flood BGP config via IGP
     bgp autodiscover TLV flooded in IGP
- no change to BGP machinery

Dave Ward: What happens during graceful restart?
Robert: We don't reflood if configuration is not changing
Chen: Does it help much if iBGP congig is not big
How will you carry MD5 key.
Robert: MD5 keys will be same for all speakers.
Chen: How does this work for RR clients
Robert: cluster id on client
Parantap: We do static config. If you miss one, it really bad. We don't need
this. We don't encourage you to touch ISIS.

Signalling tunneling Encaps
---------------------------
               draft-raggarwa-ppvpn-tunnel-encap-sig-01

- Mechanism for signaling PE tunnel encap capabilities.

- Motivations:

 o Blackhole Avoidance
 o Co-existing MPLS & IP encap

-BGP Tunnel Capability SAFI
-LDP Tunnel Encap Capabilities (may not be necessary per BGP)IANA
Considerations

Alex: The BGP specific part needs to belong in IDR

Dave: You will work together with Gargi
Rahul: Yes

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"If a man marches out of step with his
fellows it may be that he hears the sound
of a different drummer or, perhaps that
he has a poor sense of rhythm."
            -- Henry David Thoreau

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

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 13 Aug 2003 17:21:39 +0530

Checking mails after some gap ..

> Bhatia: Don't need to change encoding

I thought he was talking of Alvaro's draft and hence i said "No need to
change the encoding".

This proposal is very different from the previous presentation. In the
previous there isnt any way to advertise multiple paths. The central idea
being that the tie breaking should never reach the point where the RIDs are
compared.

> Yakov: Also look at how MP-BGP addresses this

The ECMP_NEXT_HOP attribute already has the AFI field. Just need to add a
SAFI field.

All subsequent UPDATEs with the ECMP_NEXT_HOP attribute carrying the <AFI,
SAFI> will not be treated as implicit withdrawals and will instead be
appended to the existing RIB. There is thus no special treatment required
for MP-BGP.

Regards,
Manav

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 13 Aug 2003 17:21:39 +0530

Regards,
Manav