Hi Acee, Adrian, This is very late, but better than never ๐
I read rfc4204 and see the following: The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. ... LMP requires that a pair of nodes have at least one active bi- directional control channel between them. ... An "LMP adjacency" is formed between two nodes when at least one bi- directional control channel is established between them. ... The link property correlation function of LMP is designed to aggregate multiple data links (ports or component links) into a TE link and to synchronize the properties of the TE link ... LMP messages are transmitted reliably using Message_Ids and retransmissions. The above shows that LMP is not a fit for our purpose. While writing the above, I realized that Adrian's comment is "are you sure this isn't going to grow into LMP" ๐Thanks for the reminder - we'll make sure of that ๐ In fact, we removed the acknowledgment option in the -01 revision - we concluded that it is not needed and the option would require the adjacency management which we don't want. Similarly, because of the following with L3DL: Two devices discover each other and their respective identities by sending multicast HELLO PDUs (Section 10). To assure discovery of new devices coming up on a multi-link topology, devices on such a topology, and only on a multi-link topology, send periodic HELLOs forever, see Section 19.1. Once a new device is recognized, both devices attempt to negotiate and establish a session by sending unicast OPEN PDUs (Section 11) to the source MAC addresses (plus VIDs if VLANs) of the received HELLOs. L3DL is not a good fit either. We only need/want a (quick) flooding mechanism for both local and remote scenarios - w/o maintaining adjacencies/sessions. Thanks. Jeffrey Juniper Business Use Only -----Original Message----- From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org> Sent: Tuesday, August 6, 2024 11:08 AM To: Acee Lindem <acee.i...@gmail.com>; adr...@olddog.co.uk Cc: draft-zzhang-rtgwg-router-i...@ietf.org; rtgwg@ietf.org Subject: RE: I-D Action: draft-zzhang-rtgwg-router-info-00.txt [External Email. Be cautious of content] Hi Acee, Adrian, Sorry that I did not respond to this earlier - crazy time before and after IETF. We will look into these references and get back. Thanks. Jeffrey Juniper Business Use Only Juniper Business Use Only -----Original Message----- From: Acee Lindem <acee.i...@gmail.com> Sent: Tuesday, July 9, 2024 4:10 PM To: adr...@olddog.co.uk Cc: draft-zzhang-rtgwg-router-i...@ietf.org; rtgwg@ietf.org Subject: Re: I-D Action: draft-zzhang-rtgwg-router-info-00.txt [External Email. Be cautious of content] And we also have https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/__;!!NEt6yMaO-gk!Bw231wdpMlDM02B_cQfeT9RWOojfTg0PgTHoIYrDgVP8F_sVAyv6mMz8eaaPWuRJlF8pAdBixhkAeNRmU3E$ Thanks, Acee > On Jul 4, 2024, at 11:38 AM, Adrian Farrel <adr...@olddog.co.uk> wrote: > > Are you sure this isn't going to grow into LMP [RFC4204] (or, dare I say it, > G.7714)? > > Cheers, > Adrian > > -----Original Message----- > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: 04 July 2024 12:13 > To: i-d-annou...@ietf.org > Subject: I-D Action: draft-zzhang-rtgwg-router-info-00.txt > > Internet-Draft draft-zzhang-rtgwg-router-info-00.txt is now available. > > Title: Advertising Router Information > Authors: Zhaohui Zhang > Kevin F. Wang > Changwang Lin > Name: draft-zzhang-rtgwg-router-info-00.txt > Pages: 11 > Dates: 2024-07-04 > > Abstract: > > This document specifies a generic mechanism for a router to advertise > some information to its neighbors. One use case of this mechanism is > to advertise link/path information so that a receiving router can > better react to network changes. > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzh > ang-rtgwg-router-info/__;!!NEt6yMaO-gk!Bw231wdpMlDM02B_cQfeT9RWOojfTg0 > PgTHoIYrDgVP8F_sVAyv6mMz8eaaPWuRJlF8pAdBixhkA2xRlI5w$ > > There is also an HTMLized version available at: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > t-zzhang-rtgwg-router-info-00__;!!NEt6yMaO-gk!Bw231wdpMlDM02B_cQfeT9RW > OojfTg0PgTHoIYrDgVP8F_sVAyv6mMz8eaaPWuRJlF8pAdBixhkAzCu2tVA$ > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe send > an email to i-d-announce-le...@ietf.org > > _______________________________________________ > rtgwg mailing list -- rtgwg@ietf.org > To unsubscribe send an email to rtgwg-le...@ietf.org _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
