Aijun - From: Lsr <lsr-boun...@ietf.org> On Behalf Of Aijun Wang Sent: Thursday, January 13, 2022 6:45 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: 'Peter Psenak' <ppsenak=40cisco....@dmarc.ietf.org>; 'Christian Hopps' <cho...@chopps.org>; lsr-cha...@ietf.org; 'Tony Li' <tony...@tony.li>; 'lsr' <lsr@ietf.org>; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi, Les: From: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Sent: Friday, January 14, 2022 9:18 AM To: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org<mailto:ppsenak=40cisco....@dmarc.ietf.org>>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 Aijun – In my first post on this thread I indicated that I thought RFC 5316 is sufficient for the use cases described in this draft. The subsequent lengthy discussions on this thread has convinced me that RFC 5316 is indeed sufficient and there is no need for this draft. Along the way some issues discussed were: The requirement of RFC 5316 that AS # be advertised. It is true that in some of the use cases you won’t have an AS #, but this can be addressed by using one of the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has been resolved. [WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 Remote ASBR ID sub-TLV. And, you may propose we can assign other specific IPv4/IPv6 Remote ASBR ID. Not mentioned the unnecessary configuration on such kind links, the IGP will also advertise such useless information for each boundary link. Considering also what the Robert has mentioned scenario(the product of (# of PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information will be advertised within the IGP? Why we must limit our deployment to the guideline of unsuitable RFCs? [LES:] The ASBR ID is simply the router ID of the peer at the remote end of the link. You need to know this in order to identify the peer since you do not have a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the IGP were enabled on the link. So there is no reason that this information should be bogus. You continue to promote the need to use a new sub-TLV to advertise a link type – but there is no demonstrated need for this nor any description of how such information would be used. (I say this even after reading your responses below.) [WAJ] It is the field within the Stub-Link TLV, not new sub-TLV. It is not like the Link Type Sub-TLV that defined in https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1. If you view them from the controller POV(the consumer of the BGP-LS information), you may know the below responses well. [LES:] I called it a sub-TLV because that’s what it was in the previous version of the draft – before you invented a new top level TLV to avoid using TLV 141. But regardless of the encoding details, my point is this information is not useful and not needed. There is no reason to advertise a loopback interface as a link. And there is no value in knowing whether the non-loopback link is a VLAN or top level ethernet or some type of P2P media. I have asked repeatedly of what use this information is and you have failed to provide any answer. You also continue to promote the need to use an RFC 5316 like TLV to advertise the address of loopbacks – but again there is no need. The prefix associated with a loopback is advertised in Prefix Reachability TLVs. That the prefix is associated with a loopback is identified by the presence of the N flag in the associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback is identified by the RFC 7794 defined Router-ID sub-TLV(s). [WAJ] Yes, You are right on the above information and I also know this. The primary thought for defining this type, is that we want to filter such kind stub interface from advertising to the BGP-LS Stub-Link NLRI( https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5) on the router that run BPG-LS, or filer it easily on the controller. [LES:] If you never advertise loopbacks in the TLV then there is no need to filter them out. As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft only needs to advertise a new type of prefix metric – which is to be advertised in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link TLV defined in this draft should be removed. It suggests that a Link TLV is the correct container for Prefix information – it is not. [WAJ] Would you like to provide the reason, not just directly jump into to the conclusion? [LES:] This has been discussed many times. Using a link TLV to advertise Prefix Reachability information is incorrect. Les There is no need for this draft – therefore it should not be adopted. Les From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Sent: Thursday, January 13, 2022 6:13 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org<mailto:ppsenak=40cisco....@dmarc.ietf.org>>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 Hi, Les: Aijun Wang China Telecom On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Here is my takeaway from this back-and-forth. Several highly experienced routing folks have been looking at this draft in detail and they are unable to come to a common understanding on what the draft is trying to do. [WAJ] I think most of them have gotten the key points of this draft along the discussion and the reading of the related drafts. If they have still some questions, we can discuss and explain on the list. This alone indicates that the draft needs more work. Maybe the authors have a clear idea on what they are trying to do but if expert readers cannot determine what it is then clearly the draft needs further revision. [WAJ]This is the WG adoption call, not the WGLC. We certainly will update the draft according to the comments from the WG. For adoption call, I think enough interests is the main criteria for its adoption. It also indicates to me that it is premature to determine whether the WG should adopt this or not. If experienced folks reading the draft can’t easily determine what the draft is trying to do, then it does not seem possible to make a judgment as to whether the WG should adopt it. [WAJ] I think Gyan has given the good summary for the use cases, or motivation of this draft at https://mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/. I think if you read https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10, you can get the key points of inter-AS use case. Additional comments: I tend to agree with Tony (and others) that the draft is aimed at advertising some form of TE information – [WAJ] Yes. The proposed TLV is one container and aim to convey the attributes of the Stub-Link, also as stated in the draft name. which is why I suggested even in my first post on this thread that RFC 5316 seemed like it was enough. The problem that has been exposed during the discussion is that RFC 5316 requires an AS number and in this deployment case we may not have one. But perhaps this limitation can be addressed by using the reserved AS #0 – a la RFC 7607. (BGP experts please comment – I do not claim to be a BGP expert.) [WAJ]Reuse the existing TLVs need to update RFC5316, RFC5392 or other potential RFC document , to relax the “MUST” rules that defined in these documents. It will also influence the existing implementation and deployment. Won’t it encounter more resistances? And, as mentioned in your proposal, there still need some unproved bypass methods to solve the situations that not the original scenarios of RFC5316 and RFC5392. Start from the clean state is the most efficient way. Isn’t it? There is then the additional sub-TLV defined in the document: <snip> Link Type: Define the type of the stub-link. o 1: Numbered AS boundary link o 2: Unnumbered AS boundary link o 3: Loopback link o 4: Vlan interface link <end snip> Ignoring the first two which were only added recently to try to address the lack of an AS #: What is a “loopback link”? I have no idea. [WAJ] Change it to “loopback interface” maybe more accurate. It is also one kind of “Stub Link”, which there is no IGP neighbor on the other end(and certainly no Remote AS, remote IPv4/IPv6 ASBR Router ID” that the RFC5316 and RFC5392 required.) We should extract such stub link from other types of stub link. And while I know what a VLAN is, I have no idea why advertising that a link is a VLAN is useful. The draft provides no definition or clue as to the use case for this information. [WAJ] VLAN interface is the logical interfaces that connected to servers that are out side of the IGP domain. It is also different from the inter-AS link that described in RFC5316 and RFC5392. Some information that related to the attached severs or some policy to these server can be applied to these kind stub link. Finally, there is the relationship between this draft and draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that the latest version of the 5G draft only defines a new metric to be advertised in Prefix Reachability advertisements, I have no idea what the relationship between the two drafts may be. [WAJ]No. It gives two kinds of proposals for the new metric. Please see https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7. You may ignore it. Actually, I prefer to advertising the edge server related information via the Stub-Link TLV. The advantage of such approaches is that it can contain more granular information, not only the aggregated cost. What makes sense to me is NOT to adopt the draft at this time. The authors can then spend time revising the draft, addressing the many issues which have been raised, continue to get feedback from the WG, and at a future time decide whether the revised version is suitable for WG adoption. Les From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Tony Li Sent: Wednesday, January 12, 2022 6:04 PM To: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Cc: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org<mailto:ppsenak=40cisco....@dmarc.ietf.org>>; Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 Chris, This isn't the same as TE information which can be/is based dynamic values on the router. Are you sure? First, much of the TE information that we have distributed is static (administrative group, SRLG, etc.). The dynamic part has been bandwidth reservation. That still seems applicable to inter-AS stub links, even tho Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I understand the use case. I'm pretty sure that it isn't even using the 2-way connectivity check. It's literally just saying "Router A has a stub link B (i.e., it has the config 'isis passive' on it)". As the draft has it, you’re correct. However, there’s all that undefined subTLV space just begging for TE information. The current ‘link type’ information seems somewhat pointless if it isn’t intended to be a item for TE consideration. That infomration is already a part of an operators NMS b/c that NMS is what generated that router's configuration and stuck it on that router in the first place. That same NMS is going to be configuring the other router that would be looking for that "stub link" information in the IGP. Unless I've mis-understood something here, the proposoal is literally just pushing static configuration details around inside the IGP. Agreed 100%. But it’s also what we do today with much of the static TE information. Again, there’s precedent. T
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
