Chris,
Thank you for your comments. We will figure out how we would like to proceed. Thanks, Tony > On Jun 24, 2020, at 5:17 PM, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Jun 21, 2020, at 12:50 PM, tony...@tony.li wrote: >> >> >> Les, >> >>> We don’t have to resolve this now. >>> One of my motivations for sending this was related to Early Allocation of >>> code points. Since you have already asked once, I am assuming that if WG >>> adoption is achieved it will be swiftly followed by an early allocation >>> request – and as one of the Designated Experts I wanted to share my >>> concerns sooner rather than later. >> >> >> I appreciate that. Do others share Les’ perspective on the relative >> tradeoffs? Especially our other Desginated Experts? > > [Designated Expert hat] > > I agree that we should try and reduce the number of top-level TLV allocations > being made here. > > [WG member hat] > > I think using router capabilities to eliminate the Area Proxy TLV is one > choice, and you shouldn't be afraid of storing some capability related extra > octets in it, plenty of other users do this already. > > However, if you're still going to need a top-level TLV for "Inside Node" > (perhaps b/c we fear using a Router Capability TLVs in pseudo-node?), then > why not create a single top level "Area Proxy TLV" for all Area Proxy uses > (i.e., make the current "Area Proxy TLV" and "Inside Node TLV" sub-TLVs of > that top-level container) instead? > > Thanks, > Chris. > [see above for hats] > >> >> >>> Would this argue for advertising “this is a boundary circuit” in >>> pseudo-node LSPs for boundary circuits rather than advertising “inside” on >>> all inside pseudo-nodes? >>> >>> You could do it that way. It inverts the semantics and inverts the >>> deployment. Logically, it should have the same effect. However, it then >>> is seen by outside nodes. Since they need not support Area Proxy, this >>> seemed like a riskier approach, thus we opted for marking inside >>> pseudonodes. >>> >>> [Les:] My point was largely motivated by the statement in the draft: >>> >>> “Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN >>> mode) with multiple Inside Edge Routers on them are not supported.” >>> >>> So it seems advantageous to be able to prevent this from happening – which >>> requires some signaling on the circuit in question. >> >> >> >> I think that the case that you’re concerned about is already easily >> detected. Recall that an Inside Edge router will generate IIH’s onto a >> boundary circuit using the Proxy system ID. Thus, if an Inside Edge router >> receives an IIH with a source address of it’s own proxy system id, then it >> has encountered this issue. >> >> Tony >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
