For OSPFv3 use E-LSAs (RFC8362)
Cheers, Jeff On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar <[email protected]>, wrote: > Acee, > > Thank you very much for suggesting using the Prefix TLV for carry the Running > Status and environment of 5G Edge Computing servers. > > In a nutshell, the > https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ > proposes the extension to LSA that can carry the three SubTLVs that are used > to represent the Running Status and Environment information of the 5G Edge > Computing Servers attached to the router: > > • Load measurement sub-TLV > • Capacity Index Sub-TLV > • Preference Index Sub-TLV > > Several sections of the draft are devoted to describe what those measurement > are and why need them for 5G Edge Computing, which may have made it not so > straightforward when reading in a rush. > > The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA > to be advertised to other routers in the 5G Local Data Network. > > If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension > does seem easier and cleaner: > > We can have: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Route Type | Prefix Length | AF | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Prefix (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Load Measurement Sub-TLV | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | capacity Index Sub-TLV | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Site Preference Sub-TLV | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server > addresses are in IPv6, should we specify the extension to RFC8362 in the same > draft? Or define a new AF type for the same extension to RFC7684? > > Your guidance is greatly appreciated. > > Thank you very much. > > Linda Dunbar > > > From: Acee Lindem (acee) <[email protected]> > Sent: Tuesday, November 3, 2020 1:38 PM > To: Linda Dunbar <[email protected]>; Yingzhen Qu > <[email protected]>; [email protected]; [email protected] > Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge > Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests > > We have a pretty full schedule and we add you as optional. I took a look at > the draft and it is all over the place right now with standardization > requested for one solution but 3 separate solutions partially specified. It > could benefit from some WG mailing list discussion prior to a 10 minute > presentation where we wouldn’t have time to discuss the many issues. > > One major issue is that you should be extending RFC 7684 rather than RFC 3630 > and it seems you these app-server selection metrics should be associated with > a prefix and NOT a stub link (i.e., the application server address). > > I’ll try to read it in more depth before IETF 109. > > Thanks, > Acee > > From: Linda Dunbar <[email protected]> > Date: Monday, November 2, 2020 at 10:12 PM > To: Yingzhen Qu <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing > (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests > Resent-From: <[email protected]> > Resent-To: Yingzhen Qu <[email protected]>, Acee Lindem > <[email protected]>, Christian Hopps <[email protected]> > Resent-Date: Monday, November 2, 2020 at 10:12 PM > > LSR Chairs, YingZhen, > > Can you give us 10 minute slot to present this new draft: > https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ > > This draft describes an OSPF extension that can distribute the 5G Edge > Computing App running status and environment, so that other routers in the 5G > Local Data Network can make intelligent decision on optimizing forwarding of > flows from UEs. The goal is to improve latency and performance for 5G Edge > Computing services. > > Thank you very much, > > Linda Dunbar > > From: Lsr <[email protected]> On Behalf Of Yingzhen Qu > Sent: Monday, October 19, 2020 3:52 PM > To: [email protected]; [email protected] > Subject: [Lsr] IETF 109 LSR Presentation Slot Requests > > Hi all, > > We're now accepting agenda requests for the LSR Working Grouping meeting IETF > 109. Please send your requests to [email protected] indicating draft name, > speaker, and desired duration (covering presentation and discussion). > > LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT. > > Thanks, > Yingzhen > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
