> On Jun 30, 2020, at 2:33 AM, tony...@tony.li wrote: > > > Hi all, > > The authors are on-board with this round of suggestions from Les. Could I > get a review by one more of our Designated Experts before we update the draft?
So: - Top Level Area Proxy TLV - can be used to communicate area proxy capability - can be used to communicate inside node trait - can be used to communicate area proxy system id - Re-use existing SPRING TLVs to communicate Area SID and the early request would be for a single top-level area proxy TLV code-point? If so, then it aligns with my earlier [wg hat] suggestion as well, and so looks good to me [de hat]. :) Thanks, Chris. [DE/WG member hats] > > Thanks, > Tony > > >> On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> wrote: >> >> Tony – >> >> Inline. >> >> From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li >> Sent: Monday, June 29, 2020 2:37 PM >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> Cc: Hannes Gredler <han...@gredler.at>; >> draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org >> Subject: Re: [Lsr] Comments on Requested Codepoints for >> draft-li-lsr-isis-area-proxy >> >> >> >> 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 >> >> >> ? Your pointer is to the flags field of the SID/Label Binding TLV. >> >> [Les:] Yes – as the suggestion would be to add another flag definition. >> >> >> 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? >> >> [Les:]Range could be specified as ignored in this case. Prefix length would >> be 0. >> The SID would be – as you say – advertised in the SID/Label sub-TLV – as >> with all other SIDs. >> >> >> 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? >> [Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively. >> >> There’s only three available bits (plus one octet) here. Aren’t we >> concerned about running out of bits if we go this direction? >> [Les:] I am not. It is a question of whether SR sees this as a useful type >> of SID. If so, it merits a bit. >> >> Les >> >> Tony > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
