Hi Les,
> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > Tony – > > OLD: > 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV > > 2)Inside Node TLV - Top level TLV > > 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs: > Sub-TLV Area Proxy System ID > Sub-TLV Area Segment SID > > 4)Area Segment SID - Top Level TLV > > NEW: (Please check my interpretation) > > 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV > > 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs: > Sub-TLV Area Proxy System ID > Sub-TLV Area Segment SID > Sub-TLV Inside Node ??? > > 3)Area Segment SID - Top Level TLV > > Am I correct so far?? Yes, exactly. Inside node would be a sub-TLV or a flag, TBD. > If so, a couple more comments/suggestions: > > a)Could the Area Proxy TLV become a bit more generic and allow advertisement > of the capability (implied by presence of the TLV)? > If so, the Router Capability sub-TLV could go away. Speaking just for myself, ok, that seems reasonable and doable. > b)If the Area Segment SID is (as you suggest) a generic thing not specific to > Area Proxy, then I would point you to > https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1 > <https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1> ? Your pointer is to the flags field of the SID/Label Binding TLV. > This allows SIDs to be advertised in the SID Binding TLV for a special > purpose (see the Mirror SID). One could imagine another flag bit to indicate > this is an Area SID. You’re suggesting a bit in the flags, the range would be unused, and a prefix length of 0? Then the actual SID would be in the SID/Label sub-TLV? > I think this would need to be vetted with SR folks That will happen, regardless of how we proceed. > – but I would like to avoid advertising a SID in a way different from all > other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – > whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), > or Binding SID (Mirror SID). We were trying to extend the current design consistently with existing SIDs. As the Prefix SID and Adjacency SID were top level, it made sense to continue that approach. The approach of the Binding SID TLV would seem to mix all semantics into one encoding and seems inconsistent and complicated with respect to the other SIDs. If this was the intent, shouldn’t prefix and adjacency SIDs be encoded in this TLV as well? There’s only three available bits (plus one octet) here. Aren’t we concerned about running out of bits if we go this direction? Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
