Hi, John: Please gives concrete responses for my responses to Les’s comments at https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/
If not, I would say both you and Les’s understanding of this draft is not correct. Aijun Wang China Telecom > On Jan 14, 2022, at 23:43, John E Drake <[email protected]> > wrote: > > > I agree with Les. This draft is gratuitous and ill-considered. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Lsr <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > Sent: Friday, January 14, 2022 2:22 AM > To: Aijun Wang <[email protected]> > Cc: 'Peter Psenak' <[email protected]>; 'Christian Hopps' > <[email protected]>; [email protected]; 'Tony Li' <[email protected]>; 'lsr' > <[email protected]>; [email protected]; [email protected] > Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 > > [External Email. Be cautious of content] > > Aijun - > > From: Lsr <[email protected]> On Behalf Of Aijun Wang > Sent: Thursday, January 13, 2022 6:45 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: 'Peter Psenak' <[email protected]>; 'Christian Hopps' > <[email protected]>; [email protected]; 'Tony Li' <[email protected]>; 'lsr' > <[email protected]>; [email protected]; [email protected] > Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 > > Hi, Les: > > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: Friday, January 14, 2022 9:18 AM > To: Aijun Wang <[email protected]> > Cc: Tony Li <[email protected]>; Christian Hopps <[email protected]>; Peter > Psenak <[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 > > 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 <[email protected]> > Sent: Thursday, January 13, 2022 6:13 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Tony Li <[email protected]>; Christian Hopps <[email protected]>; Peter > Psenak <[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 > > 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
