Subject: [Idr] IETF 65 wg minutes

From: Andrew Lee <[email-masked]>
Date: Thu, 23 Mar 2006 13:28:28 -0600

Please let me know if there are any corrections or additions.

Thanks
Andrew

--

IDR Working Group minutes
IETF 65
Wednesday March 22 2006
0900-1130

Scribe drafting

Document Status report

draft-levy-idr-6pe-survey-00.txt
6PE Implementation Report - Francois Le Faucheur
  Cisco and Juniper implementations
   basic tests show they are interoperable
   Cisco - arbitrary label
   Juniper - explicit NULL label
  next step:
    let implementation report expire
    move 6PE toward RFC status

Acee Lindem: Why not publish implementation report as informational?
  A: The expired draft will be archived on the IETF and still serve
     as a reference

--

draft-bhatia-bgp-multiple-next-hops-00.txt
Advertising Multiple Nexthop Routes in BGP - Joel Halpern
  Advertising Multiple NextHops Routes in BGP
  base mechanism
   need to add extra info to withdraw so you know which you are removing
  ecmp case
   seperated into different draft now
   advertise multiple paths to be used to multipath capable peers
  ebgp case
   compress as path
    possible algorithm in draft, others acceptable if the length and
    info is preserved

Dino Farinacci: Requested clarification about aspath and method of encoding
  A: We need to preserve all the ASs that appeared, as well as length
     We would like to preserve structure, but maybe thats not essential
     ECMP, by definition, must have equal as paths

Christina Radulescu-banu: How do i encode MPLS information
  A: If using bgp to carry MPLS labels, and doing multipath,
     yes the label can be next hop in the case where as path is different.
     But if you have multiple next hop with same AS path,
     you cannot right now due to proposed update packet structure.
     We can revisit this with wg, and maybe add to draft.

---

draft-zhang-idr-bgp-entire-routes-reflect-02
Entire Routes Reflecting capability - Zhang Renhai
  new capability to be negotiated between RR and client
  RR can send multiple routes to client
  no new attribute, send seperate update for each route
  process changes
   implicit withdraw
    prefix and next hop are same as existing route
   explicit withdraw
    next hop information must be provided
  update packet change
   add next_hop to packet
  other address family -  MP_UNREACH_NLRI attribute
   add next hop info (length + network address)
  how to deal with change of next hop
  multiple multiple path proposals
   all still in develepoment
  next:
   cover more applications
    rebuild draft?

Matt Meyer: With regard to other applications, there is a lack of information
             in netflow that can lead to incorrect information
  A: ingress traffic, but outbound policy doesnt match netflow will mislead
     could be gotten around by having nonbest learned routes reflected to
     netflow device

Presentations will be posted to IETF web site

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

---

From: Dana Blair <[email-masked]>
Date: Thu, 23 Mar 2006 15:48:57 -0500

>     could be gotten around by having nonbest learned routes reflected 

Can someone provide more detail on this discussion ?  I'm trying to 
understand
how netflow is related to the draft.

thanks,
Dana