Hi Paul, That's what I thought - that the management address was not necessarily associated with the local L2 interface. The Port ID TLV also doesn't include the local ifIndex so it appears that there is currently no way to learn this in LLDP - correct?
Thanks, Acee > On Mar 5, 2025, at 1:39 PM, Paul Congdon <paul.cong...@outlook.com> wrote: > > Hello Acee, > Good to hear from you. I've copied Scott Mansfield who worked on the LLDP > YANG in case he has a different perspective. > The Management Address TLV was designed with a bit of flexibility to allow > you to advertise a management address used to reach a higher level entity for > various management objects - not just the local ifIndex of the Layer-2 link. > I'm not sure anyone has used this flexibility, or if the flexibility is > sufficient for the original intent. Here is some text from the spec: > The Management Address TLV identifies an address associated with the local > LLDP agent that may be used > to reach higher layer entities to assist discovery by network management. The > TLV also provides room for > the inclusion of both the system interface number and an object identifier > (OID) that are associated with this > management address, if either or both are known. > Here are the usage rules from the spec as well: > 8.5.9.9 Management Address TLV usage rules Management Address TLVs are > subject to the following: > • At least one Management Address TLV should be included in every LLDPDU. > • Since there are typically a number of different addresses associated > with a MSAP identifier, an individual LLDPDU may contain more than one > Management Address TLV. > • When Management Address TLV(s) are included in an LLDPDU, the included > address(es) should be the address(es) offering the best management capability. > • If more than one Management Address TLV is included in an LLDPDU, each > management address shall be different from the management address in any > other management address TLV in the LLDPDU. > • If an OID is included in the TLV, it shall be reachable by the > management address. > • In a properly formed Management Address TLV, the TLV information string > length is equal to: (management address string length) + (OID string length) > + 7. If the TLV information string length in a received Management Address > TLV is incorrect, then it is ignored and processing of that LLDPDU is > terminated. > Hope this is helpful, > Paul > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Wednesday, March 5, 2025 9:42 AM > To: paul.cong...@outlook.com > Cc: lsr <lsr@ietf.org>; draft-glctgp-lsr-l2-bundle-member-remote...@ietf.org; > Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Subject: Re: WG Adoption Poll for "Advertisement of Remote Interface > Identifiers for Layer 2 Bundle Members" > -draft-glctgp-lsr-l2-bundle-member-remote-id-02 > Hey Paul, Is the interface number associated with the LLDP Management > Address TLV always the local ifIndex of the Layer-2 link? > Hope All is Well, > Acee > > On Mar 4, 2025, at 2:01 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > > Acee - > > IEEE Std 802.1AB-2016 Figure 8-11 has exactly what we need. > > In particular: > > 8.5.9.5 interface numbering subtype > > The interface numbering subtype field shall contain an integer value > > indicating the numbering method used for defining the interface number. The > > following three values are currently defined: > > 1) Unknown > > 2) ifIndex > > 3) system port number > > And > > 8.5.9.6 interface number > > The interface number field shall contain the assigned number within > > the system that identifies the specific interface associated with this > > management address. > > Les > >> -----Original Message----- > >> From: Acee Lindem <acee.i...@gmail.com> > >> Sent: Tuesday, March 4, 2025 9:56 AM > >> To: Acee Lindem <acee.i...@gmail.com> > >> Cc: lsr <lsr@ietf.org>; > >> draft-glctgp-lsr-l2-bundle-member-remote...@ietf.org > >> Subject: Re: WG Adoption Poll for "Advertisement of Remote Interface > >> Identifiers for Layer 2 Bundle Members" >> > >> -draft-glctgp-lsr-l2-bundle-member- > >> remote-id-02 > >>> Speaking as WG member: > >>> I support adoption. > >>> With respect to acquiring the remote ID, I don't believe that LLDP > >>> include the > >> remote ID. There is a port ID but I believe this is an L2 construct. > >> If you're going to reference LLDP, you should add it to the "LLDP > >> IETF Organizationally Specific TLV" as is done for BGP parameters in > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > >> tracker.ietf.org%2Fdoc%2Fdraft-&data=05%7C02%7C%7C0fdffaebc088410bcb3 > >> 808dd5c0d0812%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6387679332 > >> 21668063%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> &sdata=qBFUmw7pepHx3vPAxxxaCs3rfQi1RgKj6wgwRw2GJjY%3D&reserved=0 > >> acee-idr-lldp-peer-discovery/. Also, you don't mention (via an > >> informational > >> reference) >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsvr-l3dl%2F&data=05%7C02%7C%7C0fdffaebc088410bcb3808dd5c0d0812%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638767933221690468%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HoYufPhp3W04Jt2GzTHLuU%2Bzdn6G34ORlMr6Hpquqvc%3D&reserved=0 > >> which does, in fact, advertise the local ifIndex which is commonly used > >> as the interface ID. > >>> Thanks, > >> Acee > >>> On Mar 2, 2025, at 8:56 AM, Acee Lindem <acee.i...@gmail.com> wrote: > >>> >>> LSR WG, > >>> >>> This starts the Working Group adoption call for >>> > >>> >>> draft-glctgp-lsr-l2-bundle- > >> member-remote-id-02. Please send your > >>> support or objection to this list before March 17th, 2025. > >>> >>> Thanks, > >>> Acee > >> _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
