Hi Zhibo, Thanks for the input, I like the encoding proposed by you. I will discuss this with my co-authors; IMHO any existing implementation would require to be change when code-point is allocated so a change of format of the TLV should not be a deal breaker for any implementation out in the field.
I think we should also update the document to include a SRv6 binding type. Thanks! Dhruv From: Pce [mailto:[email protected]] On Behalf Of Huzhibo Sent: 07 January 2019 17:04 To: [email protected]; [email protected] Subject: Re: [Pce] Fwd: PCE-BSID Question to the List Hi Jeff, I think this extension is important. Please see my reply inline. Thanks, Zhibo From: Pce [mailto:[email protected]] On Behalf Of Jeff Tantsura Sent: Wednesday, November 07, 2018 10:19 AM To: [email protected]<mailto:[email protected]> Subject: [Pce] Fwd: PCE-BSID Question to the List Dear PCE, Following our presentation in Bangkok, https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-23-binding-segment-00.pdf The authors would like to ask the WG the following: (1) Do we link the Binding SID to the PCEP SR capability? Currently we can assign BSID for RSVP-TE LSP as well. [Zhibo]Yes, it is important, I could think of few use cases-> “domain stitching”,” solving MSD limits” and “interworking b/w MPLS and SRv6 domains” by PCE (2) Is WG happy with TE-PATH-BINDING TLV format? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Type (BT) | Binding Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Binding Value (continued) (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Zhibo] I prefer the length of BT field is 8 bits, and adding 24 reserved bits for future features, such as flag or something else. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Binding Value (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This encoding of BSID is similar to BGP [https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2] that works for both SR-MPLS and SRv6. When length is 8, then the binding Value is a MPLS label, when length is 20, the binding value is a SRv6 SID. Figure 2: TE-PATH-BINDING TLV (3) Is there a use case for binding value as “index” in SRGB/SRLB? [Zhibo] I think there is no use case for binding value as “index” in SRLB, cause BSID may not be a global label. Thanks! Cheers, Jeff
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
