Jeffrey:
The assumptions in the following email: https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/ are based on past assumptions. The BESS, IDR, and PIM WG Chairs have agreed to a joint WG adoptions to gain input from these 3 WGs into cohesive solutions. Therefore, let's focus on the technologies in this adoption. Please repost your draft: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/ I have extended the WG adoption call so that you can repost this draft. Please repost on 4/5 or 4/6. Without a repost of your draft, I will close the WG adoption call. My next posts will focus on the technical based on the following assertions you made in You indicated in https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/ "When it comes to SR-P2MP state downloading, there are three aspects involved here: 1. NLRI to encode policy information 2. NLRI to encode <tree/path/instance, node> identification 3. Tunnel Encapsulation Attribute (TEA) that encodes actual replication branches The draft-ietf-bess-(even when used for SR-P2MP) is aligned with other non-SR multicast trees (IP/mLDP) for a unified approach, while draft-hb is aligned to unicast BGP SR policy." Sue Hares
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
