+1 The problem can be solved - and in a much more robust way than what is proposed in the draft - without any protocol extensions.
There is no reason for this draft. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem > Sent: Monday, March 18, 2024 12:50 PM > To: draft-lin-savnet-lsr-intra-domain-met...@ietf.org > Cc: lsr <lsr@ietf.org> > Subject: [Lsr] Intra-domain SAVNET method - draft-lin-savnet-lsr-intra- > domain-method-03 > > Speaking as WG member: > > Co-Authors, > > I see you have a slot at the LSR meeting on Thursday to present the subject > draft. > > I believe this document is misguided. You shouldn't need to advertise > protected prefixes. If you are doing Source Address Validation for intra- > domain sources, why wouldn't you do it for all of them? What do you do for > the intra-domain prefixes that aren't advertised (blindly forward them or > summarily discard them)? If you were to only do SAV on certain prefixes, this > should be a local decision as opposed to something that is advertised by the > sources. > > Also, you shouldn't need to advertise any reverse metric. At least within an > area, you have all the reverse costs in link-sate. Incoming interfaces for > asymmetric paths can be readily calculated without any IGP advertisement. > Algorithms to accomplish this are described in > > https://patents.google.com/patent/US11882019B1/en?oq=11882019 > > The SAVNET WG shouldn't adopt any document requiring IGP advertisement > without LSR approval. > > Thanks, > Acee > _______________________________________________ > 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
