Hi Hannes, Thank you. Not everyone is yet in agreement with this, so we are discussing correct wording.
T > On Jul 5, 2022, at 7:00 AM, Hannes Gredler > <[email protected]> wrote: > > Hi Tony, et al, > > minor nit: > > --- > As an example, consider the Extended IS Reachability TLV (type 22). > A neighbor in this TLV is specified by: > > * 7 octets of system ID and pseudonode number > * 3 octets of default metric > > This acts as the key for this entry. The key is followed by up to > 244 octets of sub-TLV information. > --- > > I believe that in most implementations the key in the LSDB is the 7 octets of > system ID and pseudonode number > and does not include the metric (it's really an attribute to the key), > whereas the current wording might > wrongly imply that the key is {sysid, PSN and metric}. > > thanks, > > /hannes > > | From: Lsr <[email protected] <mailto:[email protected]>> On Behalf > Of Tony Li > | Sent: Tuesday, July 5, 2022 3:09 AM > | To: lsr <[email protected] <mailto:[email protected]>> > | Subject: [Lsr] Fwd: New Version Notification for > | draft-pkaneria-lsr-multi-tlv-01.txt > | > | > | > | > | > | Hi all, > | > | > | > | This is an update to reflect some of the discussions to date. A diff is > | attached. Most of this is a change to terminology to stop using the word > | ‘instance’ and shift to using ‘multi-part TLV’. > | > | > | > | We have been having a discussion about adding more discussion of keys in > | this document. We have not done that yet. This is not an indication of > | refusal, just making one baby step forward. More to come… Text > | contributions are more than welcome. > | > | > | > | Other comments? > | > | > | > | Regards, > | > | Tony > | > | > | > | > | > | > | > | > | > | Begin forwarded message: > | > | > | > | From: [email protected] <mailto:[email protected]> > | > | Subject: New Version Notification for > | draft-pkaneria-lsr-multi-tlv-01.txt > | > | Date: July 4, 2022 at 6:04:37 PM PDT > | > | To: "Antoni Przygienda" <[email protected] <mailto:[email protected]>>, > "Chris Bowers" > | <[email protected] <mailto:[email protected]>>, "Les Ginsberg" > <[email protected] <mailto:[email protected]>>, "Parag > | Kaneriya" <[email protected] <mailto:[email protected]>>, > "Shraddha Hegde" > | <[email protected] <mailto:[email protected]>>, "Tony Li" > <[email protected] <mailto:[email protected]>>, "Tony Przygienda" > | <[email protected] <mailto:[email protected]>> > | > | > | > | A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt > | has been successfully submitted by Tony Li and posted to the > | IETF repository. > | > | Name: draft-pkaneria-lsr-multi-tlv > | Revision: 01 > | Title: Multi-part TLVs in IS-IS > | Document date: 2022-07-04 > | Group: Individual Submission > | Pages: 7 > | URL: > | > https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt > | Status: > | https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ > | Htmlized: > | > https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv > | Diff: > | > https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01 > | > | Abstract: > | New technologies are adding new information into IS-IS while > | deployment scales are simultaneously increasing, causing the contents > | of many critical TLVs to exceed the currently supported limit of 255 > | octets. Extensions such as [RFC7356] require significant IS-IS > | changes that could help address the problem, but a less drastic > | solution would be beneficial. This document codifies the common > | mechanism of extending the TLV content space through multiple TLVs. > | > | The IETF Secretariat > | > | > | > | > _________________________________________________________________________________________________________________________ > | > | Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > | pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > | a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > | Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > | > | This message and its attachments may contain confidential or privileged > information that may be protected by law; > | they should not be distributed, used or copied without authorisation. > | If you have received this email in error, please notify the sender and > delete this message and its attachments. > | As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > | Thank you. > > | _______________________________________________ > | Lsr mailing list > | [email protected] <mailto:[email protected]> > | https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr> > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
