Les,
So, the management address ifIndex isn't necessarily the ifIndex for the link
bundle member.
Thanks,
Acee
> On Mar 5, 2025, at 2:47 PM, Paul Congdon <paul.cong...@outlook.com> wrote:
>
> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math";
> panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15
> 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} /* Style Definitions */
> p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99;
> mso-style-link:"Plain Text Char"; margin:0in; font-size:11.0pt;
> font-family:"Calibri",sans-serif; mso-ligatures:standardcontextual;}
> span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99;
> mso-style-link:"Plain Text"; font-family:"Calibri",sans-serif;}
> .MsoChpDefault {mso-style-type:export-only; font-size:11.0pt;} @page
> WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1 {page:WordSection1;} --> The Port ID TLV is a mandatory to
> include TLV in all LLDPDUs and helps form the unique identifier for the LLDP
> agent. There are several ways to represent the Port ID.
> <image001.png> -----Original Message-----
> From: Acee Lindem <acee.i...@gmail.com>
> Sent: Wednesday, March 5, 2025 11:31 AM
> To: Paul Congdon <paul.cong...@outlook.com>
> Cc: scott.mansfi...@ericsson.com; 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
> 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%2Fda
> > >> ta%2F&data=05%7C02%7C%7C2ef878cdb8384b8874e008dd5c1c4a84%7C84df9e7f
> > >> e9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638767998757179357%7CUnknown%7CT
> > >> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> > >> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZQy%2BvaB4Q
> > >> luy3OjkcXMxhy1pCDBBiWRzGfkK1kqKKcw%3D&reserved=0
> > >> tracker.ietf.org%2Fdoc%2Fdraft-&data=05%7C02%7C%7C0fdffaebc088410bc
> > >> b3
> > >> 808dd5c0d0812%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63876793
> > >> 32
> > >> 21668063%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> > >> Au
> > >> 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%7C2ef878cdb8384b8874e008dd5c1c4a84%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638767998757196383%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OHgxNtScVxKZyQzSz1UHpdScYmZ%2FO78NUBGeZOkHTnU%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
