Hi, Les: Aijun Wang China Telecom
> On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) <[email protected]> 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 <[email protected]> On Behalf Of Tony Li > Sent: Wednesday, January 12, 2022 6:04 PM > To: Christian Hopps <[email protected]> > Cc: Peter Psenak <[email protected]>; Aijun Wang > <[email protected]>; [email protected]; lsr <[email protected]>; > [email protected]; [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
