Subject: Re: [Idr] IETF 65 wg minutes

From: zhangrenhai 18605 <[email-masked]>
Date: Fri, 24 Mar 2006 11:13:21 +0800

Hi,

Good job.

Hi, Matt Meyer,I am appreciate your advise, if you like, contact me, 
I'd like to discuss more about the applications, 
anyone else are also welcome. 

Thanks,

Zhang Renhai

----- Original Message -----
From: Andrew Lee <[email-masked]>
Date: Friday, March 24, 2006 3:28 am
Subject: [Idr] IETF 65 wg minutes

> 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
> 

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