[Lsr] Re: draft-qgp-lsr-isis-pics-srmpls-yang-01
From: Yingzhen Qu Sent: 04 July 2024 05:57 Hi Bruno, I've published version -02. Hopefully it addressed your comments. As for RFC 8688, the L2 bundle member link attributes are applicable to more than just SR. This will be a separate YANG module. The question is whether to have it in the same draft with PICS for 8667 or a new draft. Thoughts? Separate draft. It is a no-brainer (or at least is for anyone who expects to be around on this work in a year or two's time). Once published, YANG modules proceed at different paces and having more than one module in an I-D/RFC means that bits will be updated or superseded while others may not be for years and there is no way to record this in the IETF infrastructure. Confusion results, Of course, there are those, not in this WG, who believe in subdividing work into multiple interconnected pieces with a complex mesh structure; but for them, nothing will work. I do not see that to be the case here. Tom Petch Thanks, Yingzhen On Wed, Jul 3, 2024 at 12:43 AM mailto:bruno.decra...@orange.com>> wrote: Hi Yingzhen, Thanks for you answer. Please see inline [Bruno] From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>> Sent: Tuesday, July 2, 2024 8:08 PM To: DECRAENE Bruno INNOV/NET mailto:bruno.decra...@orange.com>> Cc: Les Ginsberg (ginsberg) mailto:40cisco@dmarc.ietf.org>>; draft-qgp-lsr-isis-pics-srmpls-yang.auth...@ietf.org<mailto:draft-qgp-lsr-isis-pics-srmpls-yang.auth...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: draft-qgp-lsr-isis-pics-srmpls-yang-01 CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. Hi Bruno, Thanks for the review and comments. This is very helpful. As I mentioned during my presentation of the drafts, the level of details specified in the model is very important and subjective. We really need people, especially with operational experiences of the feature, to provide us feedback. [Bruno] Thanks Please see my answers below. Thanks, Yingzhen On Tue, Jul 2, 2024 at 9:28 AM mailto:bruno.decra...@orange.com>> wrote: Hi authors, all Thanks for the draft. I would support its progression. (and we want more PICS drafts 😉 ) I've quickly read the draft. Please find below some comments. " +--ro prefix-sid-sub-tlv-support? isis-pics:support" I think that it would be good to have the detail on a per TLV basis (TLVs 135, 235, 236, 237). Especially as some implementations are partial (e.g., support IPv4 but not IPv6) [Yingzhen]: I understand an implementation may not support multi-topology, so the prefix-sid sub-tlv is not included in TLV 235 and 237. However, for IPv4 (TLV135) and IPv6 (TLV236), isn't the "i-bit" and "v-bit" in the SR capability enough? [Bruno] My understanding is that the V-flag advertises a dataplane capability. e.g., as a guess, the ability for the router to process an “IPv6 Explicit NULL Label” (which could for example be added below an IPv4 Prefix SID). While prefix-sid-sub-tlv-support is a control plane capability (mapping a FEC to a label) I would assume that all router supporting IPv6 (and MPLS) would support the V-flag. On the other hand, some router supporting IPv6 were not supporting IPv6 prefix SID. At least in the early days, but I would assume this may not have changed. To some extent, same comment for the adj_SID TLVs. I would also propose to explicit the support of the flags. May be using the flag numbers for currently undefined flags. Again, some implementations do not support all flags. (e.g., V and L flags. However for those ones it's a bit more tricky as some implementation may support a single value (e.g. unset for some flags and set for some others flags) [Yingzhen]: Totally agree with you, the support of the flags is indeed tricky. Also it's hard to pick what flags to be included in the model. I personally don't think it's a good idea and useful to include all flags. I actually once did this and decided to remove the flags, as I feel too much information is not very useful. However, I agree with adding some flag support if these flags are considered important. As you see I included i-bit and v-bit. [Bruno] ok. Looks reasonable and I agree with you For prefix-SID: I guess the E and P flags are supported by all implementations as they are associated with “MUST”. (OTOH I tend to be occasionally negatively surprised by implementations not supporting MUST. A typical example would be with RFC3107. They would still claim being compliant with RFC though…) V/L-flags support is a MUST. But the support of “1”/set is optional and would impact int
Re: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
From: Lsr on behalf of Yingzhen Qu Sent: 13 March 2024 05:36 Les, thanks for the reminder. Liyan, you can post the WG version with a file name as Les suggested. Like Chris mentioned, X can replace Y. If you run into issues, please let us know. They will not run into issues. The rest of the world may at some future date when trying to understand what changes were introduced when and why. I have seen ADs fail to understand that a name change has happened to an I-D and so fail to understand how and why a document ended up as it is. The file name is temporary. It vanishes when the I-D is published.. Changing it just introduces the scope for mistakes. Don't do it. Ever. Tom Petch p.s. I wonder if anyone has ever appealed to the IESG against a decision to change th name of an I-D:-) Thanks, Yingzhen On Tue, Mar 12, 2024 at 9:38 PM Christian Hopps mailto:cho...@chopps.org>> wrote: I am not aware of any "inherited" requirement. We link documents (X replaces Y) in the datatracker by choosing whatever document we want as "replaces". You can post the document with whatever name changes you want and the chairs can either accept it and it gets posted or not. Thanks, Chris. > On Mar 12, 2024, at 23:26, Liyan Gong > mailto:gongli...@chinamobile.com>> wrote: > > Hi Yingzhen,Les and WG, > > Thank you. The first version will be updated soon with the name > draft-ietf-lsr-ospf-unreachable-link since the first version name needs to be > inherited. > The proposed name will be reflected in later versions. Thank you Les for your > good suggestion. It is more apt. > Any comments are always welcome. > > Best Regards, > Liyan > > 邮件原文 > 发件人："Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> > 收件人：Yingzhen Qu > mailto:yingzhen.i...@gmail.com>>,Liyan Gong > mailto:gongli...@chinamobile.com>> > 抄 送: "jie.d...@huawei.com<mailto:jie.d...@huawei.com>" > mailto:jie.d...@huawei.com>>,Acee Lindem > mailto:acee.i...@gmail.com>>,Gyan Mishra > mailto:hayabusa...@gmail.com>>,lsr > mailto:lsr@ietf.org>>,lsr-chairs > mailto:lsr-cha...@ietf.org>>,ketan Talaulikar > mailto:ketant.i...@gmail.com>> > 发送时间：2024-03-13 04:27:46 > 主题：RE: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - > 03/08/24) > >Or – if the authors want to consider my comments – replace “unreachable” > in the name with something more apt – perhaps: > > “lsr-ospf-max-link-metric” > > 😊 > >Les > > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of > Yingzhen Qu > Sent: Tuesday, March 12, 2024 1:11 PM > To: Liyan Gong mailto:gongli...@chinamobile.com>> > Cc: jie.d...@huawei.com<mailto:jie.d...@huawei.com>; Acee Lindem > mailto:acee.i...@gmail.com>>; Gyan Mishra > mailto:hayabusa...@gmail.com>>; lsr > mailto:lsr@ietf.org>>; lsr-chairs > mailto:lsr-cha...@ietf.org>>; ketan Talaulikar > mailto:ketant.i...@gmail.com>> > Subject: Re: [Lsr] WG Adoption > Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) > > Hi all, > > The adoption call has ended. > > There is strong consensus, and all the authors and contributors have replied > to the IPR call thread, so this draft is now adopted. > > Authors, please upload a WG version with name > draft-ietf-lsr-ospf-unreachable-link when the datatracker is open. > > Please continue the discussion to further refine the draft. > > Thanks, > Yingzhen > > On Mon, Mar 11, 2024 at 7:34PM Liyan Gong > mailto:gongli...@chinamobile.com>> wrote: > Hi Jie, > > Thank you for your replies. Please see inline with [Liyan]. > > Best Regards, > Liyan > > > 邮件原文 > 发件人："Dongjie \\(Jimmy\\)" > mailto:40huawei@dmarc.ietf.org>> > 收件人：Acee Lindem mailto:acee.i...@gmail.com>>,Liyan Gong > mailto:gongli...@chinamobile.com>> > 抄 送: Gyan Mishra > mailto:hayabusa...@gmail.com>>,Yingzhen Qu > mailto:yingzhen.i...@gmail.com>>,lsr > mailto:lsr@ietf.org>>,lsr-chairs > mailto:lsr-cha...@ietf.org>>,ketan Talaulikar > mailto:ketant.i...@gmail.com>> > 发送时间：2024-03-11 23:11:49 > 主题：Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - > 03/08/24) > >Hi Acee and Liyan, > > Please see some replies inline with [Jie] : > > From: Acee Lindem [mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com>] > Sent: Sunday, March 10, 2024 5:37 AM > To: Liyan Gong mailto:gongli...@chinamobile.com>> > Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; > Dongjie (Jimmy) mailto:jie.d...@huawei.com&g
Re: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt
This I-D changes the names of some bits in the identity cf RFC8667. I think that the description clause should then give the mapping to the RFC8667 name. I see this for lo-bit pe-bit af-bit These may be excellent names but they are not what RFC8667 specifies! As the YANG doctor review says, the description should reference RFC and section thereof for all identity such as r-bit. The I-D refences RFC8102 draft-ietf-rtgwg-segment-routing-ti-lfa which need adding to the I-D References Perhaps in the YANG augment OLD "This augments ISIS protocol configuration with segment routing."; NEW "This augments ISIS protocol configuration with segment routing for the MPLS data plane."; Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 31 December 2023 06:30 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-isis-sr-yang-19.txt Internet-Draft draft-ietf-isis-sr-yang-19.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane Authors: Stephane Litkowski Yingzhen Qu Pushpasis Sarkar Ing-Wher Chen Jeff Tantsura Name:draft-ietf-isis-sr-yang-19.txt Pages: 31 Dates: 2023-12-30 Abstract: This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-19.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-19 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
From: Acee Lindem Sent: 15 January 2024 20:30 Hi Tom, Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies. Acee I think that you are wrong. The historian in me knows that given a choice or primary or secondary sources, the secondary can only get it wrong; you always go back to the primary (unless or until the primary is replaced which is not the case for most of the definitions here). > On Jan 13, 2024, at 07:42, tom petch wrote: > > From: Lsr on behalf of The IESG > > Sent: 11 January 2024 14:35 > > > Most of my comments on this I-D from August are addressed but I still have > some doubts. > > p.11 identity nu-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Agreed. However, I think including both references would be good since RFC 8362 includes the flags in TLVs > > identity la-bit > here RFC8362 changes the meaning so I think the reference to RFC8362 is ok Actually, for the LA-bit, both references would be good. > p.11 identity p-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Same as nu-bit. > p.12 identity dn-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Same as nu-bit. > p.12 identity e-bit > this is not esplained in the referenced RFC8362; in fact, this one defeats > me. It is present in a diagram, s.3.6, but with no explanation. Reading > RFC5340 it could be A.4.3 but I am not sure If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, there are type 1 and type 2 metrics. Type 1 are simply added to intra-area metric to the originator. Type 2 metrics are considered greater than type 1 metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 extended-LSA encodings. Since the description is brief, I’ll include it in its entirety. Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but in the modern context of SR, IPv6, OSPFv3, extended LSA etc I did not recognise the terse allusion. And why do you not include the AC bit defined in RFC9513? Tom Petch Thanks, Acee > > Tom Petch > > > > Abstract > > > This document defines a YANG data model augmenting the IETF OSPF YANG > model to provide support for OSPFv3 Link State Advertisement (LSA) > Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide > extensible TLV-based LSAs for the base LSA types defined in RFC 5340. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-00.txt
From: Lsr on behalf of internet-dra...@ietf.org Sent: 10 December 2023 03:37 Internet-Draft draft-ietf-lsr-ospf-prefix-extended-flags-00.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: Prefix Flag Extension for OSPFv2 and OSPFv3 Authors: Ran Chen Detao Zhao Peter Psenak Ketan Talaulikar Name:draft-ietf-lsr-ospf-prefix-extended-flags-00.txt Pages: 10 Dates: 2023-12-09 Abstract: Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix attributes Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. Section 2 talks of Types TBD1 and TBD2 IANA Considerations asks IANA to assign TBD and TBD. I think that these need bringing in line Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
From: Lsr on behalf of The IESG Sent: 11 January 2024 14:35 The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Most of my comments on this I-D from August are addressed but I still have some doubts. p.11 identity nu-bit this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference identity la-bit here RFC8362 changes the meaning so I think the reference to RFC8362 is ok p.11 identity p-bit this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference p.12 identity dn-bit this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference p.12 identity e-bit this is not esplained in the referenced RFC8362; in fact, this one defeats me. It is present in a daigram, s.3.6, but with no explanation. Reading RFC5340 it could be A.4.3 but I am not sure Tom Petch Abstract This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] 8665 and 8666 in the datatracker
I commented last month that I thought that RFC8665 should be in the datatracker pages for LSR WG; I was wrong. I raised an issue and now understand that the date that counts is when the I-D was submitted to the RFC Editor. For this I-D, that was before the OSPF WG was wound up so that although by the time of publication, LSR as well underway, yet it remained an OSPF RFC. Other RFC with seemingly similar metadata did not join the RFC Editor Queue until after the LSR WG had come into being and so have been regarded as LSR RFC and listed as such in the datatracker. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AF: RFC8666 updates RFC8665?
From: Acee Lindem
Sent: 01 January 2024 13:14
> On Dec 30, 2023, at 06:56, tom petch wrote:
>
> Going through ospf-sr-yang-25 (and no, I do not want a new version for
> Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the metadata
> does not mention it.
>
> RFC8665 says
> " AF: Address family for the prefix. Currently, the only supported
> value is 0 for IPv4 unicast. The inclusion of address family
> in this TLV allows for future extension.
> "
>
> while RFC8666 says
> " AF: Address family for the prefix.
> AF: 0 - IPv4 unicast
> AF: 1 - IPv6 unicast
> "
> Since 8665 says 'only supported value' then this is no longer valid and has
> a knock-on efffect when it comes to ospf-sr-yang.
OSPFv2 only supports IPv4.
Not something you would know from reading ospf-sr-yang:-(
There are plenty of objects with ospfv2 in the identifier which then allow IPv6
values e.g
grouping ospfv2-prefix-sid-sub-tlvs {
with mt-id
or
grouping ospfv2-extended-prefix-range-tlvs {
with type inet:ip-prefix;
You could restrict OSPFv2 to IPv4 but you do not.
Tom Petch
If OSPFv2
OSPFv3 supports both IPv4 and IPv6.
Thanks,
Acee
>
> If 8665 set up a registry (which I appreciate that the LSR WG has been
> resistant to doing in other cases) then adding a value to the registry would
> not be an update as per previous AD decisions but the phrase 'the only
> supported value is 0' can mislead until the reader understands 8666 (and may
> still do so).
>
> Note that ospf-sr-yang has both RFC8665 and RFC8666 as Normative References
> so it is the implementor of the yang module that is at risk of
> misunderstanding.
>
> I have a number of comments on ospf-sr-yang relating to this which I will
> post separately.
>
> Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[Lsr] SID et al. in Re: I-D Action: draft-ietf-ospf-sr-yang-25.txt
a) I think that the treatment of SID index/label in this I-D needs more explanation. The I-D rightly says that this is either a 3-octet index or 4-octet label but fails to say how the three octets are mapped into a YANG type uint32. The information is in RFC8665 but it took me a while to find it. I think that it needs repeating in this I-D with a reference to RFC8665. Slightly harder is where to put this. I think that it needs to be in the YANG module as a description. Trouble is, there are lots of uint32 where this is relevant. Now if SID were a YANG derived type . b) the I-D does not use the same name for bits as RFC8665 does. Where this happens, then I think there should be an explanation e.g. identity lo-bit description ' this bit is referred to as the L-flag in RFC8665 section 5. c) section 1.1 is out of date d) CODE BEGINS I think better as a new paragraph for ease of reference; I see this as common practive e) leaf mt-id if the only valid values are 0 to 127, then this could use a YANG range to reflect that f) range-size likewise if this must be greater than zero, thrm the YANG could reflect that. It could even be a derived type to avoid repetition Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 19 December 2023 21:41 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-25.txt Internet-Draft draft-ietf-ospf-sr-yang-25.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane Authors: Yingzhen Qu Acee Lindem Jeffrey Zhang Ing-Wher Chen Name:draft-ietf-ospf-sr-yang-25.txt Pages: 46 Dates: 2023-12-19 Abstract: This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-25.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-yang-25 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AF: RFC8666 updates RFC8665?
From: Yingzhen Qu Sent: 30 December 2023 21:11 Hi Tom, Sorry, but I don't understand your question. RFC8665 is for OSPFv2, and RFC8666 is for OSPFv3. While in both cases, the TLV name is "Extended Prefix Range TLV", one is for OSPFv2 extended prefix LSA, the other may be advertised in: E-Intra-Area-Prefix-LSA E-Inter-Area-Prefix-LSA E-AS-External-LSA E-Type-7-LSA I'm not sure whether this answers your question. More comments are welcome. No! There are those in a world with only OSPFv2 routing domains with no awareness of the existence of OSPFv3; likewise there are those in a world with only OSPFv3 routind domains with no awareness of the existence of OSPFv2. Then there are those who live with both, perhaps with boxes at the border of Enterprise and Operator. And IETF documents exist in this world. ospf-sr-yang models OSPFv2 and OSPFv3, it has RFC8665 and RFC8666 as Normative References and defines a leaf 'af' whose definition in RFC8666 contradicts that in RFC8665 unless and until RFC8666 is seen as updating RFC8665 and which could confuse those who comprehend the Normative References, IMHO., Tom Petch Thanks, Yingzhen On Sat, Dec 30, 2023 at 3:56 AM tom petch mailto:ie...@btconnect.com>> wrote: Going through ospf-sr-yang-25 (and no, I do not want a new version for Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the metadata does not mention it. RFC8665 says " AF: Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension. " while RFC8666 says " AF: Address family for the prefix. AF: 0 - IPv4 unicast AF: 1 - IPv6 unicast " Since 8665 says 'only supported value' then this is no longer valid and has a knock-on efffect when it comes to ospf-sr-yang. If 8665 set up a registry (which I appreciate that the LSR WG has been resistant to doing in other cases) then adding a value to the registry would not be an update as per previous AD decisions but the phrase 'the only supported value is 0' can mislead until the reader understands 8666 (and may still do so). Note that ospf-sr-yang has both RFC8665 and RFC8666 as Normative References so it is the implementor of the yang module that is at risk of misunderstanding. I have a number of comments on ospf-sr-yang relating to this which I will post separately. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] AF in Re: I-D Action: draft-ietf-ospf-sr-yang-25.txt
I think that the treatment of AF in this I-D needs more thought. It is perhaps unfortunate that SR has created a new register of AF to go with those in RFC5838, RFC8349 and so on but I take that as a given from RFC8665, RFC8666. I think that this I-D needs to spell that out 'The AF defined in this document are those defined in RFC8665, RFC8666 and not those defined in RFC5838, RFC8349 and the like.' Well something like that! I think that that needs to go in the YANG module as a description not sure where but probably for each leaf 'af' with references either to both RFC8665 and RFC8666 or perhaps better just to RFC8666, so that the contradiction beween the two RFC is clear. The more complex question is what the YANG allows, or should allow. The YANG currently allows SR-MPLS SID to be distributed by OSPFv2 with an IPv6 FEC. I see no reason anywhere why this is not valid but is it your intention? Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 19 December 2023 21:41 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-25.txt Internet-Draft draft-ietf-ospf-sr-yang-25.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane Authors: Yingzhen Qu Acee Lindem Jeffrey Zhang Ing-Wher Chen Name:draft-ietf-ospf-sr-yang-25.txt Pages: 46 Dates: 2023-12-19 Abstract: This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ospf-sr-yang-25.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ospf-sr-yang-25 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
From: Acee Lindem
Sent: 12 December 2023 22:25
Hi Tom,
> On Dec 11, 2023, at 7:45 AM, tom petch wrote:
Acee
top posting since most of my comments are addressed in -25 (which I have
reviewed)
Renaming the YANG module is a pain but probably needs doing on the assumption
that there will be a ospf-srv6-yang at some stage and that you will not want to
merge the details of that into the module specified here. Of course it may
then be that just as OSPFv2 and OSPFv3 have much in common and have been merged
into a single module, so SRv6 may get merged in in which case the original name
would be better. Sometimes you cannot win!
Tom Petch
I do see routing-ti-lfa progressing this week so hopefully Normative will be ok.
>
> A convenient addressee list so top posting my first thoughts on ospf-sr-yang,
> I hope to find time to have a more detailed look, at least at ospfv2.
>
> I have looked at ospf-sr-yang and have some queries.
>
> Is this all flavours of SR or just some? Most discussion I see these days
> relates to SRv6 I guess because SR-MPLS is mature in many respects but think
> that this I-D needs to spell out the scope (like its lsr twin)
This specifies OSPF SR for the MPLS data plane. I’m considering renaming the
data module to ietf-ospf-sr-mpls.yang as well.
> I note the import from sr-mpls and think it a mistake. The routing RFC says
> that new protocols should have a presence container to switch the protocol on
> and off which sr-mpls does not do but I think that ospf-sr-yang should follow
> the guidelines.
We need to follow the sr-mpls model. We can’t change it in the OSPF SR model.
>
> There are mentions of vendor augmentations but no indications of what they
> might be and, importantly, where they would go. Other I-D, anticipating
> augments, include containers explicitly for augments so that different
> vendors put the same information in the same place.
>
> I am used to ospfv2 and ospfv3 being derived identities from ospf which makes
> reference to one of the other or both simple, as ospf-yang does. Why not
> here?
I’ve updated these to use derived-from() and the current path.
>
> I-D references seems to lack
> RFC8102
> "draft-ietf-rtgwg-segment-routing-ti-lfa -
> Latter needs to be Normative since a feature
I hate making the latter normative but I guess it needs to be hopefully the
authors of this draft will finally bring it to completion.
>
> s.1.1 is ood
This has been removed.
>
> router-id is provided by RFC8294 so it should be imported and not be
> reinvented here
Okay - I have used this definition.
>
> import ietf-ospfv3-extended-lsa {
> lacks a reference clause
>
>leaf preference {
> type uint8;
> description
> "SRMS preference TLV, value from 0 to 255.";
>
> so what? what difference soes it make to be 0 or 255 or 42?
The description has been updated to indicate that an SR Mapping Server with a
higher preference is preferred.
Thanks,
Acee
>
> Tom Petch
>
>
> From: Lsr on behalf of julien.meu...@orange.com
>
> Sent: 05 December 2023 08:15
>
> Hi Acee,
>
> I've looked at the diff: the new version looks good to me. Thanks to the
> update.
>
> Regards,
>
> Julien
>
>
> On 01/12/2023 18:05, Acee Lindem wrote:
>> Hi Julien,
>>
>> Thanks much for your review. I’ve incorporated almost all of your comments
>> in the -23 version.
>>
>> See inline.
>>
>>> On Nov 29, 2023, at 11:03 AM, julien.meu...@orange.com wrote:
>>>
>>> Hello,
>>>
>>> I have been selected as the Routing Directorate reviewer for this draft.
>>> The Routing Directorate seeks to review all routing or routing-related
>>> drafts as they pass through IETF last call and IESG review, and sometimes
>>> on special request. The purpose of the review is to provide assistance to
>>> the Routing ADs. For more information about the Routing Directorate, please
>>> see https://wiki.ietf.org/en/group/rtg/RtgDir
>>> <https://wiki.ietf.org/en/group/rtg/RtgDir>
>>>
>>> Although these comments are primarily for the use of the Routing ADs, it
>>> would be helpful if you could consider them along with any other IETF Last
>>> Call comments that you receive, and strive to resolve them through
>>> discussion or by updating the draft.
>>>
>>> Document: draft-ietf-ospf-sr-yang-22
>>> Reviewer: Julien Meuric
>>> Review Date: 2023-11-29
>>> Intended Status: Standard Tracks
>>>
>>>
>>> *Summary:*
>>>
>>> This document is basica
[Lsr] AF: RFC8666 updates RFC8665?
Going through ospf-sr-yang-25 (and no, I do not want a new version for Christmas!) it seems to me that RFC8666 updates, RFC8665 even if the metadata does not mention it. RFC8665 says " AF: Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension. " while RFC8666 says " AF: Address family for the prefix. AF: 0 - IPv4 unicast AF: 1 - IPv6 unicast " Since 8665 says 'only supported value' then this is no longer valid and has a knock-on efffect when it comes to ospf-sr-yang. If 8665 set up a registry (which I appreciate that the LSR WG has been resistant to doing in other cases) then adding a value to the registry would not be an update as per previous AD decisions but the phrase 'the only supported value is 0' can mislead until the reader understands 8666 (and may still do so). Note that ospf-sr-yang has both RFC8665 and RFC8666 as Normative References so it is the implementor of the yang module that is at risk of misunderstanding. I have a number of comments on ospf-sr-yang relating to this which I will post separately. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
From: Acee Lindem
Sent: 18 December 2023 13:14
To: tom petch
Cc: julien.meu...@orange.com; Routing Directorate;
draft-ietf-ospf-sr-yang@ietf.org; Lsr
Subject: Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Tom,
On Dec 18, 2023, at 07:47, tom petch wrote:
I have yet to catch up with -24 but still on -23, Ithink that you should
explain where the OSPFv3 YANG augments came from with a Informative Refeerence
to draft-acee-lsr-ospfv3-sr-yang. It has taken me since last Thursday to work
it out:-(. Unadopted individual drafts do not rate highly in the datatracker.
This draft includes both the SR MPLS augmentations for OSPFv2 and OSPFv3.
draft-acee-lsr-ospfv3-sr-yang is not obsolete. They were separate drafts at one
time since the latter was dependent on the OSPFv3 Extended LSA YANG model which
some day will be reviewed out AD and progressed.
All very true but it is ospf-sr-yang that is now progressing - draft-acee is
not - and which grew 50% in size when the thirteen augments from draft-acee
were incorporated so I see that needing a mention in ospf-sr-yang along with an
Informational Reference.
The nature of the model and the form that that imposes on the augments makes
it hard to follow but AFAICT twelve of the augments came across unchanged, one,
relating to nssa, changed its augment point. Whether this fixed a fault,
introduced a fault or ... I cannot tell.
It stills needs a mention IMHO
I am aware of and have reviewed extended-lsa-yang
Tom Petch
<https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/>
[ietf-logo-card.png]
YANG Model for OSPFv3 Extended
LSAs<https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/>
datatracker.ietf.org<https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/>
The fact that is was never adopted may have implications, such as IPR and the
like, I do not know, but think it needs stating if only by implication
(darft-acee..!).
We still have a WG last call to do on this draft so you needn’t worry.
I had noticed and reviewed draft-acee and was waiting for a call for adoption
to make m comments - e.g. perfix - but the call never came. I think my
comments are addressed in -21, when ospfv3 was added, but I will check again in
-24
This problem is fixed in ietf-ospf-sr-mpls.yang
Thanks,
Acee
Tom Petch
From: Acee Lindem
Sent: 12 December 2023 22:25
To: tom petch
Cc: julien.meu...@orange.com; Routing Directorate;
draft-ietf-ospf-sr-yang@ietf.org; Lsr
Subject: Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Hi Tom,
On Dec 11, 2023, at 7:45 AM, tom petch wrote:
A convenient addressee list so top posting my first thoughts on ospf-sr-yang,
I hope to find time to have a more detailed look, at least at ospfv2.
I have looked at ospf-sr-yang and have some queries.
Is this all flavours of SR or just some? Most discussion I see these days
relates to SRv6 I guess because SR-MPLS is mature in many respects but think
that this I-D needs to spell out the scope (like its lsr twin)
This specifies OSPF SR for the MPLS data plane. I’m considering renaming the
data module to ietf-ospf-sr-mpls.yang as well.
I note the import from sr-mpls and think it a mistake. The routing RFC says
that new protocols should have a presence container to switch the protocol on
and off which sr-mpls does not do but I think that ospf-sr-yang should follow
the guidelines.
We need to follow the sr-mpls model. We can’t change it in the OSPF SR model.
There are mentions of vendor augmentations but no indications of what they
might be and, importantly, where they would go. Other I-D, anticipating
augments, include containers explicitly for augments so that different vendors
put the same information in the same place.
I am used to ospfv2 and ospfv3 being derived identities from ospf which makes
reference to one of the other or both simple, as ospf-yang does. Why not here?
I’ve updated these to use derived-from() and the current path.
I-D references seems to lack
RFC8102
"draft-ietf-rtgwg-segment-routing-ti-lfa -
Latter needs to be Normative since a feature
I hate making the latter normative but I guess it needs to be hopefully the
authors of this draft will finally bring it to completion.
s.1.1 is ood
This has been removed.
router-id is provided by RFC8294 so it should be imported and not be reinvented
here
Okay - I have used this definition.
import ietf-ospfv3-extended-lsa {
lacks a reference clause
leaf preference {
type uint8;
description
"SRMS preference TLV, value from 0 to 255.";
so what? what difference soes it make to be 0 or 255 or 42?
The description has been updated to indicate that an SR Mapping Server with a
higher preference is preferred.
Thanks,
Acee
Tom Petch
From: Lsr on b
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
I have yet to catch up with -24 but still on -23, Ithink that you should
explain where the OSPFv3 YANG augments came from with a Informative Refeerence
to draft-acee-lsr-ospfv3-sr-yang. It has taken me since last Thursday to work
it out:-(. Unadopted individual drafts do not rate highly in the datatracker.
The fact that is was never adopted may have implications, such as IPR and the
like, I do not know, but think it needs stating if only by implication
(darft-acee..!).
I had noticed and reviewed draft-acee and was waiting for a call for adoption
to make m comments - e.g. perfix - but the call never came. I think my
comments are addressed in -21, when ospfv3 was added, but I will check again in
-24
Tom Petch
From: Acee Lindem
Sent: 12 December 2023 22:25
To: tom petch
Cc: julien.meu...@orange.com; Routing Directorate;
draft-ietf-ospf-sr-yang@ietf.org; Lsr
Subject: Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Hi Tom,
> On Dec 11, 2023, at 7:45 AM, tom petch wrote:
>
> A convenient addressee list so top posting my first thoughts on ospf-sr-yang,
> I hope to find time to have a more detailed look, at least at ospfv2.
>
> I have looked at ospf-sr-yang and have some queries.
>
> Is this all flavours of SR or just some? Most discussion I see these days
> relates to SRv6 I guess because SR-MPLS is mature in many respects but think
> that this I-D needs to spell out the scope (like its lsr twin)
This specifies OSPF SR for the MPLS data plane. I’m considering renaming the
data module to ietf-ospf-sr-mpls.yang as well.
>
> I note the import from sr-mpls and think it a mistake. The routing RFC says
> that new protocols should have a presence container to switch the protocol on
> and off which sr-mpls does not do but I think that ospf-sr-yang should follow
> the guidelines.
We need to follow the sr-mpls model. We can’t change it in the OSPF SR model.
>
> There are mentions of vendor augmentations but no indications of what they
> might be and, importantly, where they would go. Other I-D, anticipating
> augments, include containers explicitly for augments so that different
> vendors put the same information in the same place.
>
> I am used to ospfv2 and ospfv3 being derived identities from ospf which makes
> reference to one of the other or both simple, as ospf-yang does. Why not
> here?
I’ve updated these to use derived-from() and the current path.
>
> I-D references seems to lack
> RFC8102
> "draft-ietf-rtgwg-segment-routing-ti-lfa -
> Latter needs to be Normative since a feature
I hate making the latter normative but I guess it needs to be hopefully the
authors of this draft will finally bring it to completion.
>
> s.1.1 is ood
This has been removed.
>
> router-id is provided by RFC8294 so it should be imported and not be
> reinvented here
Okay - I have used this definition.
>
> import ietf-ospfv3-extended-lsa {
> lacks a reference clause
>
>leaf preference {
> type uint8;
> description
> "SRMS preference TLV, value from 0 to 255.";
>
> so what? what difference soes it make to be 0 or 255 or 42?
The description has been updated to indicate that an SR Mapping Server with a
higher preference is preferred.
Thanks,
Acee
>
> Tom Petch
>
>
> From: Lsr on behalf of julien.meu...@orange.com
>
> Sent: 05 December 2023 08:15
>
> Hi Acee,
>
> I've looked at the diff: the new version looks good to me. Thanks to the
> update.
>
> Regards,
>
> Julien
>
>
> On 01/12/2023 18:05, Acee Lindem wrote:
>> Hi Julien,
>>
>> Thanks much for your review. I’ve incorporated almost all of your comments
>> in the -23 version.
>>
>> See inline.
>>
>>> On Nov 29, 2023, at 11:03 AM, julien.meu...@orange.com wrote:
>>>
>>> Hello,
>>>
>>> I have been selected as the Routing Directorate reviewer for this draft.
>>> The Routing Directorate seeks to review all routing or routing-related
>>> drafts as they pass through IETF last call and IESG review, and sometimes
>>> on special request. The purpose of the review is to provide assistance to
>>> the Routing ADs. For more information about the Routing Directorate, please
>>> see https://wiki.ietf.org/en/group/rtg/RtgDir
>>> <https://wiki.ietf.org/en/group/rtg/RtgDir>
>>>
>>> Although these comments are primarily for the use of the Routing ADs, it
>>> would be helpful if you could consider them along with any other IETF Last
>>> Call comments that you receive, and strive to resolve them through
Re: [Lsr] RFC8665
From: Les Ginsberg (ginsberg) Sent: 13 December 2023 18:21 Tom - At some point the WG chairs might want to respond, but the simple answer to this "mystery" has to do with when a document became an RFC. LSR WG was formed in early 2018. It took over the work that was previously done by the OSPF WG (https://datatracker.ietf.org/wg/ospf/documents/ ) and the IS-IS WG (https://datatracker.ietf.org/wg/isis/documents/ ). If a document became an RFC after the LSR WG took over, then it is listed on LSR page - if the document became an RFC before then it is listed either on the OSPF page or the IS-IS page. If you look at those pages you will see that each WG produced a large number of documents - not sure if it would make sense to move/copy all of that to the LSR page. I will let the WG chairs comment on that. For myself, if I want to find an RFC, I simply put "RFC" into my favorite search tool and it is quickly found. Les Thanks for that, I see == Internet Engineering Task Force (IETF)P. Psenak, Ed. Request for Comments: 8665 S. Previdi, Ed. Category: Standards TrackC. Filsfils ISSN: 2070-1721 Cisco Systems, Inc. H. Gredler RtBrick Inc. R. Shakir Google, Inc. W. Henderickx Nokia J. Tantsura Apstra, Inc. December 2019 === Internet Engineering Task Force (IETF)P. Psenak, Ed. Request for Comments: 8666 S. Previdi, Ed. Category: Standards TrackCisco Systems, Inc. ISSN: 2070-1721December 2019 == the latter being listed on lsr, the former not. mm Tom Petch Les > -Original Message- > From: tom petch > Sent: Wednesday, December 13, 2023 9:34 AM > To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org > Cc: lsr@ietf.org > Subject: Re: RFC8665 > > From: Les Ginsberg (ginsberg) > Sent: 11 December 2023 16:42 > > https://datatracker.ietf.org/doc/rfc8665/ > > And there is a link to it here: > https://datatracker.ietf.org/wg/ospf/documents/ > > Not sure why you are having issues. > > > > Because the link is missing, missing from where it would be most useful, in > the > page for the LSR WG, the part that lists the RFC, the part that, inter alia, > lists > RFC8666 and RFC8667. > I have come to rely on the page for the WG to link to most of the documents I > need to reference to review eg ospf-sr-yang. > > And it is not there. > > Yes there are other links to it on other pages which just consumes more of my > time to find. > > I am thinking that the metadata may be wrong and there will be other > problems but as yet have no evidence thereof. > > Tom Petch > > > >Les > > > -Original Message- > > From: Lsr On Behalf Of tom petch > > Sent: Monday, December 11, 2023 4:02 AM > > To: lsr-cha...@ietf.org > > Cc: lsr@ietf.org > > Subject: [Lsr] RFC8665 > > > > I look in vain in the datatracker for RFC8665. > > > > Document search finds it, the data tracker does not list it. > > > > I realise that it is not a product of the lsr WG but then neither are > > RFC9129 or > > RFC8920 AFAICTand they are listed. > > > > Odd; well, irritating to be precise. > > > > Tom Petch > > ___ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC8665
From: Les Ginsberg (ginsberg) Sent: 11 December 2023 16:42 https://datatracker.ietf.org/doc/rfc8665/ And there is a link to it here: https://datatracker.ietf.org/wg/ospf/documents/ Not sure why you are having issues. Because the link is missing, missing from where it would be most useful, in the page for the LSR WG, the part that lists the RFC, the part that, inter alia, lists RFC8666 and RFC8667. I have come to rely on the page for the WG to link to most of the documents I need to reference to review eg ospf-sr-yang. And it is not there. Yes there are other links to it on other pages which just consumes more of my time to find. I am thinking that the metadata may be wrong and there will be other problems but as yet have no evidence thereof. Tom Petch Les > -Original Message- > From: Lsr On Behalf Of tom petch > Sent: Monday, December 11, 2023 4:02 AM > To: lsr-cha...@ietf.org > Cc: lsr@ietf.org > Subject: [Lsr] RFC8665 > > I look in vain in the datatracker for RFC8665. > > Document search finds it, the data tracker does not list it. > > I realise that it is not a product of the lsr WG but then neither are RFC9129 > or > RFC8920 AFAICTand they are listed. > > Odd; well, irritating to be precise. > > Tom Petch > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
A convenient addressee list so top posting my first thoughts on ospf-sr-yang,
I hope to find time to have a more detailed look, at least at ospfv2.
I have looked at ospf-sr-yang and have some queries.
Is this all flavours of SR or just some? Most discussion I see these days
relates to SRv6 I guess because SR-MPLS is mature in many respects but think
that this I-D needs to spell out the scope (like its lsr twin)
I note the import from sr-mpls and think it a mistake. The routing RFC says
that new protocols should have a presence container to switch the protocol on
and off which sr-mpls does not do but I think that ospf-sr-yang should follow
the guidelines.
There are mentions of vendor augmentations but no indications of what they
might be and, importantly, where they would go. Other I-D, anticipating
augments, include containers explicitly for augments so that different vendors
put the same information in the same place.
I am used to ospfv2 and ospfv3 being derived identities from ospf which makes
reference to one of the other or both simple, as ospf-yang does. Why not here?
I-D references seems to lack
RFC8102
"draft-ietf-rtgwg-segment-routing-ti-lfa -
Latter needs to be Normative since a feature
s.1.1 is ood
router-id is provided by RFC8294 so it should be imported and not be reinvented
here
import ietf-ospfv3-extended-lsa {
lacks a reference clause
leaf preference {
type uint8;
description
"SRMS preference TLV, value from 0 to 255.";
so what? what difference soes it make to be 0 or 255 or 42?
Tom Petch
From: Lsr on behalf of julien.meu...@orange.com
Sent: 05 December 2023 08:15
Hi Acee,
I've looked at the diff: the new version looks good to me. Thanks to the
update.
Regards,
Julien
On 01/12/2023 18:05, Acee Lindem wrote:
> Hi Julien,
>
> Thanks much for your review. I’ve incorporated almost all of your comments
> in the -23 version.
>
> See inline.
>
>> On Nov 29, 2023, at 11:03 AM, julien.meu...@orange.com wrote:
>>
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft. The
>> Routing Directorate seeks to review all routing or routing-related drafts as
>> they pass through IETF last call and IESG review, and sometimes on special
>> request. The purpose of the review is to provide assistance to the Routing
>> ADs. For more information about the Routing Directorate, please see
>> https://wiki.ietf.org/en/group/rtg/RtgDir
>> <https://wiki.ietf.org/en/group/rtg/RtgDir>
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF Last
>> Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>
>> Document: draft-ietf-ospf-sr-yang-22
>> Reviewer: Julien Meuric
>> Review Date: 2023-11-29
>> Intended Status: Standard Tracks
>>
>>
>> *Summary:*
>>
>> This document is basically ready for publication but has nits that should be
>> considered prior to publication.
>>
>>
>> *Comments:*
>>
>> - The very first paragraph of the introduction/overview section summarizes
>> the basis of YANG, XML, JSON, data models... I believe we are now far beyond
>> those general considerations and we could skip that paragraph.
> Removed - thanks.
>
>
>> - In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf
>> "neighbor-router-id" uses type "dotted-quad". This is consistent with RFC
>> 8666 which specifies the associated OSPFv3 TLV, but we had a discussion
>> about the type for router-id in the TE YANG models. The current resolution
>> on TEAS side will be to consider a union of dotted-quad and ipv6-address. I
>> wonder how much RTGWG would be ready to consider a superset of the existing
>> OSPFv3 TLVs.
> This is the OSPF Router-ID which is different from the OSPF TE Router-ID. The
> two should not be confused as the OSPF Router ID is simply a 32 bit unsigned
> integer that is typically represented in dotted quad format. It only need be
> unique within the OSPF Routing Domain. Conversely, the OSPF TE Router ID is a
> routable IPv4 or IPv6 address.
>
> >From RFC 2328 (which was inherited by RFC 5340):
>
> Router ID
> A 32-bit number assigned to each router running the OSPF
> protocol. This number uniquely identifies the router within
> an Autonomous System.
>
>>
>> *Nits:*
>>
>> - Multiple times in description: s/SR specific/SR-specific/
> Fixed.
>
>
[Lsr] RFC8665
I look in vain in the datatracker for RFC8665. Document search finds it, the data tracker does not list it. I realise that it is not a product of the lsr WG but then neither are RFC9129 or RFC8920 AFAICTand they are listed. Odd; well, irritating to be precise. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [yang-doctors] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang
An independant review draft-ississ-sr-yang so top posting.
Not Ready is my take for two major issues (was three but I m confused).
The I-D defines a raft of identity for the SR flags; it uses different names to
those used in the base documents, it gives no explanation why it has done this
and it gives no references. Even without the name changes, I think the
references should be to RFC and section for each flag. Many YANG modules do
this and this one should do too.
The I-D imports from sr-mpls and uses this in XPath to control augmentations.
The title of the I-D is not 'MPLS' but the abstract is. My first take was that
this has nothing to do with MPLS. I do see a lot of noise about IPv6 dataplane
and was expecting both to be included but reading the module it does seem to be
for an MPLS dataplane only [I note that SRv6-yang is an expired I-D) I first
thought that the augmentations were for all SR not just MPLS even if the import
is from SR-MPLS. Then the SPRING WG did put what seems to be a common grouping
in an MPLS module. Perhaps it would be better for this module not to use this
import; I notice too that while most routing protocol augments define a
presence container. as RECOMMENDED in RFC9349, this does not, again a reason to
DIY. So I got confused and would change at least the title in case there is
another I-D for IPv6 and also say something about other dataplanes e.g for
future study.
Thirdly, this I-D uses the term 'perfix' which I have not come across before as
in
=
container perfix-sid-flags {
leaf-list bits {
type identityref {
base prefix-sid-bit;
=
Perhaps one for Terminology
Some minor issues.
Common practice is to make a YANG module a section on its own for ease of
reference. Here it is preceded by other information which I think should be a
separate section.
Author:Yingzhen Qu
<mailto:yingzhen.i...@gmail.com.com>
is not the mail address I see on the list
"IS-IS will not advertise nor receive any mapping server..."
'not receive' implies a filter for such traffic. Perhaps not act upon.
/allows to advertise/advertises/
/allows to enable/controls/
" /* Notifications */ "
probably redundant or else something missing
On to OSPF (so much simpler)
Tom Petch
From: Lsr on behalf of Reshad Rahman
Sent: 14 November 2023 17:17
Hi Acee,
Couple of other differences (I didn't dig to see whether they are justified):
- Naming discrepancies e.g. TLV suffix is used more in OSPF (local-blocks v/s
local-blocks-tlv)
- No global blocks in ISIS
- No capabilities in OSPF
Regards,
Reshad.
On Tuesday, November 14, 2023, 10:11:02 AM EST, Acee Lindem
wrote:
Thanks Reshad - are there any other notable discrepancies?
Thanks,
Acee
> On Nov 14, 2023, at 9:55 AM, Reshad Rahman
> wrote:
>
> My suggestion is that authors of these 2 documents spend some time together
> to try to align the 2 documents. After that we can do YD review.
>
> Regards,
> Reshad.
>
> On Wednesday, November 1, 2023, 10:58:56 AM EDT, Reshad Rahman
> mailto:res...@yahoo.com>> wrote:
>
>
> Hi,
>
> Background: those 2 documents have just been assigned YD review, I am
> reviewing OSPF and Jan is reviewing ISIS.
>
> Was an effort made to keep those 2 documents aligned/in-sync where
> possible/desirable? My expectation is that the SR specifics would be
> near-identical in the 2 documents. e.g. shouldn't the capabilities for the 2
> protocols be very similar.
> Here are some differences which don't seem justified:
> - sr-algorithm in ISIS is a uint8 and in OSPF is an identityref
> - range-size is a uint32 in ISIS and is a uint24 in OSPF
>
>
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/isis:isis/isis:database
> /isis:levels/isis:lsp/isis:router-capabilities:
> +--ro sr-capability
> | +--ro sr-capability
> | | +--ro sr-capability-bits* identityref
> | +--ro global-blocks
> | +--ro global-block* []
> | +--ro range-size? uint32
> | +--ro sid-sub-tlv
> | +--ro sid? uint32
> +--ro sr-algorithms
> | +--ro sr-algorithm* uint8
> +--ro local-blocks
> | +--ro local-block* []
> | +--ro range-size? uint32
> | +--ro sid-sub-tlv
> | +--ro sid? uint32
> +--ro srms-preference
> +--ro preference? uint8
>
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
> /ospf:interfaces/ospf:interface/ospf:database
> /ospf:link-scope-lsa-type/ospf:link-scope-lsas
> /ospf:link-scope-lsa/ospf:version/ospf:ospfv2/ospf:ospfv2
> /ospf:body/ospf:opaque/ospf:ri-opaque:
> +--ro sr-algorithm-tlv
> | +--ro sr-alg
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
My previous message said I was happy with router-id in this i-d. No I am not. I was looking at draft-ietf--sr-yang. I think that this I-D is in error to create its own version of router-id when rfc8294 has defined one for the IETF to use (and RFC8294 which defines it is already an import). I see other minor glitches which I hope to flag next week. Tom Petch From: julien.meu...@orange.com Sent: Thursday, November 30, 2023 08:35 To: tom petch Cc: lsr@ietf.org Subject: Re: RtgDir Last Call Review: draft-ietf-ospf-sr-yang Hi Tom, That looks to me like a human mistake on the CC'ed recipients. Using the directorate web form may have prevented it, but that would have been much less fun. Thanks for your careful checking. I'd be happy to hear your opinion on the router-id type. Julien On 29/11/2023 17:33, tom petch wrote: > Why is this review on rt...@ietf.org and not on lsr@ietf.org? > > Tom Petch > > From: rtgwg on behalf of julien.meu...@orange.com > > Sent: 29 November 2023 16:03 > To: rtg-...@ietf.org > Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rt...@ietf.org > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir > <https://wiki.ietf.org/en/group/rtg/RtgDir> > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ospf-sr-yang-22 > Reviewer: Julien Meuric > Review Date: 2023-11-29 > Intended Status: Standard Tracks > > > *Summary:* > > This document is basically ready for publication but has nits that > should be considered prior to publication. > > > *Comments:* > > - The very first paragraph of the introduction/overview section > summarizes the basis of YANG, XML, JSON, data models... I believe we are > now far beyond those general considerations and we could skip that > paragraph. > - In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf > "neighbor-router-id" uses type "dotted-quad". This is consistent with > RFC 8666 which specifies the associated OSPFv3 TLV, but we had a > discussion about the type for router-id in the TE YANG models. The > current resolution on TEAS side will be to consider a union of > dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to > consider a superset of the existing OSPFv3 TLVs. > > > *Nits:* > > - Multiple times in description: s/SR specific/SR-specific/ > - Multiple times in description: s/flag bits list/flag list/ > - Multiple times in description: s/flags list/flag list/ > - The description fields use a mix of "Adj sid", "adj sid", "Adj SID"... > sometimes with hyphens (not to mention the full expansions). A single > phrase should be chosen and used all along the module. > - A few description starts with "The..." (e.g., in > "ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most > of them don't. For consistency, it should be dropped from every brief > description. > > - In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting > pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/ > - In the same grouping, the description of the container should be > "Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the > following list element). > - In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not > wrong, but should be consistent with others.] > - In the same container (p 26): "s/Topology Independent Loop Free > Alternate/Topology-Independent Loop-Free Alternate/ > - In section 3 (p 37): s/The YANG modules [...] define/The YANG module > [...] defines/ > - In the same section: s/in the modules/in the module/ > - In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/ > > > Thanks, > > Julien > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
From: julien.meu...@orange.com Sent: Thursday, November 30, 2023 08:35 Hi Tom, That looks to me like a human mistake on the CC'ed recipients. Using the directorate web form may have prevented it, but that would have been much less fun. Thanks for your careful checking. I'd be happy to hear your opinion on the router-id type. type or value? I have annotated my copy of the I-D with the word 'Good' alongside the values of the router-type:-) Tom Petch Julien On 29/11/2023 17:33, tom petch wrote: > Why is this review on rt...@ietf.org and not on lsr@ietf.org? > > Tom Petch > > From: rtgwg on behalf of julien.meu...@orange.com > > Sent: 29 November 2023 16:03 > To: rtg-...@ietf.org > Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rt...@ietf.org > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir > <https://wiki.ietf.org/en/group/rtg/RtgDir> > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ospf-sr-yang-22 > Reviewer: Julien Meuric > Review Date: 2023-11-29 > Intended Status: Standard Tracks > > > *Summary:* > > This document is basically ready for publication but has nits that > should be considered prior to publication. > > > *Comments:* > > - The very first paragraph of the introduction/overview section > summarizes the basis of YANG, XML, JSON, data models... I believe we are > now far beyond those general considerations and we could skip that > paragraph. > - In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf > "neighbor-router-id" uses type "dotted-quad". This is consistent with > RFC 8666 which specifies the associated OSPFv3 TLV, but we had a > discussion about the type for router-id in the TE YANG models. The > current resolution on TEAS side will be to consider a union of > dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to > consider a superset of the existing OSPFv3 TLVs. > > > *Nits:* > > - Multiple times in description: s/SR specific/SR-specific/ > - Multiple times in description: s/flag bits list/flag list/ > - Multiple times in description: s/flags list/flag list/ > - The description fields use a mix of "Adj sid", "adj sid", "Adj SID"... > sometimes with hyphens (not to mention the full expansions). A single > phrase should be chosen and used all along the module. > - A few description starts with "The..." (e.g., in > "ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most > of them don't. For consistency, it should be dropped from every brief > description. > > - In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting > pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/ > - In the same grouping, the description of the container should be > "Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the > following list element). > - In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not > wrong, but should be consistent with others.] > - In the same container (p 26): "s/Topology Independent Loop Free > Alternate/Topology-Independent Loop-Free Alternate/ > - In section 3 (p 37): s/The YANG modules [...] define/The YANG module > [...] defines/ > - In the same section: s/in the modules/in the module/ > - In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/ > > > Thanks, > > Julien > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang
Why is this review on rt...@ietf.org and not on lsr@ietf.org? Tom Petch From: rtgwg on behalf of julien.meu...@orange.com Sent: 29 November 2023 16:03 To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rt...@ietf.org Subject: RtgDir Last Call Review: draft-ietf-ospf-sr-yang Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir <https://wiki.ietf.org/en/group/rtg/RtgDir> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-sr-yang-22 Reviewer: Julien Meuric Review Date: 2023-11-29 Intended Status: Standard Tracks *Summary:* This document is basically ready for publication but has nits that should be considered prior to publication. *Comments:* - The very first paragraph of the introduction/overview section summarizes the basis of YANG, XML, JSON, data models... I believe we are now far beyond those general considerations and we could skip that paragraph. - In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf "neighbor-router-id" uses type "dotted-quad". This is consistent with RFC 8666 which specifies the associated OSPFv3 TLV, but we had a discussion about the type for router-id in the TE YANG models. The current resolution on TEAS side will be to consider a union of dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to consider a superset of the existing OSPFv3 TLVs. *Nits:* - Multiple times in description: s/SR specific/SR-specific/ - Multiple times in description: s/flag bits list/flag list/ - Multiple times in description: s/flags list/flag list/ - The description fields use a mix of "Adj sid", "adj sid", "Adj SID"... sometimes with hyphens (not to mention the full expansions). A single phrase should be chosen and used all along the module. - A few description starts with "The..." (e.g., in "ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most of them don't. For consistency, it should be dropped from every brief description. - In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/ - In the same grouping, the description of the container should be "Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the following list element). - In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not wrong, but should be consistent with others.] - In the same container (p 26): "s/Topology Independent Loop Free Alternate/Topology-Independent Loop-Free Alternate/ - In section 3 (p 37): s/The YANG modules [...] define/The YANG module [...] defines/ - In the same section: s/in the modules/in the module/ - In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/ Thanks, Julien ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
From: Aijun Wang Sent: 20 September 2023 10:28 Hi, Tom: My appeal is that it's unfair to ignore the draft that was put forward THREE years earlier than the follower, and we devote intense discussions for this topic along the process, but there is no adoption call. Aijun That seems clear to me. I will shut up now and let the process take its course. Tom Petch Best Regards Aijun Wang China Telecom -邮件原件- 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tom petch 发送时间: 2023年9月15日 18:41 收件人: Aijun Wang ; John Scudder ; cho...@chopps.org 抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 From: Aijun Wang Sent: 15 September 2023 08:08 Hi,John: Thanks in advance for your review for the discussion within the mail list. Normally, the WG adoption call decisions will be coordinated between the Chairs. That’s the reason that I sort the judgement directly from the AD. If the previous results represents only Acee’s preference, we would like to ask Chris to review also all the discussions and expect Chris to solve my concerns that Acee didn’t convince me. The IETF community should respect the initiative idea and adoption decision should be made based on the facts. Aijun The IETF community works on 'rough consensus and running code' to a greater or lesser extent. The descriptions of our processes do not give hard and fast rules about what constitutes consensus and that flexibility is one of the strengths of the IETF. Consensus is judged, by WG Chairs, AD, IESG, IAB, based on what the mailing lists contain. The judgement can be appealed. The result can be one I-D going forward or two or none. Here we currently have consensus declared for one I-D to go forward. I hear you protest and see that as an implicit appeal but I am unclear what you are appealing. The appeal could be that consensus does not reflect what appeared on the list, that the consensus call was not properly made, that there should have been additional consensus calls and so on. You list facts and that is fine but they are only input to my and others' judgement which we then express in response to a consensus call. The facts may persuade some, they may not persuade others but it is the summation of views expressed on the list that determines the consensus, not facts. Tom Petch Hi, Chris: I have asked Acee the following questions (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/<https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/> )and would like to hear your feedback: For the adoption call or merge efforts, I think the WG should consider the following facts: 1) Which draft is the first to provide the use cases? 2) Which draft is the first to propose explicit signaling for unreachable information? 3) Which draft is the first to propose short lived notification? 4) Which explicit signaling mechanism is simpler? 5) Which draft provides more mechanisms to cover more scenarios? The base document should be selected based on the answers of the above questions. John can also refer the above questions when reviewing the past discussions within the list. Aijun Wang China Telecom On Sep 15, 2023, at 04:02, John Scudder wrote: Tom is right of course, and thank you for pointing it out. (The specific section in RFC 2026 to look at is 6.5.1.) In the meantime, I’ll review the mailing list discussion. However, the most desirable outcome would be to settle things at the WG level without further escalation. —John On Sep 14, 2023, at 12:25 PM, tom petch wrote: From: Lsr on behalf of Aijun Wang Sent: 14 September 2023 11:38 Hi, Acee: I admire your efforts for the LSR WG, but for the adoption call of this draft, you have not convinced me, although I gave you large amount of solid facts. Then, it's time to let our AD to step in, to make the non-biased judgement, based on our discussions along the adoption call. I think that what you have in mind is an appeal, as per RFC2026. The first stage therein is to involve the Chairs, and while Acee is one, he is not the only one. Have you involved the other Chair, on or off list? That would seem to me to be next step. Tom Petch We request the WG document be based on the https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$ , because it is the first document to initiate the use case, provide the explicit signaling mechanism, and cover more scenarios. It’s unreasonable to adopt the follower solution and ignore the initiator. We started and lead the discussions THREE years earlier than the current proposal. Aijun Wan
Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
From: Aijun Wang Sent: 15 September 2023 08:08 Hi,John: Thanks in advance for your review for the discussion within the mail list. Normally, the WG adoption call decisions will be coordinated between the Chairs. That’s the reason that I sort the judgement directly from the AD. If the previous results represents only Acee’s preference, we would like to ask Chris to review also all the discussions and expect Chris to solve my concerns that Acee didn’t convince me. The IETF community should respect the initiative idea and adoption decision should be made based on the facts. Aijun The IETF community works on 'rough consensus and running code' to a greater or lesser extent. The descriptions of our processes do not give hard and fast rules about what constitutes consensus and that flexibility is one of the strengths of the IETF. Consensus is judged, by WG Chairs, AD, IESG, IAB, based on what the mailing lists contain. The judgement can be appealed. The result can be one I-D going forward or two or none. Here we currently have consensus declared for one I-D to go forward. I hear you protest and see that as an implicit appeal but I am unclear what you are appealing. The appeal could be that consensus does not reflect what appeared on the list, that the consensus call was not properly made, that there should have been additional consensus calls and so on. You list facts and that is fine but they are only input to my and others' judgement which we then express in response to a consensus call. The facts may persuade some, they may not persuade others but it is the summation of views expressed on the list that determines the consensus, not facts. Tom Petch Hi, Chris: I have asked Acee the following questions (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/<https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/> )and would like to hear your feedback: For the adoption call or merge efforts, I think the WG should consider the following facts: 1) Which draft is the first to provide the use cases? 2) Which draft is the first to propose explicit signaling for unreachable information? 3) Which draft is the first to propose short lived notification? 4) Which explicit signaling mechanism is simpler? 5) Which draft provides more mechanisms to cover more scenarios? The base document should be selected based on the answers of the above questions. John can also refer the above questions when reviewing the past discussions within the list. Aijun Wang China Telecom On Sep 15, 2023, at 04:02, John Scudder wrote: Tom is right of course, and thank you for pointing it out. (The specific section in RFC 2026 to look at is 6.5.1.) In the meantime, I’ll review the mailing list discussion. However, the most desirable outcome would be to settle things at the WG level without further escalation. —John On Sep 14, 2023, at 12:25 PM, tom petch wrote: From: Lsr on behalf of Aijun Wang Sent: 14 September 2023 11:38 Hi, Acee: I admire your efforts for the LSR WG, but for the adoption call of this draft, you have not convinced me, although I gave you large amount of solid facts. Then, it's time to let our AD to step in, to make the non-biased judgement, based on our discussions along the adoption call. I think that what you have in mind is an appeal, as per RFC2026. The first stage therein is to involve the Chairs, and while Acee is one, he is not the only one. Have you involved the other Chair, on or off list? That would seem to me to be next step. Tom Petch We request the WG document be based on the https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$ , because it is the first document to initiate the use case, provide the explicit signaling mechanism, and cover more scenarios. It’s unreasonable to adopt the follower solution and ignore the initiator. We started and lead the discussions THREE years earlier than the current proposal. Aijun Wang China Telecom On Sep 8, 2023, at 23:16, Acee Lindem wrote: The WG adoption call has completed and there is more than sufficient support for adoption. What’s more, vendors are implementing and operators are planning of deploying the extensions. Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. A couple of WG members, while acknowledging the use case, thought that it would be better satisfied outside of the IGPs. In fact, they both offered other viable alternatives. However, with the overwhelming support and commitment to implementation and deployment, we are going forward with WG adoption of this document. As the Co-Chair managing the adoption, I don’t see this optional mechanism as fundamentally changing the IGPs. There was also quite vehement opposition
Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
From: Lsr on behalf of Aijun Wang Sent: 14 September 2023 11:38 Hi, Acee: I admire your efforts for the LSR WG, but for the adoption call of this draft, you have not convinced me, although I gave you large amount of solid facts. Then, it's time to let our AD to step in, to make the non-biased judgement, based on our discussions along the adoption call. I think that what you have in mind is an appeal, as per RFC2026. The first stage therein is to involve the Chairs, and while Acee is one, he is not the only one. Have you involved the other Chair, on or off list? That would seem to me to be next step. Tom Petch We request the WG document be based on the https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/, because it is the first document to initiate the use case, provide the explicit signaling mechanism, and cover more scenarios. It’s unreasonable to adopt the follower solution and ignore the initiator. We started and lead the discussions THREE years earlier than the current proposal. Aijun Wang China Telecom > On Sep 8, 2023, at 23:16, Acee Lindem wrote: > > The WG adoption call has completed and there is more than sufficient support > for adoption. > What’s more, vendors are implementing and operators are planning of deploying > the extensions. > Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. > > A couple of WG members, while acknowledging the use case, thought that it > would be better satisfied outside of the IGPs. > In fact, they both offered other viable alternatives. However, with the > overwhelming support and commitment to implementation > and deployment, we are going forward with WG adoption of this document. As > the Co-Chair managing the adoption, I don’t see > this optional mechanism as fundamentally changing the IGPs. > > There was also quite vehement opposition from the authors of > draft-wang-lsr-prefix-unreachable-annoucement. This draft > purports to support the same use case as well as others (the archives can be > consulted for the discussion). Further discussion > of this other draft and the use cases it addresses should be in the context > of draft-wang-lsr-prefix-unreachable-annoucement > and not the WG draft. > > Thanks, > Acee > >> On Aug 23, 2023, at 3:58 PM, Acee Lindem wrote: >> >> LSR Working Group, >> >> This begins the working group adoption call for “IGP Unreachable Prefix >> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04. >> Please indicate your support or objection on this list prior to September >> 7th, 2023. >> >> Thanks, >> Acee > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-00.txt
Usually, I can look at the datatracker and see what the name of an I-D was prior to WG adoption. I see no such information for this I-D and wonder why. Doubtless at this moment in time, the name will be well-ingrained in peoples' minds but it might be useful to have a reference to at a future date. Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 11 September 2023 12:25 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-00.txt Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-00.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: IGP Unreachable Prefix Announcement Authors: Peter Psenak Clarence Filsfils Stephane Litkowski Daniel Voyer Amit Dhamija Shraddha Hegde Gunter Van de Velde Gyan Mishra Name:draft-ietf-lsr-igp-ureach-prefix-announce-00.txt Pages: 15 Dates: 2023-09-11 Abstract: In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-00 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang
From: Acee Lindem
Sent: 21 August 2023 15:52
Hi Tom,
Thanks for the review.
> On Aug 21, 2023, at 06:57, tom petch wrote:
>
> From: Lsr on behalf of Christian Hopps
>
> Sent: 19 August 2023 01:26
>
> This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
>
> Some stray thoughts from a quick look at -22
>
> ** It is an augmentation of the OSPF base model provided support for
> perhaps provides
>
> /ospf:ospfv3/ospf:body:
> I have forgotten what that final colon does but it is not in the YANG
>
> OLD
> | +--ro prefix-options
> | | +--ro prefix-options* identityref
> NEW
> | +--ro prefix-options
> | | +--ro prefix-option* identityref
> might be clearer with the singular
This is a leaf-list of options. One can debate whether it would be cleaner if
it were singular. However, this is moot point as this is from RFC 9129.
Ah yes, I missed that when reviewing ospf-yang
Tom Petch
>
> identity ospfv3-e-inter-area-router-lsa {
> ...
> reference
> "RFC 8362: OSPFv3 Link State Advertisement (LSA)
> Extensibility, Section 4.3";
> Section 4.4 I think
> I have not checked to see which section the data objects relate to
Fixed.
>
> description
> "Intra-Area Prefix TLV Grouping";
> reference
> "RFC 8362: OSPFv3 Link State Advertisement (LSA)
> Extensibility, Section 3.4";
> Section 3.7 I think
> I have not checked to see which section the data objects relate to
Fixed.
>
> reference
> "RFC 8362: OSPFv3 Link State Advertisement (LSA)
>Extensibility, Appendix B - AreaExtendedLSASupport";
> (twice)
> Appendix B is Area Configuration Parameters
Fixed.
Thanks,
Acee
>
> Tom Petch
>
> Authors,
>
> Please indicate to the list, your knowledge of any IPR related to this work.
>
> Thanks,
> Chris.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang
From: Lsr on behalf of Christian Hopps
Sent: 19 August 2023 01:26
This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
Some stray thoughts from a quick look at -22
** It is an augmentation of the OSPF base model provided support for
perhaps provides
/ospf:ospfv3/ospf:body:
I have forgotten what that final colon does but it is not in the YANG
OLD
| +--ro prefix-options
| | +--ro prefix-options* identityref
NEW
| +--ro prefix-options
| | +--ro prefix-option* identityref
might be clearer with the singular
identity ospfv3-e-inter-area-router-lsa {
...
reference
"RFC 8362: OSPFv3 Link State Advertisement (LSA)
Extensibility, Section 4.3";
Section 4.4 I think
I have not checked to see which section the data objects relate to
description
"Intra-Area Prefix TLV Grouping";
reference
"RFC 8362: OSPFv3 Link State Advertisement (LSA)
Extensibility, Section 3.4";
Section 3.7 I think
I have not checked to see which section the data objects relate to
reference
"RFC 8362: OSPFv3 Link State Advertisement (LSA)
Extensibility, Appendix B - AreaExtendedLSASupport";
(twice)
Appendix B is Area Configuration Parameters
Tom Petch
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Extended LSA: was I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt
From: Acee Lindem Sent: 09 June 2023 16:05 Hi Tom, I believe Yingzhen and I have fixed all of these nits in the -14 version. https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ yes, looks good, Tom Petch > On Jun 1, 2023, at 6:16 AM, tom petch wrote: > > Acee > > My comments all relate to the 'latter I-D', that is to the extended LSAs YANG > model, the one you really want to publish and not to the admin tags (which > you will doubtless want to publish in due course). > > Tom Petch. > _ > From: Acee Lindem > Sent: 31 May 2023 19:44 > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt > > Hi Tom, > > On May 31, 2023, at 06:45, tom petch wrote: > > From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of > Acee Lindem mailto:acee.i...@gmail.com>> > Sent: 28 May 2023 20:35 > > Simply refreshed before expiration and updated a reference. We really need to > publish the extended LSAs YANG model as it is a prerequisite for a lot of > drafts. > > > Regarding the latter, I noted back in 2020 that it was a tough read and that > has not changed, so I will likely only have the energy to review it once and > so will wait for at least WGLC before undertaking such a review. Meanwhile > I see some editorial glitches but would not appreciate a revised I-D unless > and until that WGLC is imminent. > > s.1.1 text is out of date > > I don’t see a problem in -09. I updated with with the full list of normative words. > > > /opf:ospfv3/ospf:body: > here and elsewhere, what is the final colon doing? > > I don’t see this anywhere in the draft. For better or worse, this is the format that “pyang -f tree” provides. > > > > contact URL is out of date > > I’ll update my Email. This is updated. > > > references to OSPF YANG need updating to the RFC > > This is fixed in -09. Fixed. > > > > 'Figure .. ' now appears in four places, doubtless a 'good idea' from the > tool makers. > > There is only “Figure 1”. I agree this is confusing. I’ve removed all the figure designations. Thanks, Acee > > Thanks, > Acee > > > > Like I say, not justifying a new I-D just yet IMHO. > > Tom Petch > > Thanks, > Acee > > On May 28, 2023, at 3:29 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Link State Routing > (LSR) WG of the IETF. > > Title : Extensions to OSPF for Advertising Prefix Administrative > Tags > Authors : Acee Lindem > Peter Psenak > Yingzhen Qu > Filename: draft-ietf-lsr-ospf-admin-tags-08.txt > Pages : 19 > Date: 2023-05-28 > > Abstract: > It is useful for routers in OSPFv2 and OSPFv3 routing domains to be > able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 > were relegated to a single tag and only for AS External and Not-So- > Stubby-Area (NSSA) prefixes. With the flexible encodings provided by > OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, > multiple administrative tags may be advertised for all types of > prefixes. These administrative tags can be used for many > applications including route redistribution policy, selective prefix > prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, > and many others. > > The ISIS protocol supports a similar mechanism that is described in > RFC 5130. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-08.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-admin-tags-08 > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Extended LSA: was I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt
Acee My comments all relate to the 'latter I-D', that is to the extended LSAs YANG model, the one you really want to publish and not to the admin tags (which you will doubtless want to publish in due course). Tom Petch. _ From: Acee Lindem Sent: 31 May 2023 19:44 Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt Hi Tom, On May 31, 2023, at 06:45, tom petch wrote: From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee Lindem mailto:acee.i...@gmail.com>> Sent: 28 May 2023 20:35 Simply refreshed before expiration and updated a reference. We really need to publish the extended LSAs YANG model as it is a prerequisite for a lot of drafts. Regarding the latter, I noted back in 2020 that it was a tough read and that has not changed, so I will likely only have the energy to review it once and so will wait for at least WGLC before undertaking such a review. Meanwhile I see some editorial glitches but would not appreciate a revised I-D unless and until that WGLC is imminent. s.1.1 text is out of date I don’t see a problem in -09. /opf:ospfv3/ospf:body: here and elsewhere, what is the final colon doing? I don’t see this anywhere in the draft. contact URL is out of date I’ll update my Email. references to OSPF YANG need updating to the RFC This is fixed in -09. 'Figure .. ' now appears in four places, doubtless a 'good idea' from the tool makers. There is only “Figure 1”. Thanks, Acee Like I say, not justifying a new I-D just yet IMHO. Tom Petch Thanks, Acee On May 28, 2023, at 3:29 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Link State Routing (LSR) WG of the IETF. Title : Extensions to OSPF for Advertising Prefix Administrative Tags Authors : Acee Lindem Peter Psenak Yingzhen Qu Filename: draft-ietf-lsr-ospf-admin-tags-08.txt Pages : 19 Date: 2023-05-28 Abstract: It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-08.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-admin-tags-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt
From: Lsr on behalf of Acee Lindem Sent: 28 May 2023 20:35 Simply refreshed before expiration and updated a reference. We really need to publish the extended LSAs YANG model as it is a prerequisite for a lot of drafts. Regarding the latter, I noted back in 2020 that it was a tough read and that has not changed, so I will likely only have the energy to review it once and so will wait for at least WGLC before undertaking such a review. Meanwhile I see some editorial glitches but would not appreciate a revised I-D unless and until that WGLC is imminent. s.1.1 text is out of date /opf:ospfv3/ospf:body: here and elsewhere, what is the final colon doing? contact URL is out of date references to OSPF YANG need updating to the RFC 'Figure .. ' now appears in four places, doubtless a 'good idea' from the tool makers. Like I say, not justifying a new I-D just yet IMHO. Tom Petch Thanks, Acee > On May 28, 2023, at 3:29 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Link State Routing > (LSR) WG of the IETF. > > Title : Extensions to OSPF for Advertising Prefix Administrative > Tags > Authors : Acee Lindem > Peter Psenak > Yingzhen Qu > Filename: draft-ietf-lsr-ospf-admin-tags-08.txt > Pages : 19 > Date: 2023-05-28 > > Abstract: > It is useful for routers in OSPFv2 and OSPFv3 routing domains to be > able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 > were relegated to a single tag and only for AS External and Not-So- > Stubby-Area (NSSA) prefixes. With the flexible encodings provided by > OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, > multiple administrative tags may be advertised for all types of > prefixes. These administrative tags can be used for many > applications including route redistribution policy, selective prefix > prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, > and many others. > > The ISIS protocol supports a similar mechanism that is described in > RFC 5130. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-08.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-admin-tags-08 > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Lars Eggert's No Objection on draft-ietf-lsr-ospf-terminology-08: (with COMMENT)
Dropping the IESG from the cc: on the assumption that they already know ... From: Lsr on behalf of Acee Lindem Sent: 25 May 2023 15:51 Hi Lars, > On May 25, 2023, at 2:57 AM, Lars Eggert via Datatracker > wrote: > > Lars Eggert has entered the following ballot position for > draft-ietf-lsr-ospf-terminology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology > > -- > COMMENT: > -- > > # GEN AD review of draft-ietf-lsr-ospf-terminology-07 > > CC @larseggert > > Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review > (https://mailarchive.ietf.org/arch/msg/gen-art/nivmH8c3YlgBr7JSoG7isGH1Vgo). > ## Comments > > ### DOWNREFs > > DOWNREF `[RFC5243]` from this Proposed Standard to Informational `RFC5243`. > (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call > and also seems to not appear in the DOWNREF registry.) > > DOWNREF `[RFC5614]` from this Proposed Standard to Experimental `RFC5614`. > (For > IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and > also seems to not appear in the DOWNREF registry.) > > DOWNREF `[RFC4811]` from this Proposed Standard to Informational `RFC4811`. > (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call > and also seems to not appear in the DOWNREF registry.) We want to keep these down references and update these documents as well. I don’t know what the DOWNREF registry is. https://datatracker.ietf.org/doc/downref/ A registry of documents which have been approved by the IESG for use as DOWNREFs in the past and so do not need further approval or a mention in the Last Call notice Tom Petch > ## Nits > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > ### Grammar/style > > Section 6, paragraph 1 > ``` > and all instances of "Slave" will be rename to "Follower". 7. Update to RFC > ^ > ``` > There may an error in the verb form "be rename". Yes, this should be “be renamed”. I’ve fixed in the -09 version so it doesn’t get lost although the RFC Editor would most likely have found it. Thanks, Acee > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard
From: Les Ginsberg (ginsberg) Sent: 21 April 2023 19:26 Tom - I have submitted V1 to address all of the comments from you that I deemed possible/desirable to do. Please see responses inline as to the unaddressed issues. Ok. I will be interested to see what IANA may (or may not) say about the IANA actions when they review it. Tom Petch > -Original Message- > From: tom petch > Sent: Friday, April 21, 2023 4:55 AM > > From: Les Ginsberg (ginsberg) > Sent: 20 April 2023 17:21 > > Tom - > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > codepoints.xhtml > > At the very top it says: > > "IS-IS TLV Codepoints" > > > John, Les > > Thank you for that, The URL does take me to just that but scrolling down the > IANA pages, I see it not; looking at the source, I see > > IS-IS > > which is what I see on the screen, no other title no notes, no references, > nothing but that is for another (web browser) day. > > Returning to my Obsessive-Compulsive review of the I-D: > > - the IANA registry has references to RFC8919 even for the registries created > by rfc8919bis. Should all the references be updated since the bis obsoletes > 8919? IANA may need telling to do this in my experience. [LES:] I added an instruction to IANA to update the RFC 8919 references. > > 7.2 > the I S - I S"TLV Codepoints Registry". > I see it in the > 'I S - I S Top-Level TLV Codepoints' registry > > 7.3 >IANA has created a new registry titled > "Sub-sub-TLV Codepoints for >Application-Specific Link Attributes" under the "IS-IS TLV > lacks the initial > I S-I S > which given the nature of LSR and he number of registries I think significant > > also, the IANA page has > 17 temporary assignment flex-algo-bw-con > which seems an issue of timing and procedure as to where it should be > mentioned > [LES:] Doing so would create a dependency between this document and draft-ietf-lsr-flex-algo-bw-con - which I do not think is appropriate. I chose not to do this. > 7.4 > Likewise, the IANA page has > bit 3 Flexible Algorithm RFC9350 > which the I-D lacks > [LES:] For the same reason as previous comment, I chose not to do this. Les > 7.5 > you got there before me but IANA starts the name with I S I S > which as above I think significant in this context. > > Tom Petch > > > >Les > > > -Original Message- > > From: tom petch > > Sent: Thursday, April 20, 2023 9:05 AM > > To: John Scudder > > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > > cha...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > > Specific Link Attributes) to Proposed Standard > > > > From: John Scudder > > Sent: 20 April 2023 13:45 > > To: tom petch > > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > > cha...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > > Specific Link Attributes) to Proposed Standard > > > > Hi Tom, > > > > Thanks for catching this, sorry I missed it in my review. The registry is > > now > > named "IS-IS Sub-TLVs for Application-Specific SRLG TLV", so, > > > > OLD: > > 7.5. Sub-TLVs for TLV 238 Registry > > > >IANA has created a new registry titled "Sub-TLVs for TLV 238" under > >the "IS-IS TLV Codepoints" registry to control the assignment of sub- > > > > NEW: > > 7.5. Sub-TLVs for IS-IS Sub-TLVs for Application-Specific SRLG TLV Registry > > > >IANA has created a new registry titled "IS-IS Sub-TLVs for Application- > > Specific SRLG TLV" under > >the "IS-IS TLV Codepoints" registry to control the assignment of sub- > > > > Authors, can you please make the revision when you publish the next > > version? > > > > > > John > > > > I had not got that far:-( My comment was meant to be that there is nothing > I > > can see on the IANA website with the title > > IS-IS TLV Codepoints" > > a reference which appears in several places. I think that there are other > > inconsistencies but decided to work top down and see what I came up with > > and this was at the top. > > > > Tom Petch > > I think hat > > > > > > Thanks, > > > > -John > > > > > On Apr 20, 2023, at 6:41 AM, tom petch wrote: > > > > > > > > > From: Lsr on behalf of The IESG &g
Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard
From: Les Ginsberg (ginsberg) Sent: 20 April 2023 17:21 Tom - https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml At the very top it says: "IS-IS TLV Codepoints" IS-IS which is what I see on the screen, no other title no notes, no references, nothing but that is for another (web browser) day. Returning to my Obsessive-Compulsive review of the I-D: - the IANA registry has references to RFC8919 even for the registries created by rfc8919bis. Should all the references be updated since the bis obsoletes 8919? IANA may need telling to do this in my experience. 7.2 the I S - I S"TLV Codepoints Registry". I see it in the 'I S - I S Top-Level TLV Codepoints' registry 7.3 IANA has created a new registry titled "Sub-sub-TLV Codepoints for Application-Specific Link Attributes" under the "IS-IS TLV lacks the initial I S-I S which given the nature of LSR and he number of registries I think significant also, the IANA page has 17 temporary assignment flex-algo-bw-con which seems an issue of timing and procedure as to where it should be mentioned 7.4 Likewise, the IANA page has bit 3 Flexible Algorithm RFC9350 which the I-D lacks 7.5 you got there before me but IANA starts the name with I S I S which as above I think significant in this context. Tom Petch Les > -Original Message- > From: tom petch > Sent: Thursday, April 20, 2023 9:05 AM > To: John Scudder > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > Specific Link Attributes) to Proposed Standard > > From: John Scudder > Sent: 20 April 2023 13:45 > To: tom petch > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > Specific Link Attributes) to Proposed Standard > > Hi Tom, > > Thanks for catching this, sorry I missed it in my review. The registry is now > named "IS-IS Sub-TLVs for Application-Specific SRLG TLV", so, > > OLD: > 7.5. Sub-TLVs for TLV 238 Registry > >IANA has created a new registry titled "Sub-TLVs for TLV 238" under >the "IS-IS TLV Codepoints" registry to control the assignment of sub- > > NEW: > 7.5. Sub-TLVs for IS-IS Sub-TLVs for Application-Specific SRLG TLV Registry > >IANA has created a new registry titled "IS-IS Sub-TLVs for Application- > Specific SRLG TLV" under >the "IS-IS TLV Codepoints" registry to control the assignment of sub- > > Authors, can you please make the revision when you publish the next > version? > > > John > > I had not got that far:-( My comment was meant to be that there is nothing I > can see on the IANA website with the title > IS-IS TLV Codepoints" > a reference which appears in several places. I think that there are other > inconsistencies but decided to work top down and see what I came up with > and this was at the top. > > Tom Petch > I think hat > > > Thanks, > > -John > > > On Apr 20, 2023, at 6:41 AM, tom petch wrote: > > > > > > From: Lsr on behalf of The IESG secret...@ietf.org> > > Sent: 19 April 2023 21:01 > > To: IETF-Announce > > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; > j...@juniper.net; lsr-cha...@ietf.org; lsr@ietf.org > > Subject: [Lsr] Last Call: (IS-IS > > Application- > Specific Link Attributes) to Proposed Standard > > The IESG has received a request from the Link State Routing WG (lsr) to > > consider the following document: - 'IS-IS Application-Specific Link > > Attributes' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > comments on this action. Please send substantive comments to the > > last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may > > be sent to i...@ietf.org instead. In either case, please retain the > > beginning > > of the Subject line to allow automated sorting. > > > > > > " IANA has created a new registry titled "Sub-TLVs for TLV 238" under > > the "IS-IS TLV Codepoints" registry to control the assignment > > " > > > > When I go to the IANA website I see lots of I S - I S under which it might > > be > but not that particular one. What is it by another name? > > > > Tom Petch > > > > Abstract > > > > > > Existing traffic-engineering-related link attribute advertisements
Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard
From: John Scudder Sent: 20 April 2023 13:45 To: tom petch Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard Hi Tom, Thanks for catching this, sorry I missed it in my review. The registry is now named "IS-IS Sub-TLVs for Application-Specific SRLG TLV”, so, OLD: 7.5. Sub-TLVs for TLV 238 Registry IANA has created a new registry titled "Sub-TLVs for TLV 238" under the "IS-IS TLV Codepoints" registry to control the assignment of sub- NEW: 7.5. Sub-TLVs for IS-IS Sub-TLVs for Application-Specific SRLG TLV Registry IANA has created a new registry titled "IS-IS Sub-TLVs for Application-Specific SRLG TLV" under the "IS-IS TLV Codepoints" registry to control the assignment of sub- Authors, can you please make the revision when you publish the next version? John I had not got that far:-( My comment was meant to be that there is nothing I can see on the IANA website with the title IS-IS TLV Codepoints" a reference which appears in several places. I think that there are other inconsistencies but decided to work top down and see what I came up with and this was at the top. Tom Petch I think hat Thanks, —John > On Apr 20, 2023, at 6:41 AM, tom petch wrote: > > > From: Lsr on behalf of The IESG > > Sent: 19 April 2023 21:01 > To: IETF-Announce > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; > lsr-cha...@ietf.org; lsr@ietf.org > Subject: [Lsr] Last Call: (IS-IS > Application-Specific Link Attributes) to Proposed Standard > The IESG has received a request from the Link State Routing WG (lsr) to > consider the following document: - 'IS-IS Application-Specific Link > Attributes' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may > be sent to i...@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > > " IANA has created a new registry titled "Sub-TLVs for TLV 238" under > the "IS-IS TLV Codepoints" registry to control the assignment > " > > When I go to the IANA website I see lots of I S - I S under which it might > be but not that particular one. What is it by another name? > > Tom Petch > > Abstract > > > Existing traffic-engineering-related link attribute advertisements > have been defined and are used in RSVP-TE deployments. Since the > original RSVP-TE use case was defined, additional applications (e.g., > Segment Routing Policy and Loop-Free Alternates) that also make use > of the link attribute advertisements have been defined. In cases > where multiple applications wish to make use of these link > attributes, the current advertisements do not support application- > specific values for a given attribute, nor do they support indication > of which applications are using the advertised value for a given > link. This document introduces new link attribute advertisements > that address both of these shortcomings. > > This document obsoletes RFC 8919. > > > > > The file can be obtained via > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/__;!!NEt6yMaO-gk!H--jQXaGBKyUh1Ji8-0I02I_lK5h848xPJFQqyeHphMG17NBjPpu__ABg4byU4qG2GbHgH-66efP5g$ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!H--jQXaGBKyUh1Ji8-0I02I_lK5h848xPJFQqyeHphMG17NBjPpu__ABg4byU4qG2GbHgH8CiymDMA$ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard
From: Lsr on behalf of The IESG Sent: 19 April 2023 21:01 To: IETF-Announce Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; lsr-cha...@ietf.org; lsr@ietf.org Subject: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Application-Specific Link Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. " IANA has created a new registry titled "Sub-TLVs for TLV 238" under the "IS-IS TLV Codepoints" registry to control the assignment " When I go to the IANA website I see lots of I S - I S under which it might be but not that particular one. What is it by another name? Tom Petch Abstract Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Identifying an instance
What is the recommended way of identifying an instance of the routing protocol I S I S within a node? draft-ietf-opsawg-service-assurance-yang proposes (Appendix B.5) an unrestricted string, ie almost any Unicode character up to a length of 18446744073709551615 characters long (my favourite number). Is this the recommended way of doing it? Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00
From: Les Ginsberg (ginsberg) Sent: 09 December 2022 00:30 Tom - I don’t want to prolong this thread beyond reason. But I would like to make a few points. I generally find your diligence and attention to detail admirable and usually concur with your recommendations. But in this case, I still have some hesitancy. I do want you to know your comments are being seriously considered, even if - in the end - the drafts are not changed in the way you suggest. Of course. It is rough consensus and I learnt decades ago that I will often be in the rough. But I also know from long before my involvement with the IETF that I get feedback some years down the line along the lines that my suggestions were better than they seemed at the time so I continue to make them (I also know that I could word them better at times). Whatever you come up is ok. Tom Petch More inline. Look for LES2. > -Original Message- > From: tom petch > Sent: Thursday, December 8, 2022 9:00 AM > To: Les Ginsberg (ginsberg) ; Christian Hopps > ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-rfc8920...@ietf.org > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00 > > From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> > Sent: 08 December 2022 15:38 > > Tom - > > > -Original Message- > > From: tom petch mailto:ie...@btconnect.com>> > > Sent: Thursday, December 8, 2022 2:52 AM > > > > From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of > > Christian Hopps > > mailto:cho...@chopps.org>> > > Sent: 07 December 2022 13:20 > > This begins a 2 week WG Last Call, ending Dec 21, 2022, for: > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ > > > > > > Clicking on the URL in Section 15 of the HTML-formatted I-D pulls up a list > > of > > 8642 messages; this may be a quirk of my user-friendly browsers although > it > > does happen with all of them which suggests not. > > [LES:] I'll look into fixing this in the next revision. Thanx. > > > The I-D might benefit from a Terminology section. SABM, for example, is a > > well-known abbreviation in link layer protocols but not in the sense it is > used > > here. > > > [LES:] The first use of SABM (in Section 5 TLV ASCII art) is followed by: > > "SABM Length:Standard Application Identifier Bit Mask Length in octets." > > Do you really think this is not sufficient? > > > yes, I really think that it is not sufficient. It is a very dense I-D as the > lists in s.5 > and s.6 show so I think that a terminology section would help. I was working > with SABM for decades before OSPF repurposed that abbreviation; others > might stumble with e.g LFA or SR although those I do not. > [LES2:] The use of SABM acronym is to make the ASCII art more readable. There is no additional use of this acronym other than in Section 15 which summarizes the changes introduced by the bis draft. Given this contained usage, the probability of confusing this usage with preexisting usage for a Layer 2 protocol like LAPB seems quite low to me - though clearly the possibility came to your mind. And I want you to know that I am old enough to have worked with LAPB, so it isn’t a generational gap. 😊 Although terminology sections are usually benign, given that this document references many acronyms defined elsewhere, the introduction of duplicate definitions always gives me pause - because it is always possible that unintentional differences in wording might suggest a different definition when none is intended. This is why I always prefer references rather than duplication. So, I am reluctant...but I will discuss your suggestion with co-authors. > > > The IANA registry has 28 references to RFC8920; should this be updated? > > [LES:] The IANA section states: > > "This specification updates two existing registries:..." > > Based on this instruction, I assume the IANA folks will update the existing > references to the new RFC. > > > > I never have a problem with giving IANA precise instructions. They are very > good at doing what they are told (even when it is not sensible!). Here you > are asking them to look beyond the IANA Considerations, note that the > references on the website are to an RFC that is being obsoleted and infer the > action needed. > [LES2:] First, I want to say that, in my experience, IANA is simply very good at what they do. That includes following instructions as well as knowing when to question those instructions. Given that the text here is identical to the text in the draft that
Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00
From: Les Ginsberg (ginsberg) Sent: 08 December 2022 15:38 Tom - > -Original Message- > From: tom petch > Sent: Thursday, December 8, 2022 2:52 AM > > From: Lsr on behalf of Christian Hopps > > Sent: 07 December 2022 13:20 > This begins a 2 week WG Last Call, ending Dec 21, 2022, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ > > > Clicking on the URL in Section 15 of the HTML-formatted I-D pulls up a list of > 8642 messages; this may be a quirk of my user-friendly browsers although it > does happen with all of them which suggests not. [LES:] I'll look into fixing this in the next revision. Thanx. > The I-D might benefit from a Terminology section. SABM, for example, is a > well-known abbreviation in link layer protocols but not in the sense it is > used > here. > [LES:] The first use of SABM (in Section 5 TLV ASCII art) is followed by: "SABM Length:Standard Application Identifier Bit Mask Length in octets." Do you really think this is not sufficient? yes, I really think that it is not sufficient. It is a very dense I-D as the lists in s.5 and s.6 show so I think that a terminology section would help. I was working with SABM for decades before OSPF repurposed that abbreviation; others might stumble with e.g LFA or SR although those I do not. > The IANA registry has 28 references to RFC8920; should this be updated? [LES:] The IANA section states: "This specification updates two existing registries:..." Based on this instruction, I assume the IANA folks will update the existing references to the new RFC. I never have a problem with giving IANA precise instructions. They are very good at doing what they are told (even when it is not sensible!). Here you are asking them to look beyond the IANA Considerations, note that the references on the website are to an RFC that is being obsoleted and infer the action needed. Tell them! Tom Petch Les > > Tom Petch > > > Authors, > > Please indicate to the list, your knowledge of any IPR related to this work. > > Thanks, > Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00
From: Lsr on behalf of Christian Hopps Sent: 07 December 2022 13:20 To: lsr@ietf.org This begins a 2 week WG Last Call, ending Dec 21, 2022, for: https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ Clicking on the URL in Section 15 of the HTML-formatted I-D pulls up a list of 8642 messages; this may be a quirk of my user-friendly browsers although it does happen with all of them which suggests not. The I-D might benefit from a Terminology section. SABM, for example, is a well-known abbreviation in link layer protocols but not in the sense it is used here. The IANA registry has 28 references to RFC8920; should this be updated? Tom Petch Authors, Please indicate to the list, your knowledge of any IPR related to this work. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-ogondio-lsr-isis-topology-00.txt
From: Lsr on behalf of Oscar González de Dios
Sent: 06 November 2022 14:35
Dear LSR colleagues,
We have recently submitted a draft to augment ietf-topology Yang model to
include IS-IS information, which was not covered in the different topology
yangs.
The use case that the drafts is targeted is exporting the topology of
network domains from a controller/NMS to planning applications and perform
what-if scenario analysis. Information such as the IS-IS level is required to
fully understand the network topology.
We would appreciate feedback and comments on the draft.
Mmmm sounds challenging.
The prefix in the YANG module must be the same as that specified in the IANA
Considerations.
The prefixes used in the YANG module do not match those in Section 1.4
import ietf-isis {
prefix "ietf-isis";
reference
"RFC 6991: Common YANG Data Types";
I see no ietf-isis in RFC6991; in fact, I see no ietf-isis prefix anywhere in
IETF documents.
(Imported modules should use the prefix from the module definition).
I find single use groupings an unnecessary complication in understanding a
module.
The descriptions of the 'when' clauses is at odds with the description there
of. I suspect that the when clauses are incorrect.
Somewhat challenging:-(
Tom Petch
Best Regards,
Oscar
-Mensaje original-
De: internet-dra...@ietf.org
Enviado el: lunes, 24 de octubre de 2022 19:26
Para: Oscar González de Dios ; Oscar
González de Dios ; SAMIER BARGUIL GIRALDO
; Victor Lopez
Asunto: New Version Notification for draft-ogondio-lsr-isis-topology-00.txt
A new version of I-D, draft-ogondio-lsr-isis-topology-00.txt
has been successfully submitted by Oscar de Dios and posted to the IETF
repository.
Name: draft-ogondio-lsr-isis-topology
Revision: 00
Title: A YANG Data Model for Intermediate System to intermediate
System (ISIS) Topology
Document date: 2022-10-24
Group: Individual Submission
Pages: 13
URL:
https://www.ietf.org/archive/id/draft-ogondio-lsr-isis-topology-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ogondio-lsr-isis-topology/
Html:
https://www.ietf.org/archive/id/draft-ogondio-lsr-isis-topology-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ogondio-lsr-isis-topology
Abstract:
This document defines a YANG data model for representing an abstract
view of the provider network topology that contains Intermediate
System to intermediate System (ISIS) information. This document
augments the 'ietf-network' data model by adding ISIS concepts.
The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA).
The IETF Secretariat
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.
The information contained in this transmission is confidential and privileged
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] ietf-o...@2019-10-17.yang: questions
From: Lsr on behalf of Renato Westphal Sent: 30 September 2022 00:55 Hi Acee, Thanks for your response. Please see my inline comments below. Em qua., 7 de set. de 2022 às 18:05, Acee Lindem (acee) mailto:a...@cisco.com>> escreveu: Thanks for you comments. However, at this point in the cycle, we’re not going to make any additions to the model since it is has already been through the complete review cycle. We will however fix things that are broken. Understood. I only have a couple of additional comments for things that might be worth fixing before the RFC is released: Too late. The I-D, after 1129 days, has completed AUTH48 and its release as an RFC is imminent. Tom Petch 1. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id This leaf's type should be u32 and not u16. 2. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/database/as-scope-lsa-type/as-scope-lsas/as-scope-lsa/ospfv3/body/intra-area-prefix/prefixes/prefix/metric This leaf's type should be u16 and not "ospf-metric" (u32). 3. While the "lls" feature is present in the model, the "ospfv2-lsa-option" base identity is missing an identity for the L-Bit specified by RFC 5613. While that could be added via augmentation, I think it would make sense to have an "l-bit" identity as part of the base model. 4. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/neighbors/neighbor/cost Shouldn't the description be updated to include NBMA networks in addition to p2mp and hybrid networks? 5. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route/next-hops/next-hop This list is keyed by the `next-hop` leaf, which is an IP address. Given that directly connected routes don't have an IP address, shouldn't this be a keyless list instead? Since the local RIB only contains OSPF routes, they always have a next-hop. I was referring to the local RIB, where OSPF connected routes are calculated as a "byproduct" of the SPF algorithm. Example: https://pastebin.com/raw/zyDASfm2 (the connected routes are the ones without nexthops). In any case, section 16.1.1 of RFC 2328 says that nexthop addresses aren't required for point-to-point interfaces. So I'm still wondering whether a keyless list wouldn't be a better option. Best Regards, -- Renato Westphal ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC
On 26/09/2022 18:02, The IESG wrote: The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Flood Reflection' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I am confused by s.8.3 as introduced at AD Review for IANA Considerations. It specifies a new registry with a name that starts 'Sub-sub TLVs for Flood''under the "IS-IS TLV Codepoints" Grouping. Grouping is not a term I recognise. IANA have just responded to a Last Call comment on dnsop-dnssec-bcp to clarify that the preferred terminology is registry and registry group; I cannot recall seeing 'grouping' being used. Further, I cannot see IS-IS TLV Codepoints in any form. IS-IS is one of those rare protocols whose IANA registry are all together under a group with an obvious name so while this I-D does not mention the group name, it is one of those rare cases when that should not be a problem. Second, there are several existing registry of Sub-Sub TLVs so Sub-Sub would seem better - I do note that RFC8401 which created Sub-Sub-TLVs for BIER uses sub-sub! But the significant point is that I do not understand the reference in the Registration Procedures to common expert review guidance for the grouping since I do not know what is meant by a grouping. Tom Petch Abstract This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which L1 areas provide transit forwarding for L2 using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 LSPDUs and are used in the L2 SPF computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than traditionally used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4186/ https://datatracker.ietf.org/ipr/5807/ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]
From: John Scudder Sent: 12 September 2022 13:47 Hi Tom, Needless (?) to say, I’m sympathetic with your position, and thanks for bringing up the parallel case. I take it however, that you aren’t taking the position that this reorganization/restructuring/call it what you will needs to be done by draft-ietf-lsr-ospf-l2bundles, though? Right now it looks to me as though there’s not consensus that it *should* be done in draft-ietf-lsr-ospf-l2bundles, which suggests to me that, - We should ask Ketan to revert to the version where the registry is left untouched (the “nothing” option), - We should then send draft-ietf-lsr-ospf-l2bundles for IETF LC and proceed with the publication process, and concurrently, - Someone who sees value in reorganizing the registry should write a standalone draft to do that, and propose it as a WG draft. Any objection to that approach? That sounds like a good plan, Tom Petch Thanks, —John > On Sep 12, 2022, at 5:33 AM, tom petch wrote: > > From: Lsr on behalf of John Scudder > > Sent: 06 September 2022 22:04 > >> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee) wrote: >> >> I guess if we do decide to either abandon the reorganization suggestion >> altogether, or to pursue it as a separate draft, then >> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of >> listing restrictions in their own subsections of the main spec, do you >> agree? Recall that we got here (in part) because it seemed strange to me to >> update the registry to list some restrictions, but not all of them. >> >> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle >> Attributes" restriction to the IANA registry unless we do it for all the >> Sub-TLVs as you suggest. > > We agree; that was what I meant. All or nothing, either do the whole > reorganization (or whatever you want to call it) or back out the 05 change to > the IANA section and just roll with what was in 04 and earlier. Halfway > doesn’t make a lot of sense to me. > > > All; you have to do it sometime, better sooner than later. > > I see a close parallel with MPLS which got itself into a tangle, attempts to > clarify were rebuffed until eventually the problems were just too great and > the work was done. > > Look at the TLVs registry in the IANA Multiprotocol Label Switching > Architecture (MPLS) Group. I think that you need a strong reason not to > adopt a similar approach (if only for users who use MPLS as well as OSPF). > No need for ten columns, just a structured approach. > > It took a lot of detailed review to get it right - Loa knows that well - but > I believe that the effort was worth it. > > Tom Petch > > —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]
From: Lsr on behalf of John Scudder Sent: 06 September 2022 22:04 > On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee) wrote: > >I guess if we do decide to either abandon the reorganization suggestion > altogether, or to pursue it as a separate draft, then > draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of > listing restrictions in their own subsections of the main spec, do you agree? > Recall that we got here (in part) because it seemed strange to me to update > the registry to list some restrictions, but not all of them. > > [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle > Attributes" restriction to the IANA registry unless we do it for all the > Sub-TLVs as you suggest. We agree; that was what I meant. All or nothing, either do the whole reorganization (or whatever you want to call it) or back out the 05 change to the IANA section and just roll with what was in 04 and earlier. Halfway doesn’t make a lot of sense to me. All; you have to do it sometime, better sooner than later. I see a close parallel with MPLS which got itself into a tangle, attempts to clarify were rebuffed until eventually the problems were just too great and the work was done. Look at the TLVs registry in the IANA Multiprotocol Label Switching Architecture (MPLS) Group. I think that you need a strong reason not to adopt a similar approach (if only for users who use MPLS as well as OSPF). No need for ten columns, just a structured approach. It took a lot of detailed review to get it right - Loa knows that well - but I believe that the effort was worth it. Tom Petch —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding
From: John Scudder Sent: 14 June 2022 21:49 Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem (acee); lsr@ietf.org Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding I’ll point out that option 2 frees us from having to run an annual exception process to renew the code points. I mean, if the draft is being actively worked then of course keep it in draft, but don’t just version-bump it ad infinitum (it wasn’t clear to me if that was what you meant by “continue to refresh”). Another issue I often see is the need to make a Normative Reference to an RFC that is not Standards Track, or BCP, because the authors did not consider it so which then generates extra work for AD and IESG, at least when the issue first arises (as described in RFC4897 and the like). I do agree that we should publish, that Historic is a perfectly good status for it with the above caveat. Experimental seems to me the least attractive, e.g. suitable for a manufacturer private approach which may later be taken up and turned into Standards Track. Tom Petch Thanks, —John > On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) > wrote: > > > John - > > I would be inclined to agree with you - but...to my knowledge (happy to be > corrected...) - > > There has been no interoperability testing. > It is really only possible to do interoperability testing on centralized mode > at present, since distributed mode requires standardization/multi-vendor > implementation of at least one algorithm - which hasn’t happened yet. > So, a significant portion of the protocol extensions remain untested. And > since enthusiasm for this work has waned - perhaps only temporarily - it > seems unlikely that these gaps will be closed in the immediate future. > Moving to standards track RFC with these gaps seems unwise and to some degree > "irresponsible". > > I think there are then three viable paths: > > 1)Continue to refresh the draft until such time as the gaps are closed or it > becomes clear the work is more permanently not of interest > 2)Capture the current contents as an Experimental RFC - noting the remaining > work. > 3)Capture the current contents as a Historic RFC - noting the remaining work. > > I am not in favor of #3. > I would be OK with #1 or #2. > > Les > > >> -Original Message- >> From: Lsr On Behalf Of John E Drake >> Sent: Tuesday, June 14, 2022 11:23 AM >> To: Les Ginsberg (ginsberg) ; John >> Scudder >> Cc: Tony Li ; tom petch ; Acee >> Lindem (acee) ; lsr@ietf.org >> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic- >> flooding >> >> Hi, >> >> I don't understand why we don't just go through the normal Standards track >> process. I am sure there are any number of Standards track RFCs which are >> published and which are neither widely implemented nor widely deployed, >> but which may become so in the future. >> >> As Peter noted in the context of another draft, we are starting to see >> extreme growth in the size of IGPs which to me indicates that the subject >> draft will be perceived as timely in the not too distant future. >> >> Yours Irrespectively, >> >> John >> >> >> Juniper Business Use Only >> >>> -Original Message- >>> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >>> Sent: Tuesday, June 14, 2022 12:19 PM >>> To: John Scudder >>> Cc: Tony Li ; tom petch ; Acee >> Lindem >>> (acee) ; lsr@ietf.org >>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr- >> dynamic- >>> flooding >>> >>> [External Email. Be cautious of content] >>> >>> >>> John - >>> >>> Thanx for the information. >>> >>> I think what is relevant as regards the dynamic-flooding draft is that we >> may be >>> prematurely burying it. >>> It is true, as Tony has stated, that the marketplace has not shown an active >>> interest in deploying this technology - but I am not yet convinced that >>> this is >> the >>> final disposition. As the scale of IGP networks increases and the use of >>> fast- >>> flooding is deployed, it may be that interest in dynamic-flooding is >>> revived. >>> >>> Publishing the draft as Experimental leaves open the possibilities. >>> It could still be moved to Historic somewhere down the road if there >> continues >>> to be no deployment interest. >>> >>> I suppose it is also possible (as your post indic
Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS
From: Lsr on behalf of Les Ginsberg (ginsberg) Sent: 14 June 2022 17:29 Jaideep – I am not aware that any standard formally defines a system-id of .. as invalid. If there is, it would be an ISO specification – but a perusal of ISO 10589, ISO 8348, and ISO 7498 did not yield any such statement. (I would be happy to be corrected if someone has a reference.) >From a practical standpoint, the lack of agreement on this by all >implementations should not represent a significant concern. Schemes which automatically populate the system-id are typically based on the MAC address of some NIC on the box. Another common strategy is to use the zero filled IP address of some loopback. In either case all zeros will not be the result. In cases where the systemid is explicitly configured, it is easy enough NOT to use all 0’s. Looking at draft-isis-yang-isis-cfg, it has a regex for system-id which if I reverse engineer it aright allows for all zero along with all [0-9a-fA-F] Tom Petch HTH Les From: Lsr On Behalf Of Jaideep Choudhary Sent: Tuesday, June 14, 2022 8:00 AM To: Tony Li Cc: supp...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS Hi Tony, I am not looking for technical support, but looking for IETF's perspective regarding the system id in IS-IS. As per the RFC 3784 there is no mention about any invalid value in a system id. Can you please confirm whether there is any such restriction to not to use a SYS ID of .. as per IETF standards ? If this mailing address is not appropriate for answering this query, can you suggest/redirect me to the correct team from IETF ? Thanks. Regards Jaideep On Tue, Jun 14, 2022, 20:19 Tony Li mailto:tony...@tony.li>> wrote: Hi, Neither of these mailing lists are appropriate for technical support. Please contact your vendors directly. Tony On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary mailto:jaideepchoudhar...@gmail.com>> wrote: Hi Team, I would like to know, whether in IS-IS, a system id can be .. or it is an invalid value for sys I'd ? As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention explicitly whether SYS ID of .. could be invalid. Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't talk about any invalid option. The reason I am asking this is that Juniper defines a SYS ID of .. as invalid. https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html This can cause issues in inter-operability as some vendors like Cisco doesn't define a SYS-ID of .. as invalid. I would appreciate your response on this. Regards Jaideep Choudhary On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT, mailto:supp...@ietf.org>> wrote: Hi Jaideep, You have reached the IETF Secretariat, which is the administrative branch of the IETF, and as such, we are not qualified to answer your technical questions. You might have better luck if you try posing your question to the Link State Routing (LSR) Working Group (https://datatracker.ietf.org/wg/lsr/about/). LSR was formed by merging the ISIS and OSPF WGs and assigning all their existing adopted work at the time of chartering to LSR. Their mailing list address is lsr@ietf.org<mailto:lsr@ietf.org>. Best regards, Cindy On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com<mailto:jaideepchoudhar...@gmail.com> wrote: Hi Team, I would like to know, whether in IS-IS, a system id can be .. or it is an invalid value for sys I'd ? As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention explicitly whether SYS ID of .. could be invalid. Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't talk about any invalid option. The reason I am asking this is that Juniper defines a SYS ID of .. as invalid. https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html This can cause issues in inter-operability as some vendors like Cisco doesn't define a SYS-ID of .. as invalid. I would appreciate your response on this. Regards Jaideep Choudhary ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding
From: Lsr on behalf of Acee Lindem (acee) Sent: 10 June 2022 15:10 Initially, there was a lot interest and energy in reducing the flooding overhead in dense drafts. Now, it seems the interest and energy has waned. IMO, this draft contains some very valuable extensions to the IGPs. I discussed this with the editors and one suggestion was to go ahead and publish the draft as “Experimental”. However, before doing this I’d like to get the WG’s opinion on making it experimental rather standards track. Additionally, I know there were some prototype implementations. Have any of those been productized? The trouble with experimental is what happens next? Does it stay experimental for ever or is there some assessment at some point when it becomes Standards Track? What are the criteria? I am not aware of an RFC describing such a process and the IPPM WG seemed uncertain what to do with RFC8321 and RFC8889 when such an issue arose. The shepherd report for 8321 said 'the measurement utility of this extension still is to be demonstrated at a variety of scales in a plurality of network conditions' as the justification for experimental but did not state how that might later be demonstrated. Tom Petch Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: netmod on behalf of Andy Bierman Sent: 14 April 2022 22:25 On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn mailto:randy_pres...@alumni.stanford.edu>> wrote: Hi - On 2022-04-14 1:33 PM, Andy Bierman wrote: > > > On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder > mailto:j.schoenwael...@jacobs-university.de> > <mailto:j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>> > wrote: > > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > > > The proposal is for a 2 year phase to change modules > > that really do want a zone index. It is not blindly removing the > zone > > index. > > People not reading type definitions will also not read a warning > signs. This is blindly removing the zone index in two years, I hardly > see a difference from doing the same (damage) today. > > > A 2 year advance notice is way more than normal in the open source world. > > There does not seem to be any consensus on the general issues or the > specific typedef, > or even agreement that OpenConfig (and RFC 4001) got it right and IETF > got it wrong. > > One set of data models treats a zone index as the normal case, not the > exception, > and the other treats a zone index as the exception. > > Spinning all the YANG modules that use these typedefs is not going to > happen, > and not even clear that would help with multi-SDO integration, given the > disconnect > on the design of the typedefs. ... Why do you believe it is necessary to revise all the YANG modules that use the current typedefs? Have any interoperability problems resulted from the use of the current definitions? The argument that not changing the substance of the current definitions would somehow result in the need to modify the modules that have used the current definitions is a paper tiger, I think. There seems to be many modules where ip-address was used when the intention of the WG was to use ip-address-no-zone. Well, we really do not know. We do know that in the past two years or so, when the meaning of ip-address has been pointed out to YANG module authors, most, but not all, have changed to the no-zone format, suggesting that they were unfamiliar with the use of zones in IPv6. But they may have got it wrong, The flavour of RFC4007 is that from now on, all IPv6 addresses will include a zone in their representation but since that is mostly the default zone and the default zone can be omitted then we do not often see zones in the representation. To quote RFC4007 ' This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index. ' All internal uses! that is what an implementer should be doing with YANG or with anything else. Tom Petch Tom Petch The easiest solution is to do nothing, and force the server implementers to deal with it. A server is obligated to check all client input. Any request with a zone index can be rejected instead of accepted. This solution is compatible with the OpenConfig typedef (unless zone index actually used). Randy Andy ___ netmod mailing list net...@ietf.org<mailto:net...@ietf.org> https://www.ietf.org/mailman/listinfo/netmod ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IP address zones in YANG
From: Lsr on behalf of Rob Wilton (rwilton) Sent: 14 April 2022 13:40 To: net...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] IP address zones in YANG Spinning off part of the discussion into a separate thread, but keeping lsr cc’ed on the discussion. I'm trying to get a better understand of how and where zoned IP addresses should be used in YANG data models. RFC 4007 defines zones for IPv6 addresses, but not for IPv4. Even though RFC 6991 bis has support for a zoned IPv4 address, I'm struggling to see where zoned IPv4 addresses would ever really be used. Does anyone know of any usage or deployments anywhere? For IPv6, my understanding is that the use of the zone is to add the extra interface context for IPv6 link-local addresses. Is there any use of zones outside of this interface context? Yes. See RFC4007. My take is that there is always a zone associated with an IPv6 address but that it may be omitted when it is the default, which it usually is for global scope addresses. For link local, it may not be since some link local addresses appear on all links - e.g. FE80::1 - so when a node has multiple interfaces - the norm for me in datacentres- and the application needs to send a packet over the correct interface - e.g. so that it has the right link layer address to be acceptable to the recipient - then the application, whatever that is that invokes the sending of a packet, must use the correct zone to identify the correct interface. With only one interface, then it is unlikely to be a concern. With global scope addresses, it is unlikely to be a concern. With link local, I always stop and think about zones - IPv6 101! In passing, I note that VRRP requires a link local address with IPv6; I am wondering if it requires zones in the YANG. I was unaware of the existence of zones with IPv4 until I came across them in the YANG types but that is my ignorance - they were always there1! Tom Petch The current definition of ipv6-address type and the ip-address nodes in ietf-ip.yang seem to make zoned IP addresses hard to use. The canonical zone definition in RFC 6991 is for an (presumably unique) numeric zone identifier, but in the YANG management layer it is unclear to me how one maps from this numeric id back to the interface name (e.g., for a client to construct a suitable zoned IP address in configuration). ietf-ip.yang uses ipv6-address-no-zone for interface IP addresses so it isn't possible to get the zone id associated with the link local address. This feels underspecified to me to tie these together and make this work robustly. I also have a general question about what is the best way of modelling this in YANG. Using a zoned ip address is one choice to link an IP address and interface together. Another choice is to have a separate leaf to scope an IP address to a specific interface, wherever that is appropriate and required. E.g., considering the IP RIB YANG model, | |+--rw v6ur:ipv6 | | +--rw v6ur:route* [destination-prefix] | | +--rw v6ur:destination-prefix | | | inet:ipv6-prefix | | +--rw v6ur:description? string | | +--rw v6ur:next-hop | | +--rw (v6ur:next-hop-options) | |+--:(v6ur:simple-next-hop) | || +--rw v6ur:outgoing-interface? | || | if:interface-ref | || +--rw v6ur:next-hop-address? | || inet:ipv6-address Given that an outgoing-interface is already provided then it seems that using a zoned IP address as a next hop address here would potentially be confusing, or at least not required because it is effectively already scoped to the outgoing-interface anyway? It seems like it provides redundant information. Considering another arbitrary protocol YANG module RFC, this time TWAMP, rfc 8913, it seems that some of the ip-address fields in the model could in theory support link local addresses (e.g., the test-session ones), but it is unclear to me whether that was ever the intent, or whether that even makes sense. For the other uses of IP addresses that identify a client or server, it feels like using link local addresses is much less compelling. Modelling these all with the same type seems confusing. | +--rw test-session-request* [name] |+--rw name string |+--rw sender-ip?inet:ip-address |+--rw sender-udp-port? union |+--rw reflector-ip inet:ip-address |+--rw reflector-udp-port? inet:port-number |+--rw timeout? uint64 |+--rw padding-length? uint32 |+--rw test-packet-dscp
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: netmod on behalf of Rob Wilton (rwilton) Sent: 11 April 2022 18:06 Hi all, Thanks for the comments on this thread so far. It would be nice if we are able to come to some sort of rough consensus to a solution. I think that there is consensus that the YANG type ip-address (and the v4/v6 versions) are badly named as the prominent default type name has been given to the unusual variant of including zone information. Based on the comments on this thread, it also seems likely to me that most of the usages of ip-address in YANG RFCs is likely to be wrong, and the intention was that IP addresses without zones was intended. At a rough count, of the published RFC YANG models at github YangModels/standard/ietf/RFC/ to be: 86 uses of ip-address 68 uses of ipv4-address 66 uses of ipv6-address 1 use of ip-address-no-zone 4 uses of ipv4-address-no-zone 4 uses of ipv6-address-no-zone These types appear in 49 out of the 141 YANG modules published in RFCs. At a quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs. As is sometimes the case with the processes of the IETF, this ignores any issues of transition. I have pointed out a significant number of WG that have modules in I-D which include no-zone, in various states, perhaps increasing your figures by an order of magnitude. What are you going to do with I-D e.g. in the RFC Editor queue? Haul them back? I think that the plan below is a bad one. I would introduce types with zone - that is a no-brainer - but would deprecate the existing types. Tom Petch As mentioned previously, it is also worth comparing this to the OpenConfig YANG modules: They have redefined ip-address (and v4/v6 variants) to exclude zone information and have defined separate types include zone information. There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses in the latest OpenConfig github repository. However, approximately a third of the IP address types are still to the ietf-inet-types.yang rather than openconfig-inet-types.yang, so in theory some of those 58 entries could still intentionally be supporting zoned IP addresses, but I would expect that the vast majority would not. I do see some strong benefit if this basic type being defined in the same way in both IETF and OC YANG, and I believe that the OC folks have got the definition right. I see that some are arguing that the zone in the ip-address definition is effectively optional, and implementations are not really obliged to implement it. I don't find that argument compelling, at least not with the current definition of ip-address in RFC 6991. I see a clear difference between a type defined with an incomplete regex that may allow some invalid values and a type that is explicitly defined to included additional values in the allowable value space. Further, I believe that a client just looking at the YANG module could reasonably expect a server that implements a data node using ip-address would be expected to support IP zones, where they are meaningful, or otherwise they should deviate that data node to indicate that they don't conform to the model. We also need to be realistic as to what implementations will do. They are not going to start writing code to support zones just because they are in the model. They will mostly reject IP addresses with zone information. Perhaps some will deviate the type to ip-address-no-zone, but probably most won't. The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all appealing. This would take a significant amount of time/effort and I think that we will struggle to find folks who are willing to do this. Although errata could be used to point out the bug, then can't be used to fix it, all the errata would be "hold for document update" at best. Further, during the time that it would take us to fix it, it is plausible that more incorrect usages of ip-address will likely occur (but perhaps could be policed via scripted checks/warnings). I still feel the right long-term solution here is to get to a state where the "ip-address" type means what 99% of people expect it to mean, i.e., excluding zone information. Given the pushback on making a single non-backwards compatible change to the new definition, I want to ask whether the following might be a possible path that gains wider consensus: (1) In RFC 6991 bis, I propose that we: (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the -no-zone versions. (ii) we change the description of "ip-address" to indicate: - Although the type allows for zone information, many implementations are unlikely to accept zone information in most scenarios (i.e., so the description of the type more accurately reflects reality). - A new ip-address-with-zone type has been introduced to use wher
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: Lsr on behalf of Reshad Rahman
Sent: 10 April 2022 21:42
Inline.
On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee)
wrote:
Hi Chris (as WG member),
On 4/5/22, 10:47 AM, "Christian Hopps"
mailto:cho...@chopps.org>> wrote:
> On Apr 5, 2022, at 09:48, Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
>
> [wg-member]
>
> The thing is that most of the existing RFCs use inet:ip-address rather
inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address
in RFC 6991 BIS to not include the zone similar to what was done in the MIB
(RFC 4001). However, we're getting the passive aggressive treatment on this
point.
>
> If the netmod WG doesn't have the integrity and strength to fix RFC 6991
in the BIS version, we should consider changing the OSPF and IS-IS base
specifications before publication to use inet:ip-address-no-zone.
[as wg-member]
I think we should do the right thing in our (LSR) modules no matter what,
again, what harm does it do to get it right in the modules under LSR WGs direct
control?
Actually this is a very bad idea. We don't want to endorse the error in RFC
6991 that could be fixed in the BIS document. I'm certainly not going to change
the documents I authored when the world expects an IP address to not include a
zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review)
authors about this issue and apparently they agree with me as they chose not to
respond.
Just way behind on IETF emails. I can't speak for the other authors but I don't
agree (too late). But I think we should make the change in 9127-bis. And follow
current guidelines, as others have mentioned, to tackle what's in 6991-bis.
That is the I-D that has just been approved by the IESG!
I do wonder about BFD. Single hop IPv6 would seem to be a case for link local
even if RFC5881 has a SHOULD NOT for using link local; and IPv6 link local is
where the zone may be needed to identify the interface. RFC5881 does not
mention zones.
Tom Petch
Regards,
Reshad.
Thanks,
Acee
The netmod change is a much larger action with a large blast radius (not
saying it's wrong), and perhaps most importantly is also outside of LSR WG
control. :)
Thanks,
Chris.
[wg-member]
> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps"
mailto:cho...@chopps.org>> wrote:
>
>If they are new leaf values why not use the correct no-zone variant,
what's the harm in doing it right? It has a nice side effect of basically
restricting the base spec zone values to no-zone only. :)
>
>Thanks,
>Chris.
>[wg member]
>
>> On Apr 4, 2022, at 12:30, Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
>>
>> In the MIB, the base types don't include the zone -
https://www.ietf.org/rfc/rfc4001.txt
>>
>> It was very unfortunate that the YANG IP addresses included the zone in
the base types.
>>
>> Tom - I think it would be hard to find an author where including the
zone was a conscious decision.
>>
>> Thanks,
>> Acee
>>
>> On 4/4/22, 11:55 AM, "tom petch"
mailto:ie...@btconnect.com>> wrote:
>>
>> From: Acee Lindem (acee) mailto:a...@cisco.com>>
>> Sent: 04 April 2022 15:58
>>
>> Hi Tom, +Juergen, netmod WG,
>>
>> I think the question you ought to be asking is whether the base IPv4
and IPv6 address types should be modified to NOT include the zone and the zone
versions should be added as a separate YANG type.
>>
>> The RFC 6991 is under revision now:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
>>
>> However, I'm not sure if the painful backward compatibility discussions
could be overcome. We'd also have to admit that it was a big mistake to
include the zone in the base addresses. In any case, I don't think we just
start using the no-zone types when the base addresses types are used everywhere.
>>
>>
>>
>> Well, there are plenty of uses of the no-zone types as well, so some
authors, some YANG doctors, have made the conscious choice to use them. I
cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and
there are others.
>>
>> Also, some authors want the zone information as part of their leaf.
>>
>> Tom Petch
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"
mailto:lsr-bo
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: tom petch Sent: 08 April 2022 17:32 From: Lsr on behalf of Joel M. Halpern Sent: 07 April 2022 18:51 Given that you are asking for an incompatible change to an existing module, the shoe would seem to be on the other foot. If you could show it was necessary to make such an incompatible change, then there would be a difficult argument to be had. But you simply have not shown it. (And showing that no one uses the zone field would seem the reasonable and impossible bar for doing such.) I said previously that I saw the DHC and I2NSF WG consciously using no-zone but was not able to check for others. I now can check, in part, and see detnet, MPLS and rtgwg using no-zone. It may be that nvo3, sacm and intarea are other such WGs. Interestingly, I recall one author saying that yes, they needed the zone format and I see that mldp uses a mix of zone and no-zone so that may have been the one I was remembering and it may be a case where a zone is required. I would make sense for that protocol, as it would for other 'local' protocols, such as printing, problem determination and so on. I see another use of no-zone in draft-ietf-lsr-ospf-srv6-yang-01 so the LSR WG is, at times, a user of no-zone. Tom Petch Yours, Joel On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote: > Hi Joel, > > On 4/7/22, 1:18 PM, "Joel M. Halpern" wrote: > > Acee, I am missing something basic. > It seems to me that it would be very wrong for the LSR YANG module to > demand a change to an important type because it turns out that type > doesn't mean what LSR thought it meant. Such an error is LSR's problem, > not the underlying modules. > > There seem to be two fixes. If it is for some reason imperitive to us > the same typedef we have been using, then put in text / patterns / > restrictions saying that this model MUST NOT use the scope field. > > More reasonably, use a different typedef in this model. > > Point me to a usages where the zone is actually desired and supported? > > Acee > > > > > Yours, > Joel > > On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote: > > Hi Martin, > > > > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" > wrote: > > > > Andy Bierman wrote: > > > On Thu, Apr 7, 2022 at 9:11 AM tom petch > wrote: > > > > > > > From: Lsr on behalf of Rob Wilton > (rwilton) > > > > > > > > Sent: 07 April 2022 10:25 > > > > > > > > I basically agree with Acee, and I think that we should do > (b): > > > > > > > > b) Change the types as suggested and accept that > doing so breaks > > > > modules where zone indexes are meaningful. > > > > > > > > > > > > > > > > I am concerned that such behaviour will damage the standing > of the IETF at > > > > large. > > > > > > > > > > > MAY for the client means MUST for the server. > > > > I'm not sure what you mean here. > > > > But I'm also not sure I understand what the real problem is. > Just b/c > > the type allows a zone doesn't mean that all leafs that use this > type > > MUST support a zone. Compare with the value "0.0.0.0". It is a > legal > > value according to the pattern, but it will not be valid in all > places > > where this type is used. And even when an implementation supports > > zones, it will not accept all legal (according to the pattern) > values > > for the zone index. Perhaps the solution is to explain this > > better in the description? > > > > > > > But if no servers actually support it, because the YANG does > not match > > > the operational requirements, then is it really a MUST > requirement? > > > > > > This seems like a bugfix, and the worst thing the IETF could do > wrt/ > > > standing > > > is to force the world to change every module that imports the > typedef. > > > Since many people were not aware of the full syntax, it is not > clear that > > > the WG intent was to include a zone. > > > > It is pretty clear IMO that this w
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: Lsr on behalf of Joel M. Halpern Sent: 07 April 2022 18:51 Given that you are asking for an incompatible change to an existing module, the shoe would seem to be on the other foot. If you could show it was necessary to make such an incompatible change, then there would be a difficult argument to be had. But you simply have not shown it. (And showing that no one uses the zone field would seem the reasonable and impossible bar for doing such.) I said previously that I saw the DHC and I2NSF WG consciously using no-zone but was not able to check for others. I now can check, in part, and see detnet, MPLS and rtgwg using no-zone. It may be that nvo3, sacm and intarea are other such WGs. Interestingly, I recall one author saying that yes, they needed the zone format and I see that mldp uses a mix of zone and no-zone so that may have been the one I was remembering and it may be a case where a zone is required. I would make sense for that protocol, as it would for other 'local' protocols, such as printing, problem determination and so on. Tom Petch Yours, Joel On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote: > Hi Joel, > > On 4/7/22, 1:18 PM, "Joel M. Halpern" wrote: > > Acee, I am missing something basic. > It seems to me that it would be very wrong for the LSR YANG module to > demand a change to an important type because it turns out that type > doesn't mean what LSR thought it meant. Such an error is LSR's problem, > not the underlying modules. > > There seem to be two fixes. If it is for some reason imperitive to us > the same typedef we have been using, then put in text / patterns / > restrictions saying that this model MUST NOT use the scope field. > > More reasonably, use a different typedef in this model. > > Point me to a usages where the zone is actually desired and supported? > > Acee > > > > > Yours, > Joel > > On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote: > > Hi Martin, > > > > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" > wrote: > > > > Andy Bierman wrote: > > > On Thu, Apr 7, 2022 at 9:11 AM tom petch > wrote: > > > > > > > From: Lsr on behalf of Rob Wilton > (rwilton) > > > > > > > > Sent: 07 April 2022 10:25 > > > > > > > > I basically agree with Acee, and I think that we should do > (b): > > > > > > > > b) Change the types as suggested and accept that > doing so breaks > > > > modules where zone indexes are meaningful. > > > > > > > > > > > > > > > > I am concerned that such behaviour will damage the standing > of the IETF at > > > > large. > > > > > > > > > > > MAY for the client means MUST for the server. > > > > I'm not sure what you mean here. > > > > But I'm also not sure I understand what the real problem is. > Just b/c > > the type allows a zone doesn't mean that all leafs that use this > type > > MUST support a zone. Compare with the value "0.0.0.0". It is a > legal > > value according to the pattern, but it will not be valid in all > places > > where this type is used. And even when an implementation supports > > zones, it will not accept all legal (according to the pattern) > values > > for the zone index. Perhaps the solution is to explain this > > better in the description? > > > > > > > But if no servers actually support it, because the YANG does > not match > > > the operational requirements, then is it really a MUST > requirement? > > > > > > This seems like a bugfix, and the worst thing the IETF could do > wrt/ > > > standing > > > is to force the world to change every module that imports the > typedef. > > > Since many people were not aware of the full syntax, it is not > clear that > > > the WG intent was to include a zone. > > > > It is pretty clear IMO that this was not a mistake. The text > > explicitly says: > > > >The IPv4 address may include a zone > >inde
Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: Lsr on behalf of Rob Wilton (rwilton) Sent: 07 April 2022 10:25 I basically agree with Acee, and I think that we should do (b): b) Change the types as suggested and accept that doing so breaks modules where zone indexes are meaningful. I am concerned that such behaviour will damage the standing of the IETF at large. We clearly laid down rules as to what updates were regarded as compatible so that authors of software could be confident that their work was robust and future-proof. We did it with SNMP, inter alia, and we have carried that forward with YANG. To tear up that understanding , creating who knows how much disruption, can only harm the standing of IETF. Much has been said about how implementations have assumed that the address types do not include a zone but no evidence has been put forward for that assertion. I have always assumed that software uses libraries and that the libraries have been written with an understanding of the specifications such that if a zone is received over the wire in conformance with the specification but where the display, field or such like does not allow for a zone, then, tolerant of what to accept, the zone is silently discarded and the address is used without the zone. But, like the assertion that keeping the zone will cause who knows what damage, I have not done the research to substantiate that assumption. Tom Petch I appreciate that this is an NBC change, but I believe that this is the most intuitive definition and is the best choice longer term. I also note that the base ipv4-address/ipv6-address types in OpenConfig (where they use the OC copy/version of inet-types and not ietf-inet-types) don't allow a zone to be specified and assumes the default zone. They have separate types in cases where a zone is allowed to be specified, i.e., aligned to what (b) proposes. For modules that are using/wanting zones (if any), then they can migrate to the new explicit zone type. draft-ietf-netmod-yang-module-versioning, if it keeps its import "revision-or-derived" extension, would also allow such modules to indicate the dependency on the updated revision/definition of ietf-inet-types.yang. Of course, the description associated with the updated ietf-inet-types.yang revision should clearly highly the non-backwards-compatible change to the types. Rob -Original Message- From: iesg On Behalf Of Jürgen Schönwälder Sent: 07 April 2022 08:35 To: Acee Lindem (acee) Cc: lsr@ietf.org; The IESG ; net...@ietf.org Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt Here is roughly what happened: - RFC 6020 (published ~12 years ago) introduced the ip-address type. It included an optional zone index part since zone indexes are necessary in certain situations (e.g., configuring services listening on link-local addresses or clients connecting to services listening on link-local addresses). - RFC 6991 (published ~9 years ago) added the ip-address-no-zone types since people felt that it is useful to also an ip address type without the optional zone part for situations where a zone is not applicable. The name 'ip-address-no-zone' was picked since the name ip-address was already taken. I understand that the names resulting from this evolution of the YANG module confuse people not looking up the type definitions. Let me note that using a type allowing for an optional zone for a leaf that never needs a zone is not a fatal error (its like using an int where a short is sufficient) while using a type not allowing for a zone for a leaf that may need zones is a fatal error (using a short where an int is required) requiring an update of the definition of the leaf to fix. What are our options? a) Do nothing and accept that types are called as they are. b) Change the types as suggested and accept that doing so breaks modules where zone indexes are meaningful. c) Deprecate the types and create a new module defining new types so that modules can opt-in to use better names. d) Deprecate the -no-zone types and move back to have a single type for IP addresses. Any other options? How are we going to pick between them? /js On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote: > Jürgen and netmod WG, +IESG, > > It is not just the IETF models that are using the inet:ip-address for the > standard IPv4/IPv6 addresses without zones. Every vendor’s native models and > the OpenConfig models use the base types and expect the standard IP address > notation. If we don’t fix this, it is something that people can point to as > another example of the IETF being out of touch with reality. > > I thought about more, and it might make the backward compatibility easier if > we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone types and add *-zone types for the remote
Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
From: Acee Lindem (acee) Sent: 04 April 2022 15:58 Hi Tom, +Juergen, netmod WG, I think the question you ought to be asking is whether the base IPv4 and IPv6 address types should be modified to NOT include the zone and the zone versions should be added as a separate YANG type. The RFC 6991 is under revision now: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ However, I'm not sure if the painful backward compatibility discussions could be overcome. We'd also have to admit that it was a big mistake to include the zone in the base addresses. In any case, I don't think we just start using the no-zone types when the base addresses types are used everywhere. Well, there are plenty of uses of the no-zone types as well, so some authors, some YANG doctors, have made the conscious choice to use them. I cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and there are others. Also, some authors want the zone information as part of their leaf. Tom Petch Thanks, Acee On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" wrote: I assume that this is a refresh while waiting for ospf.yang to wind its way through the system I wonder if the ip address should be the no-zone variant from RFC6991 - I never know the answer to that so keep asking. Some time the contact needs updating to https://datatracker and the TLP to 'Revised' Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 07 March 2022 03:14 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt Pages : 29 Date: 2022-03-06 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
I assume that this is a refresh while waiting for ospf.yang to wind its way through the system I wonder if the ip address should be the no-zone variant from RFC6991 - I never know the answer to that so keep asking. Some time the contact needs updating to https://datatracker and the TLP to 'Revised' Tom Petch From: Lsr on behalf of internet-dra...@ietf.org Sent: 07 March 2022 03:14 To: i-d-annou...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt Pages : 29 Date: 2022-03-06 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Update to OSPF Terminology (draft-fox-lsr-ospf-terminology)
From: Lsr on behalf of Christian Hopps Sent: 24 February 2022 14:02 Alvaro Retana writes: > On February 23, 2022 at 8:35:03 PM, Christian Hopps wrote: > > > Chris: > > Hi! > > >> I support these changes, and thanks for taking this up. > > :-) > > >> I guess it makes sense to not go full-in and re-spin the base docs if there >> literally are no other changes (although one wonders if it will actually >> change things like CLIs if we don't). >> >> That said, quite a few errata exist for both of these documents. >> >> Maybe an even better way forward with these types of inclusivity updates, for >> base documents with errata, would be to re-spin the base doc incorporating >> the existing errata *and* the improved terminology. > > Hmmm... That sounds like a lot of work for a couple of words. > > The concern with opening up a big document like rfc2328/rfc5340 is that other > things may creep in: "let's fix this", "let's add that", "let's include the > Updates", "what about security?", etc. It's wouldn't be a lot of work and those fears need not be present if we start the process with things clearly defined. "The *only* changes allowed are to incorporate the already accepted errata, and the terminology change; no other changes will be accepted". That's it, nothing more allowed. That would be the first thing for the WG to agree on, the rest would be editorial changes and shouldn't require much time at all then. This shouldn't be hard to do, and if it is, maybe we're just doing it wrong. :) The problem I have always had with RFC2328, rendering it unusable, is the formatting where spaces have been replace with tabs, at least on every copy I have downloaded from the RFC Editor web site, and several years of trying have never yielded the magic formula as to what the tab settings should be for the document to print in a usable format. I would engage with a 2328bis Tom Petch Thanks, Chris. > > Adam Roach wrote a draft [1] that describes a process for changes like this > (terminology + errata). The IESG has used it a couple of times, but it is not > formal. It would be up to the AD to approve, communicate with the IESG, etc. > > > [BTW, I am not the AD for this WG, nor am I acting as an AD when discussing > this document, and I will recuse myself from IESG discussions about it.] > > > Alvaro. > > > [1] https://datatracker.ietf.org/doc/html/draft-roach-bis-documents ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Issues with master/slave terminology in OSPF
From: Lsr on behalf of Mike Fox Sent: 16 November 2021 20:53 Many companies in the industry including mine are undergoing initiatives to replace offensive terminology in IT. One of the targeted terms is master/slave, which is used in OSPF database exchange and the terms appear in various documentation and displays for our OSPF routing daemon. I'm still waiting on guidance on whether or not industry-standard terms get a pass, but it's not looking good. Has anyone else encountered this issue and if so how have you handled it? If I'm going to need to change to terminology that does not match the RFC I'd like to be consistent with what others are doing. Mike The IESG statement triggered a lengthy discussion on the main IETF list 23jul2020 which was shut down by the IETF Chair as unhelpful 11aug20. (There are references to the 'terminology' list but I do not know what went on there). The use of master and slave got quite an airing and the sense I got was that the referenced documents, of which there are several from several sources, do not address the issue of a controlling and controlled entity as is common in electronics, protocols and engineering in general. There might have been some progress in the past year but I see no evidence thereof. Equally, my sense was that there was no consensus in support of taking draft-knodel as a way forward, political pressure perhaps, but not IETF consensus. Tom Petch Thank you, Mike IBM Enterprise Network Solutions Architecture & Design Research Triangle Park, NC USA ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] how not to distribute an e-mail Re: "Prefix Unreachable Announcement"
From: Lsr on behalf of tom petch Sent: 14 October 2021 16:42 From: Christian Hopps Sent: 14 October 2021 13:13 Does it junk the mail if the one true and proper form is used: "IS-IS" (i.e., with the hyphen)? :) Yes. That is what the thread about Prefix unreachable that Acee kicked off has in the Subject: and it has junked about 60 of those for me. Of course they still exist, I just have to remember to look for them, whereas ones I send with that character string do not make it to the list although they are in the Sent folder. Sometimes it seems to inspect the body and junk on the basis of that but clearly not in this case as I have received your e-mail. It even junked an e-mail that I sent to another WG but I cannot see what it saw in that! Having made some 50 or more reports that this is not junk, then the subsequent e-mails have made it to my Inbox and not the Junk folder so my ESP does take notice eventually! I suspect though that it will not learn and when another message with those four or five characters appear in the Subject: then I will again have to retrieve them from Junk. Of course I do not expect you to stop using the abbreviation, with or without a hyphen - rather I was flagging it in the expectation that others whose domains are serviced by this ESP may be experiencing the same as me but had not noticed. Normally I get very little e-mail classified as Junk (despite getting a lot of phishing e-mail from within the domain). Tom Petch Thanks, Chris. > On Oct 14, 2021, at 7:15 AM, tom petch wrote: > > Top posting for a different topic > > My ESP, one of the larger ones in the world, is classifying most of the LSR > e-mails as junk. Yes, I have reported them as not junk but doubt if it will > make a difference. > > To me it is obvious that anything with that well known abbreviation that was > coined by ISO for their IGP in the subject line is going to receive > unfavourable treatment so it may be that while many are responding there are > others who like me have an ESP who is busy filling their junk folder. > > Equally if I send an e-mall with that abbreviation it goes into a black hole > with no MDN nothirng > > Tom Petch > > ps perhaps this is the considered opinion of the ESP on the I-D:-) > > > From: Lsr on behalf of Acee Lindem (acee) > > Sent: 12 October 2021 20:05 > To: lsr@ietf.org > > Speaking as WG Chairs: > > The authors of “Prefix Unreachable Announcement” have requested an adoption. > The crux of the draft is to signal unreachability of a prefix across OSPF or > areas when area summarization is employed and prefix is summarised. We also > have “ and OSPF Extension for Event Notification” which can be used to > address the same use case. The drafts take radically different approaches to > the problem and the authors of both drafts do not wish to converge on the > other draft’s method so it is understandable that merging the drafts really > isn’t an option. > > Before an adoption call for either draft, I’d like to ask the WG: > > > 1. Is this a problem that needs to be solved in the IGPs? The use case > offered in both drafts is signaling unreachability of a BGP peer. Could this > better solved with a different mechanism (e.g., BFD) rather than flooding > this negative reachability information across the entire IGP domain? > 2. Assuming we do want to take on negative advertisement in the IGP, what > are the technical merits and/or detriments of the two approaches? > > We’ll reserve any further discussion to “WG member” comments on the two > approaches. > > Thanks, > Acee and Chris > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] how not to distribute an e-mail Re: "Prefix Unreachable Announcement"
From: Christian Hopps Sent: 14 October 2021 13:13 Does it junk the mail if the one true and proper form is used: "IS-IS" (i.e., with the hyphen)? :) Yes. That is what the thread about Prefix unreachable that Acee kicked off has in the Subject: and it has junked about 60 of those for me. Of course they still exist, I just have to remember to look for them, whereas ones I send with that character string do not make it to the list although they are in the Sent folder. Sometimes it seems to inspect the body and junk on the basis of that but clearly not in this case as I have received your e-mail. It even junked an e-mail that I sent to another WG but I cannot see what it saw in that! Tom Petch Thanks, Chris. > On Oct 14, 2021, at 7:15 AM, tom petch wrote: > > Top posting for a different topic > > My ESP, one of the larger ones in the world, is classifying most of the LSR > e-mails as junk. Yes, I have reported them as not junk but doubt if it will > make a difference. > > To me it is obvious that anything with that well known abbreviation that was > coined by ISO for their IGP in the subject line is going to receive > unfavourable treatment so it may be that while many are responding there are > others who like me have an ESP who is busy filling their junk folder. > > Equally if I send an e-mall with that abbreviation it goes into a black hole > with no MDN nothirng > > Tom Petch > > ps perhaps this is the considered opinion of the ESP on the I-D:-) > > > From: Lsr on behalf of Acee Lindem (acee) > > Sent: 12 October 2021 20:05 > To: lsr@ietf.org > > Speaking as WG Chairs: > > The authors of “Prefix Unreachable Announcement” have requested an adoption. > The crux of the draft is to signal unreachability of a prefix across OSPF or > areas when area summarization is employed and prefix is summarised. We also > have “ and OSPF Extension for Event Notification” which can be used to > address the same use case. The drafts take radically different approaches to > the problem and the authors of both drafts do not wish to converge on the > other draft’s method so it is understandable that merging the drafts really > isn’t an option. > > Before an adoption call for either draft, I’d like to ask the WG: > > > 1. Is this a problem that needs to be solved in the IGPs? The use case > offered in both drafts is signaling unreachability of a BGP peer. Could this > better solved with a different mechanism (e.g., BFD) rather than flooding > this negative reachability information across the entire IGP domain? > 2. Assuming we do want to take on negative advertisement in the IGP, what > are the technical merits and/or detriments of the two approaches? > > We’ll reserve any further discussion to “WG member” comments on the two > approaches. > > Thanks, > Acee and Chris > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] how not to distribute an e-mail Re: "Prefix Unreachable Announcement"
Top posting for a different topic My ESP, one of the larger ones in the world, is classifying most of the LSR e-mails as junk. Yes, I have reported them as not junk but doubt if it will make a difference. To me it is obvious that anything with that well known abbreviation that was coined by ISO for their IGP in the subject line is going to receive unfavourable treatment so it may be that while many are responding there are others who like me have an ESP who is busy filling their junk folder. Equally if I send an e-mall with that abbreviation it goes into a black hole with no MDN nothirng Tom Petch ps perhaps this is the considered opinion of the ESP on the I-D:-) From: Lsr on behalf of Acee Lindem (acee) Sent: 12 October 2021 20:05 To: lsr@ietf.org Speaking as WG Chairs: The authors of “Prefix Unreachable Announcement” have requested an adoption. The crux of the draft is to signal unreachability of a prefix across OSPF or areas when area summarization is employed and prefix is summarised. We also have “ and OSPF Extension for Event Notification” which can be used to address the same use case. The drafts take radically different approaches to the problem and the authors of both drafts do not wish to converge on the other draft’s method so it is understandable that merging the drafts really isn’t an option. Before an adoption call for either draft, I’d like to ask the WG: 1. Is this a problem that needs to be solved in the IGPs? The use case offered in both drafts is signaling unreachability of a BGP peer. Could this better solved with a different mechanism (e.g., BFD) rather than flooding this negative reachability information across the entire IGP domain? 2. Assuming we do want to take on negative advertisement in the IGP, what are the technical merits and/or detriments of the two approaches? We’ll reserve any further discussion to “WG member” comments on the two approaches. Thanks, Acee and Chris ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
From: Lsr on behalf of Yaron Sheffer Sent: 10 August 2021 14:57 So let me suggest: An offlist suggestion for you to consider OLD Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in [RFC5310] and [RFC5709], if the mechanism described in this document is used. Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any encryption mechanisms to protect the secrecy of the PCED TLV, and the operator must ensure that no private data is carried in the TLV, for example that key names do not reveal sensitive information about the network. NEW Thus before advertising the PCE security parameters, using the mechanism described in this document, the IGP MUST be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in [RFC5304], [RFC5310] or [RFC5709], Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not provide any encryption mechanisms to protect the secrecy of the PCED TLV, then the operator must ensure that no private data is carried in the TLV, e.g. that key names do not reveal sensitive information about the network. Tom Petch Thanks, Yaron On 8/10/21, 15:01, "Qin Wu" wrote: Yaron: Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is. But I prefer to add the addition references in the previous sentence as follows: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in [RFC5310] and [RFC5709] if the mechanism described in this document is used. As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration. " If you better wording, please let me know. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 19:26 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV,
Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110
From: Reshad Rahman Sent: 21 May 2021 00:03 FYI, Mahesh did the extraction of the mpls-te from draft-ietf-bfd-yang and it's been submitted to the RFC Editor. Two months have passed and I see no change in the RFC Editor queue. Whatever was done would appear to have been not enough. I was expecting an action by the AD to be required and have seen no sign thereof which may be relevant. Tom Petch Regards, Reshad. On 2021-03-22, 3:30 PM, "Rtg-bfd on behalf of Yingzhen Qu" wrote: Hi, I also support the split of ietf-bfd-mpls-te module from the base BFD module, so modules like ietf-ospf and ietf-isis can progress. Thanks, Yingzhen > On Mar 22, 2021, at 2:33 AM, tom petch wrote: > > > > From: Rtg-bfd on behalf of Reshad Rahman > Sent: 19 March 2021 18:58 > To: rtg-bfd@ietf. org > Subject: Draft minutes for BFD @ IETF110 > > BFD WG, > > Draft minutes have been posted @ https://datatracker.ietf.org/doc/minutes-110-bfd/ > > Please provide comments to the list by April 2nd. > > > I support Acee's suggestion that the TE part should be split from the BFD YANG draft so that the other three WG, who have been held up for years, can progress. > > Tom Petch > > Copying the LSR WG. > > > Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0 > > Regards, > Reshad. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) Sent: 24 June 2021 19:51 Joel - Thanx for the revised version. While I would still have some editorial comments to make, I think you have done a good job of responding to the comments made. The bigger question for me is whether the draft is needed at all. I am still of the opinion that it is not needed. Again, I am in broad agreement with Les. As I suggested before, I would still add to the Introduction or - probably - Abstract the fact that the assignment of a value to ifType was made by Expert Review. Those who know nothing of IETF procedures will not find it odd that RFC5309 does not contain IANA Considerations. Those that know a little, and see that omission, may think that the correct procedures have not been followed, for assignment. Those who know the spectrum of possibilities will look at the assignment policy, see it is Expert Review and deduce that that is how the assignment was made. And even if there is a more recent RFC to be pointed to, I think it clearer to spell out that Expert Review was how the value was assigned and so not to look for further documentation. Tom Petch. Les > -Original Message- > From: Lsr On Behalf Of Joel M. Halpern > Sent: Thursday, June 24, 2021 5:52 AM > To: tom petch ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > Tom, please look at the latest revision and see if that helps. > > Also note, this document does not assign the ifType. (I.e. it does not > "create an ifType".) That is already done. > > Yours, > Joel > > On 6/24/2021 7:27 AM, tom petch wrote: > > From: Les Ginsberg (ginsberg) > > Sent: 23 June 2021 17:38 > > > > Joel - > > > > I have had concerns from the beginning as to whether this draft is really > needed. > > As I have commented previously, the only content of any significance is > Section 4 - and that only provides example settings of the management fields > for this interface type. > > I question whether a draft is required for this purpose. > > I will defer on this matter to folks more expert in this area than I, but, > > my > opinion is that a draft solely for this purpose is not required. > > > > > > Les has a point. I see a relevant I-D and dive in and review it and do not > stop to think whether or not this work justifies an RFC. Having reviewed it, > and having worked out what is new - as Les says, examples in Section 4 and > not much else - I struggle to see a justification. > > > > The other thought that this brought to mind is why create an ifType value > when the world has been getting on quite happily without it for 13 years? Is > there anything that now needs a value which previously did not? If so, that > might be more suitable for an I-D. > > > > Tom Petch > > > > > > I thought it polite to mention this before you spend the time and effort to > produce a new version. > > > > Les > > > > > >> -Original Message- > >> From: Lsr On Behalf Of tom petch > >> Sent: Wednesday, June 23, 2021 1:43 AM > >> To: Joel M. Halpern ; Harold Liu > >> ; lsr@ietf.org > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> From: Joel M. Halpern > >> Sent: 22 June 2021 09:57 > >> > >> Do Les' suggested edits address your concerns. > >> We will apply yor changes to the IANA considerations section. > >> > >> > >> I would go further than Les as I suggested on Tuesday. Perhaps it is time > for > >> a new version to comment on. > >> > >> Tom Petch > >> > >> Yours, > >> Joel > >> > >> On 6/22/2021 4:34 AM, tom petch wrote: > >>> From: Joel M. Halpern > >>> Sent: 21 June 2021 15:13 > >>> > >>> Tom, 5309 did not define the ifType. Go read 5309. You seem to have > >>> gotten confused by the fact that the IANA entry given to 303 points to > >>> 5309. That was done to have some reference (with the consent of the > >>> experts). What we are doing now is providing a better reference. So > >>> yes, this document defines how the ifType is defined. With no criticism > >>> of 5309, it does not define that, since it does not define the ifType. > >>> > >>> > >>> Stepping back a few e-mails, > >>> I have read 5309 and did point out previously that there is no IANA > >> Considerations in that RFC. What I have said and repeat here is that 5309 > >> defines the p2pOverLan type. That is what the RFC cla
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) Sent: 23 June 2021 17:38 Joel - I have had concerns from the beginning as to whether this draft is really needed. As I have commented previously, the only content of any significance is Section 4 - and that only provides example settings of the management fields for this interface type. I question whether a draft is required for this purpose. I will defer on this matter to folks more expert in this area than I, but, my opinion is that a draft solely for this purpose is not required. Les has a point. I see a relevant I-D and dive in and review it and do not stop to think whether or not this work justifies an RFC. Having reviewed it, and having worked out what is new - as Les says, examples in Section 4 and not much else - I struggle to see a justification. The other thought that this brought to mind is why create an ifType value when the world has been getting on quite happily without it for 13 years? Is there anything that now needs a value which previously did not? If so, that might be more suitable for an I-D. Tom Petch I thought it polite to mention this before you spend the time and effort to produce a new version. Les > -Original Message- > From: Lsr On Behalf Of tom petch > Sent: Wednesday, June 23, 2021 1:43 AM > To: Joel M. Halpern ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > From: Joel M. Halpern > Sent: 22 June 2021 09:57 > > Do Les' suggested edits address your concerns. > We will apply yor changes to the IANA considerations section. > > > I would go further than Les as I suggested on Tuesday. Perhaps it is time for > a new version to comment on. > > Tom Petch > > Yours, > Joel > > On 6/22/2021 4:34 AM, tom petch wrote: > > From: Joel M. Halpern > > Sent: 21 June 2021 15:13 > > > > Tom, 5309 did not define the ifType. Go read 5309. You seem to have > > gotten confused by the fact that the IANA entry given to 303 points to > > 5309. That was done to have some reference (with the consent of the > > experts). What we are doing now is providing a better reference. So > > yes, this document defines how the ifType is defined. With no criticism > > of 5309, it does not define that, since it does not define the ifType. > > > > > > Stepping back a few e-mails, > > I have read 5309 and did point out previously that there is no IANA > Considerations in that RFC. What I have said and repeat here is that 5309 > defines the p2pOverLan type. That is what the RFC claims and that is what it > does. You seem to think that the definition of a type is incomplete without a > numerical value assigned to it, the SMI ifType or YANG identity. The concept > of the type exists whether or not a value has been assigned to it and this is > one of the places where this I-D goes wrong.. > > > > I would say > > Abstract > > The p2pOverLan interface type is described in RFC5309. > > Subsequently, this interface type has been assigned a value of 303 by > IANA, by Expert Review. > > This memo > > > > Well, what does it do? Gives examples of its use? I see nothing more. > > > > Tom Petch > > > > We are explicit in this draft that one of the obvious uses for this > > ifType is to trigger 5309 behavior. > > > > Yours, > > Joel > > > > On 6/21/2021 4:41 AM, tom petch wrote: > >> From: Lsr on behalf of Harold Liu > > >> Sent: 21 June 2021 02:01 > >> > >> Hi Med and All: > >> Thanks for your helpful comments, I have updated a new version 01 > to follow the comments; > >> The main updating is: > >> 1. More clearly described the intend of this draft in the > >> introduction; > >> 2. Change the reference style; > >> 3. Refactor the reference section to make it more reasonable; > >> 4. I haven't change "IANA Consideration" at the moment given there > is lots of discussion in this part and it is still up in the air, I will > change this > section next update the document once this part is finalized; > >> > >> > >> I still think that this is an unsatisfactory I-D and would oppose adoption > >> in > its present form, > >> > >> It is a question of veracity. It claims to do what others have already > >> done > and does so without reference, without acknowledgement. Having the > same data defined in more than one place can only create confusion, in > future if not now. > >> > >> This is a pattern and starts with the Abstract and continues t
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 22 June 2021 09:57 Do Les' suggested edits address your concerns. We will apply yor changes to the IANA considerations section. I would go further than Les as I suggested on Tuesday. Perhaps it is time for a new version to comment on. Tom Petch Yours, Joel On 6/22/2021 4:34 AM, tom petch wrote: > From: Joel M. Halpern > Sent: 21 June 2021 15:13 > > Tom, 5309 did not define the ifType. Go read 5309. You seem to have > gotten confused by the fact that the IANA entry given to 303 points to > 5309. That was done to have some reference (with the consent of the > experts). What we are doing now is providing a better reference. So > yes, this document defines how the ifType is defined. With no criticism > of 5309, it does not define that, since it does not define the ifType. > > > Stepping back a few e-mails, > I have read 5309 and did point out previously that there is no IANA > Considerations in that RFC. What I have said and repeat here is that 5309 > defines the p2pOverLan type. That is what the RFC claims and that is what it > does. You seem to think that the definition of a type is incomplete without > a numerical value assigned to it, the SMI ifType or YANG identity. The > concept of the type exists whether or not a value has been assigned to it and > this is one of the places where this I-D goes wrong.. > > I would say > Abstract > The p2pOverLan interface type is described in RFC5309. > Subsequently, this interface type has been assigned a value of 303 by IANA, > by Expert Review. > This memo .... > > Well, what does it do? Gives examples of its use? I see nothing more. > > Tom Petch > > We are explicit in this draft that one of the obvious uses for this > ifType is to trigger 5309 behavior. > > Yours, > Joel > > On 6/21/2021 4:41 AM, tom petch wrote: >> From: Lsr on behalf of Harold Liu >> >> Sent: 21 June 2021 02:01 >> >> Hi Med and All: >> Thanks for your helpful comments, I have updated a new version 01 >> to follow the comments; >> The main updating is: >> 1. More clearly described the intend of this draft in the >> introduction; >> 2. Change the reference style; >> 3. Refactor the reference section to make it more reasonable; >> 4. I haven't change "IANA Consideration" at the moment given there >> is lots of discussion in this part and it is still up in the air, I will >> change this section next update the document once this part is finalized; >> >> >> I still think that this is an unsatisfactory I-D and would oppose adoption >> in its present form, >> >> It is a question of veracity. It claims to do what others have already done >> and does so without reference, without acknowledgement. Having the same >> data defined in more than one place can only create confusion, in future if >> not now. >> >> This is a pattern and starts with the Abstract and continues throughout the >> I-D. >> >> Thus the Abstract claims 'this defines point-to-point interface type'. No. >> This type was defined in RFC5309 and you need to say that and to say what if >> anything you are changing in that definition. You should not reproduce text >> from that RFC unless you have to and then you should make it clear you are >> quoting. >> >> You do the same with Figure 1. This is a copy, may be accurate may be not, >> it does not matter, from RFC8343 with no mention thereof. You should not be >> reproducing such text without a good reason and then you should make it >> clear what is reproduced, from where and why. >> >> And as I have said already, IANA Considerations is yet again claiming to do >> what has already happened which can only confuse. All that is needed as I >> said in a separate note is to ask IANA to update two references, nothing >> more. >> >> Tom Petch >> >> And I would like to share more background information for this >> internet draft: >> As Joel mentioned, we requested and received an IF Type assignment >> from IANA (with expert review) for point-to-point over Ethernet links >> several weeks ago and the p2pOverLan type is already added to IANA registry >> now; >> During the discussion around the assignment we noticed a doc >> describing why that is needed and how to use that would be helpful; >> For example, if no entry saying p2pOverLan layer over ethernet, the >> management will suffer since lose the ability to get to the >> Ethernet-speci
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) Sent: 21 June 2021 20:06 inline (sorry that my web browser messes up e-mail) Joel - In addition to the IANA section changes, 1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over LAN" - not simply "Point to Point" 2)I think the abstract/introduction should make it clear that this draft is specifying the management mappings for the " Point to Point (P2P) Interface over LAN". It is NOT defining Point to Point (P2P) Interface over LAN operation - that clearly was already done by RFC 5309. As previously, I suggest Abstract The p2pOverLan interface type is described in RFC 5309. Subsequently, this interface type has been assigned a value of 303 by IANA, by Expert Review. This memo Well, what does it do? Gives examples of its use? That is what I see. 3)I don’t know if Section 3 is really needed. I tend to think not. But if you do want to keep it, please Reference RFC 8343 Section 4 as this is clearly a copy of the Figure in that document/section. I agree, not needed. I would also moderate the claim that this is the predominant circuit type for OSPF. That may be true for IX or PE-CE but not for the Enterprise LAN that I see. Widely used by ISP perhaps. I do not see this type enabling routing protocols to select the right mode automatically; theoretically possible but ospf-yang requires explicit configuration thereof. Requirements language should use RFC8174. With the revised IANA Considerations, there is no need for Security Considerations to make any mention of YANG. Tom Petch Les > -Original Message- > From: Joel Halpern Direct > Sent: Monday, June 21, 2021 8:47 AM > To: Les Ginsberg (ginsberg) ; tom petch > ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > The change Tom has proposed to the IANA considerations section is fine > with me. > > If there are other specific changes that will make it clearer, I and my > co-authors are happy to make those. I have tried looking at the text. > Even before you found it misleading, I did conclude that Tom getting > the wrong impression meant it needs to be clarified. But as I am having > trouble seeing what misled you, I can not suggest wording improvements > to my co-authors. > > I presume from your phrasing that you want more changes than just to the > IANA considerations section. I presume I am just being dense in not > seeing the rest. I apologize, but that does not make me less dense. > Sorry. > > Help? > Joel > > On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: > > Joel - > > > > I am not objecting to the draft. > > I am simply asking for it to be both clear and accurate in what it is > > actually > doing. > > > > I think Tom has done an excellent job of pointing out the inaccuracies and > in some cases providing proposed revised text. > > > > I would ask you to reread your own draft in the context that at least two > people have read it and found it inaccurate and both of us have made very > explicit points about what language is confusing. > > > > Les > > > >> -Original Message- > >> From: Joel Halpern Direct > >> Sent: Monday, June 21, 2021 8:13 AM > >> To: Les Ginsberg (ginsberg) ; tom petch > >> ; Harold Liu > >> ; lsr@ietf.org > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> Les, I am missing something ion both your and Tom's comments. 5309 > >> didn't define the ifType. If you look at 5309, it has no IANA > >> considerations at all. > >> > >> Yes, this document should talk about 5309 as one of the cases that the > >> ifType simplifies. And it does. > >> > >> This documents follows the lead of 8343 in defining this specific ifType. > >> > >> Let's be clear. We were asked, quite reasoanbly, by the expert, when we > >> requested the IANA code point, to please submit a document describing > >> how the dcode point would be used, rather than merely pointing at 5309 > >> and assuming everyone could guess correctly. (Guessing is not good for > >> standards.) > >> So we are trying to do so. > >> > >> You seem to be objecting to our doing so. Why? > >> > >> If the working group really doesn't want a description, we can go away. > >>We have the code point we felt was useful. But it seems much more > >> useful to actually provide meaningful documentation. > >> > >> Yours, > >> Joel > >> > >> > >>
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 21 June 2021 15:13 Tom, 5309 did not define the ifType. Go read 5309. You seem to have gotten confused by the fact that the IANA entry given to 303 points to 5309. That was done to have some reference (with the consent of the experts). What we are doing now is providing a better reference. So yes, this document defines how the ifType is defined. With no criticism of 5309, it does not define that, since it does not define the ifType. Stepping back a few e-mails, I have read 5309 and did point out previously that there is no IANA Considerations in that RFC. What I have said and repeat here is that 5309 defines the p2pOverLan type. That is what the RFC claims and that is what it does. You seem to think that the definition of a type is incomplete without a numerical value assigned to it, the SMI ifType or YANG identity. The concept of the type exists whether or not a value has been assigned to it and this is one of the places where this I-D goes wrong.. I would say Abstract The p2pOverLan interface type is described in RFC5309. Subsequently, this interface type has been assigned a value of 303 by IANA, by Expert Review. This memo Well, what does it do? Gives examples of its use? I see nothing more. Tom Petch We are explicit in this draft that one of the obvious uses for this ifType is to trigger 5309 behavior. Yours, Joel On 6/21/2021 4:41 AM, tom petch wrote: > From: Lsr on behalf of Harold Liu > > Sent: 21 June 2021 02:01 > > Hi Med and All: > Thanks for your helpful comments, I have updated a new version 01 to > follow the comments; > The main updating is: > 1. More clearly described the intend of this draft in the > introduction; > 2. Change the reference style; > 3. Refactor the reference section to make it more reasonable; > 4. I haven't change "IANA Consideration" at the moment given there is > lots of discussion in this part and it is still up in the air, I will change > this section next update the document once this part is finalized; > > > I still think that this is an unsatisfactory I-D and would oppose adoption in > its present form, > > It is a question of veracity. It claims to do what others have already done > and does so without reference, without acknowledgement. Having the same data > defined in more than one place can only create confusion, in future if not > now. > > This is a pattern and starts with the Abstract and continues throughout the > I-D. > > Thus the Abstract claims 'this defines point-to-point interface type'. No. > This type was defined in RFC5309 and you need to say that and to say what if > anything you are changing in that definition. You should not reproduce text > from that RFC unless you have to and then you should make it clear you are > quoting. > > You do the same with Figure 1. This is a copy, may be accurate may be not, > it does not matter, from RFC8343 with no mention thereof. You should not be > reproducing such text without a good reason and then you should make it clear > what is reproduced, from where and why. > > And as I have said already, IANA Considerations is yet again claiming to do > what has already happened which can only confuse. All that is needed as I > said in a separate note is to ask IANA to update two references, nothing > more. > > Tom Petch > > And I would like to share more background information for this > internet draft: > As Joel mentioned, we requested and received an IF Type assignment > from IANA (with expert review) for point-to-point over Ethernet links several > weeks ago and the p2pOverLan type is already added to IANA registry now; > During the discussion around the assignment we noticed a doc > describing why that is needed and how to use that would be helpful; > For example, if no entry saying p2pOverLan layer over ethernet, the > management will suffer since lose the ability to get to the Ethernet-specific > management properties (Ethernet MIB or YANG model) via many tools; So we > propose this draft to define a complete p2pOverLan ifStack(Including higher > layer and lower layer); > > Brs > > -Original Message- > From: mohamed.boucad...@orange.com > Sent: Thursday, June 17, 2021 2:16 PM > To: Joel M. Halpern ; draft-liu-lsr-p2pover...@ietf.org > Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > Hi Joel, all, > > Please find some quick comments to this draft, fwiw: > > * pdf: > https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337-41fd-bf1b-56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIE
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Lsr on behalf of Harold Liu Sent: 21 June 2021 02:01 Hi Med and All: Thanks for your helpful comments, I have updated a new version 01 to follow the comments; The main updating is: 1. More clearly described the intend of this draft in the introduction; 2. Change the reference style; 3. Refactor the reference section to make it more reasonable; 4. I haven't change "IANA Consideration" at the moment given there is lots of discussion in this part and it is still up in the air, I will change this section next update the document once this part is finalized; I still think that this is an unsatisfactory I-D and would oppose adoption in its present form, It is a question of veracity. It claims to do what others have already done and does so without reference, without acknowledgement. Having the same data defined in more than one place can only create confusion, in future if not now. This is a pattern and starts with the Abstract and continues throughout the I-D. Thus the Abstract claims 'this defines point-to-point interface type'. No. This type was defined in RFC5309 and you need to say that and to say what if anything you are changing in that definition. You should not reproduce text from that RFC unless you have to and then you should make it clear you are quoting. You do the same with Figure 1. This is a copy, may be accurate may be not, it does not matter, from RFC8343 with no mention thereof. You should not be reproducing such text without a good reason and then you should make it clear what is reproduced, from where and why. And as I have said already, IANA Considerations is yet again claiming to do what has already happened which can only confuse. All that is needed as I said in a separate note is to ask IANA to update two references, nothing more. Tom Petch And I would like to share more background information for this internet draft: As Joel mentioned, we requested and received an IF Type assignment from IANA (with expert review) for point-to-point over Ethernet links several weeks ago and the p2pOverLan type is already added to IANA registry now; During the discussion around the assignment we noticed a doc describing why that is needed and how to use that would be helpful; For example, if no entry saying p2pOverLan layer over ethernet, the management will suffer since lose the ability to get to the Ethernet-specific management properties (Ethernet MIB or YANG model) via many tools; So we propose this draft to define a complete p2pOverLan ifStack(Including higher layer and lower layer); Brs -Original Message- From: mohamed.boucad...@orange.com Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; draft-liu-lsr-p2pover...@ietf.org Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Hi Joel, all, Please find some quick comments to this draft, fwiw: * pdf: https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337-41fd-bf1b-56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-rev%2520Med.pdf * doc: https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-938b18d2-86073b36ea28-e0406a2599fa2a6d&q=1&e=d4a020c9-b337-41fd-bf1b-56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-rev%2520Med.docx Cheers, Med > -Message d'origine- > De : Lsr [mailto:lsr-boun...@ietf.org] De la part de Joel M. Halpern > Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee) > ; lsr@ietf.org Objet : Re: [Lsr] Fwd: I-D Action: > draft-liu-lsr-p2poverlan-00.txt > > This document (and the code point) are intended to be in line with > 5309. > I believe they are. If we got it wrong, please help us fix it. > > A reference would be reasonable to add. (The IANA entry for the code > point does reference 5309.) > > Thank you, > Joel > > > > On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote: > > Hi Joel, > > > > At first I wondered where this document should reside and then > decided that LSR is probably as good as any other place. > > > > Can you guys check whether it is mostly in line with > https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it > should be referenced? > > > > Thanks, > > Acee > > > > > > On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" boun...@ietf.org on behalf of j...@joelhalpern.com> wrote: > > > > Recently, Ericsson requested and received an IF Type > assignment from > > IANA (with expert review) for point-to-point over Ethernet > links. > > > > It was noted during the discussion around t
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 18 June 2021 17:41 How can we clarify the wording. If it is misleading you, we need to improve it. The text is not asking to create an entry (i.e. it does not "ask for an assignment"), but rather to change an entry that already exists. (And obviously, it won't do so until and if the document becomes an RFC.) NEW "IANA Considerations In the Interface Types registry, IANA has previously assigned a value of 303 for p2pOverLan with a reference of RFC5309. IANA is requested to amend the reference to point to this document and to make a similar amendment in the YANG iana-if-type module which currently points to RFC8561." I see no need for any more action by IANA; it is the sort of request that has been made many times before when one RFC obsoletes another The body of the document might say more, e.g. that value 303 was assigned for interface type ap2pOverLan by Expert review which caused IANA to add the entries to the MIB module and the YANG module but IANA do not need to be told that - they did it! Tom Petch Yours, Joel On 6/18/2021 12:20 PM, tom petch wrote: > From: Joel M. Halpern > Sent: 18 June 2021 16:29 > > Tom, I am not sure what you mean by "the update has happened"> The code > point has been assigned. Assuming this document becomes an RFC, it will > be significantly clearer if the 303 code point IANA entry points at this > for information instead of 5309. So this document requests that update. > > > I mean that the IANA Registry has been updated to include 303 with a > reference to 5309 so I think it wrong of this I-D to ask for assignment which > is what I see it doing with > > IANA need to update the "Interface Types(ifType)" with the following status > types: > >| 303| p2pOverLan |Point to Point over LAN interface | > > It should only ask for the reference to be changed and should also spell > out that the assignment was made by Expert Review since that may otherwise be > unclear to users.. > > Likewise the update to the YANG module is automatic, has happened and so > specifying it here can only confuse IMHO. > > And elsewhere I find the flavour misleading. The abstract and introduction > should IMHO reference RFC5309 as the source of p2pOverLan, add that the > values have been assigned by Expert Review and that this I-D ... well I am > not clear what it does except lay claim to things that others have already > done with RFC5309 and expert review :-) > > I think too that camel case is problematic. SMI uses it, YANG does not but > we are now likely stuck with identity p2pOverLan . > > Tom Petch > > Yours, > Joel > > On 6/18/2021 7:47 AM, tom petch wrote: >> From: Lsr on behalf of Joel M. Halpern >> >> Sent: 16 June 2021 21:46 >> >> This document (and the code point) are intended to be in line with 5309. >> I believe they are. If we got it wrong, please help us fix it. >> >> A reference would be reasonable to add. (The IANA entry for the code >> point does reference 5309.) >> >> >> which confused me as RFC5309 has no IANA considerations and no reference to >> 303. I understand how this is so but think that this I-D could explain >> this. I think that the I-D is wrong to ask IANA to perform an update - the >> update has happened. >> >> What would help would be for this I-D to explain that the allocation was >> made by Expert Review and to ask that IANA update the reference to point to >> this I-D and then this I-D can point back to RFC5309. This is almost an >> updates to 5309 as it give a value to the specification - I can see the IESG >> having fun with that concept but I would go for it. >> >> I think too that this I-D should reference and build on RFC5309. At present >> it looks like an Unused Ref. >> >> Tom Petch >> >> >> >> Thank you, >> Joel >> >> >> >> On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote: >>> Hi Joel, >>> >>> At first I wondered where this document should reside and then decided that >>> LSR is probably as good as any other place. >>> >>> Can you guys check whether it is mostly in line with >>> https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it >>> should be referenced? >>> >>> Thanks, >>> Acee >>> >>> >>> On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" >>> wrote: >>> >>>Recently, Ericsson requested and received an IF Type assignment from >>>IANA (with expert review) for
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 18 June 2021 16:29 Tom, I am not sure what you mean by "the update has happened"> The code point has been assigned. Assuming this document becomes an RFC, it will be significantly clearer if the 303 code point IANA entry points at this for information instead of 5309. So this document requests that update. I mean that the IANA Registry has been updated to include 303 with a reference to 5309 so I think it wrong of this I-D to ask for assignment which is what I see it doing with IANA need to update the "Interface Types(ifType)" with the following status types: | 303| p2pOverLan |Point to Point over LAN interface | It should only ask for the reference to be changed and should also spell out that the assignment was made by Expert Review since that may otherwise be unclear to users.. Likewise the update to the YANG module is automatic, has happened and so specifying it here can only confuse IMHO. And elsewhere I find the flavour misleading. The abstract and introduction should IMHO reference RFC5309 as the source of p2pOverLan, add that the values have been assigned by Expert Review and that this I-D ... well I am not clear what it does except lay claim to things that others have already done with RFC5309 and expert review :-) I think too that camel case is problematic. SMI uses it, YANG does not but we are now likely stuck with identity p2pOverLan . Tom Petch Yours, Joel On 6/18/2021 7:47 AM, tom petch wrote: > From: Lsr on behalf of Joel M. Halpern > > Sent: 16 June 2021 21:46 > > This document (and the code point) are intended to be in line with 5309. >I believe they are. If we got it wrong, please help us fix it. > > A reference would be reasonable to add. (The IANA entry for the code > point does reference 5309.) > > > which confused me as RFC5309 has no IANA considerations and no reference to > 303. I understand how this is so but think that this I-D could explain this. > I think that the I-D is wrong to ask IANA to perform an update - the update > has happened. > > What would help would be for this I-D to explain that the allocation was made > by Expert Review and to ask that IANA update the reference to point to this > I-D and then this I-D can point back to RFC5309. This is almost an updates > to 5309 as it give a value to the specification - I can see the IESG having > fun with that concept but I would go for it. > > I think too that this I-D should reference and build on RFC5309. At present > it looks like an Unused Ref. > > Tom Petch > > > > Thank you, > Joel > > > > On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote: >> Hi Joel, >> >> At first I wondered where this document should reside and then decided that >> LSR is probably as good as any other place. >> >> Can you guys check whether it is mostly in line with >> https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it >> should be referenced? >> >> Thanks, >> Acee >> >> >> On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" >> wrote: >> >> Recently, Ericsson requested and received an IF Type assignment from >> IANA (with expert review) for point-to-point over Ethernet links. >> >> It was noted during the discussion around the assignment that a >> document >> (eventually, we hope, an RFC) describing how to use that and why we >> asked for it would be helpful. >> >> The below announcement is that draft. We would like to work with the >> community to improve and clarify teh draft. >> >> Thank you, >> Joel >> >> >> Forwarded Message >> Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt >> Date: Wed, 16 Jun 2021 07:00:04 -0700 >> From: internet-dra...@ietf.org >> Reply-To: internet-dra...@ietf.org >> To: i-d-annou...@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >>Title : Interface Stack Table Definition for Point >> to >> Point (P2P) Interface over LAN >>Authors : Daiying Liu >> Joel Halpern >> Congjie Zhang >>Filename: draft-liu-lsr-p2poverlan-00.txt >>Pages : 7 >>Date: 2021-06-16 >> >> Abstract: >> The point-to-point circuit type is one of the mainly used circuit >> types in li
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Lsr on behalf of Joel M. Halpern Sent: 16 June 2021 21:46 This document (and the code point) are intended to be in line with 5309. I believe they are. If we got it wrong, please help us fix it. A reference would be reasonable to add. (The IANA entry for the code point does reference 5309.) which confused me as RFC5309 has no IANA considerations and no reference to 303. I understand how this is so but think that this I-D could explain this. I think that the I-D is wrong to ask IANA to perform an update - the update has happened. What would help would be for this I-D to explain that the allocation was made by Expert Review and to ask that IANA update the reference to point to this I-D and then this I-D can point back to RFC5309. This is almost an updates to 5309 as it give a value to the specification - I can see the IESG having fun with that concept but I would go for it. I think too that this I-D should reference and build on RFC5309. At present it looks like an Unused Ref. Tom Petch Thank you, Joel On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote: > Hi Joel, > > At first I wondered where this document should reside and then decided that > LSR is probably as good as any other place. > > Can you guys check whether it is mostly in line with > https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should > be referenced? > > Thanks, > Acee > > > On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" > wrote: > > Recently, Ericsson requested and received an IF Type assignment from > IANA (with expert review) for point-to-point over Ethernet links. > > It was noted during the discussion around the assignment that a document > (eventually, we hope, an RFC) describing how to use that and why we > asked for it would be helpful. > > The below announcement is that draft. We would like to work with the > community to improve and clarify teh draft. > > Thank you, > Joel > > > Forwarded Message > Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt > Date: Wed, 16 Jun 2021 07:00:04 -0700 > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Interface Stack Table Definition for Point to > Point (P2P) Interface over LAN > Authors : Daiying Liu > Joel Halpern > Congjie Zhang > Filename: draft-liu-lsr-p2poverlan-00.txt > Pages : 7 > Date: 2021-06-16 > > Abstract: > The point-to-point circuit type is one of the mainly used circuit > types in link state routing protocol. It is important to identify > the correct circuit type when forming adjacencies, flooding link > state database packets, and monitor the link state. This document > defines point-to-point interface type and relevant stack tables to > provide benefit for operation, maintenance and statistics. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
From: Lsr on behalf of gregory.mir...@ztetx.com Sent: 25 May 2021 22:02 Inline under Tom Petch Hi Tony, thank you for clarifying your view on this. Please find my notes in-line below under the GIM>> tag. Regards, Greg Mirsky Sr. Standardization Expert 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division [cid:9ae3e214c17d49ed935d87c674ba3ee2] [cid:24242e5637af428891c4db731e7765ad] E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com> www.zte.com.cn<http://www.zte.com.cn/> Original Mail Sender: TonyLi Date: 2021/05/25 09:52 Hi Greg, Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 nanoseconds or 100 nanoseconds. Ok. The specific precision isn’t particularly relevant to me. The real questions are whether microseconds are the right base or not, and whether we should shift to floating point for additional range or add more bits. To Tony's question, the delay is usually calculated from the timestamps collected at measurement points (MP). Several formats of a timestamp, but most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits represent seconds and 32 bits - a fraction of a second. As you can see, the nanosecond-level resolution is well within the capability of protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of the packet delay metric, I can think of URLLC in the MEC environment. I was told that some applications have an RTT budget of in the tens microseconds range. It’s very true that folks have carried around nanosecond timestamps for a long time now. No question there. My question is whether it is actually useful. While NTP has that precision in its timestamps, the actual precision of NTP’s synchronization algorithms aren’t quite that strong. In effect, many of those low order bits are wasted. GIM>> What I see from deployment of active measurement protocols, e.g., TWAMP and STAMP, is the strong interest in using PTP, i.e. IEEE 1588v2, timestamp format in the data plane. And the requirement (actually, there are different profiles) for the quality of clock synchronization for 5G is, as I understand it, achievable with PTP. I have no information if that is the case with NTP. That’s not a big deal, but when we make the base more precise, we lose range. If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and his inter-planetary Internet. :-) GIM>> Agree. I would propose to consider 100 usec as a unit, which gets close to 7 minutes. We could go with 64 bits of nanoseconds, but then we’ll probably only rarely use the high order bits, so that seems wasteful of bandwidth. Or we can go to floating point. This will greatly increase the range, at the expense of having fewer significant bits in the mantissa. Personally, I would prefer to stay with 32 bits, but I’m flexible after that. GIM>> I think that we can stay with a 32 bit-long field and get better resolution at the same time. A related item. I was looking at draft-ietf-detnet-yang which uses uint32 nanoseconds for latency so that is another where nanoseconds can be found. Tom Petch Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] opsawg-l3sm-l3nm
Looking at this I-D, from OPSAWG, I get somewhat concerned and wonder what those with more knowledge of the LSR protocols than I would think. It caters for routing between PE and CE, RIP, VRRP, BGP, PIM, MLD, IGMP, BFD not to mention the two LSR protocols and so contains the YANG to configure those protocols but in a way that is different to the YANG models for those protocols. Thus it uses address family to mean IPv4 or IPV6 (not the BGP meaning) and often splits the protocol on that basis, not e.g. as OSPFv2 or OSPFv3. There is but a single OSPF identity, imported from a common module which only ever mentions OSPFv2, which means there is no way of specifying in YANG what is part of OSPFv2, what is OSPFv3, only what is OSPF for IPv4 or what is OSPF for IPv6. Other terminology is different. Thus for BGP, symptomatic if not a concern here, it specifies hold-time and keep-alive, where BGP omits the hyphen, and it does not mention BGP Identifier which I would see as the starting point for BGP. Of more interest here, it uses level1, level2 and level1-2 where every other document I know uses level-1 etc including the hyphen. OSPF authentication is rather different to that of ospf-yang with IPsec, key-chain and key-explicit. I would sum up the I-D as 'routing for everyone but different' and wonder what others might think. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Split was Re: Draft minutes for BFD @ IETF110
From: Rtg-bfd on behalf of Reshad Rahman Sent: 19 March 2021 18:58 To: rtg-bfd@ietf. org Subject: Draft minutes for BFD @ IETF110 BFD WG, Draft minutes have been posted @ https://datatracker.ietf.org/doc/minutes-110-bfd/ Please provide comments to the list by April 2nd. I support Acee's suggestion that the TE part should be split from the BFD YANG draft so that the other three WG, who have been held up for years, can progress. Tom Petch Copying the LSR WG. Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0 Regards, Reshad. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When is an IANA Registry Required
From: Lsr on behalf of Tony Li Sent: 17 March 2021 20:56 Les, [Les:] The question here is whether there is a qualitative difference between two classes of bit fields. That is indeed the key question. IMHO, there is not. I don’t much care if a field is updated by a bis document or a related document. Regardless of the cause, as soon as there is more than one source of truth about the field, we are creating ambiguity and confusion. At the same time, I see no point in a registry with contents that never change. Thus, I will propose an alternative: by analogy to copy-on-write shared memory semantics, I propose that we apply ‘registry-on-write’ semantics. Specifics: When a potentially shared field is created, the defining document speciifies the name of a future registry, but does NOT request IANA create the registry at this time. When any document wishes to update the field, it requests that IANA create it and populate it with both legacy and updated values. Implementors that come along either document know where the source of truth is. If the registry has not been created, then there is no ambiguity. If it has been, then there is no ambiguity. Thoughts? I keep seeing YANG modules which reference the RFC that set up the IANA Registry which by then is of course out-of-date as the Normative definition is now in the IANA Registry. I suspect that the authors fail to notice that this is now an IANA registry just reading the body of the RFC. We do hide IANA Considerations out of site in Section 42 or some such tucked away at the end of the document. The other issue is that if you want an example of abysmal choice of an identifier, then the IANA Registry names provide a wealth of examples, along with a comprehensive set of examples of how not to structure information in a hierarchy (assuming, that is, that you want others to be able to find the information). LSR is not bad in this regard, compared to some routing WG, but it could do better. Thus I see Sub-sub-TLV sub-sub-TLVs Sub-TLVs etc For me everyone of these is not as helpful as it could be. What matters? TLV 144, so that comes first; to me, it is a no-brainer but clearly my brain is different. Tom Petch Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03
From: Yingzhen Qu Sent: 21 January 2021 17:28 Hi Tom, We published the new version a while back, so just wondering whether you got a chance to review the changes? Please kindly let us know if you have other comments. Yes, I did see and look at it. I would say that it addresses the points I gave as show-stoppers to adoption. The period for the adoption call has now expired so I was expecting a follow-up from the Chairs. I would leave further changes until the adoption is complete. Tom Petch Thanks, Yingzhen On Jan 5, 2021, at 10:02 AM, Yingzhen Qu mailto:yingzhen...@futurewei.com>> wrote: Hi Tom, Thank you for your review and comments. We’ll publish a new version to address your comments within a couple of days. Thanks, Yingzhen On Jan 5, 2021, at 9:04 AM, tom petch mailto:ie...@btconnect.com>> wrote: From: Christian Hopps Sent: Tuesday, January 05, 2021 16:54 > On Jan 5, 2021, at 11:47 AM, tom petch > mailto:ie...@btconnect.com>> wrote: > > From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of > Christian Hopps mailto:cho...@chopps.org>> > Sent: 05 January 2021 09:19 > > This begins a 2 week WG adoption call for the following draft: > > > https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2F&data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2a746233cc21444a04b608d8b1a4393e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454666271945908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P6mbsiz6uADWt%2FafxPcjh6ADttVUFNycty982MKy3AM%3D&reserved=0> > > Please indicate your support or objection by January 19th, 2021. > > > > Object, strongly. > > In an earlier version, there was one YANG module and the accompanying text > related to that module. > > A second YANG module has been dropped into the I-D while the text is > untouched. Thus > the Abstract is wrong > the Introduction is wrong > IANA Considerations are wrong > and so on. > > This second module lacks references while introducing technical objects such > as udabm-length or r-flag with no indication where in the 68 documents > credited to the LSR WG (plus those of ISO) information may be found to judge > whether or not the YANG is suitable. > > The security considerations is out-of-date, the references do not reflect RFC > published last year, YANG import lack references, the key references are > listed as Informative. > > And, contrary to the announcement, the intended status of the I-D is > Informational. > > I am surprised that anyone should consider this to be in a state fit for > adoption! Adoption just means the WG is willing to take on the work. It does not imply that the work is done or even close to being done. That said thanks for pointing out work that needs to be done prior to considering a WGLC on this document. :) Chris, as you doubtless realise, I am saying that this version is not ready for adoption. Intended status Informational? That to me is a show-stopper (even if you do not consider the misleading Abstract and so on to be - which I do!) Tom Petch Thanks, Chris. > > Tom Petch > > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to this draft. > > Thanks, > Chris. > ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03
From: Christian Hopps Sent: Tuesday, January 05, 2021 16:54 > On Jan 5, 2021, at 11:47 AM, tom petch wrote: > > From: Lsr on behalf of Christian Hopps > > Sent: 05 January 2021 09:19 > > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/ > > Please indicate your support or objection by January 19th, 2021. > > > > Object, strongly. > > In an earlier version, there was one YANG module and the accompanying text > related to that module. > > A second YANG module has been dropped into the I-D while the text is > untouched. Thus > the Abstract is wrong > the Introduction is wrong > IANA Considerations are wrong > and so on. > > This second module lacks references while introducing technical objects such > as udabm-length or r-flag with no indication where in the 68 documents > credited to the LSR WG (plus those of ISO) information may be found to judge > whether or not the YANG is suitable. > > The security considerations is out-of-date, the references do not reflect RFC > published last year, YANG import lack references, the key references are > listed as Informative. > > And, contrary to the announcement, the intended status of the I-D is > Informational. > > I am surprised that anyone should consider this to be in a state fit for > adoption! Adoption just means the WG is willing to take on the work. It does not imply that the work is done or even close to being done. That said thanks for pointing out work that needs to be done prior to considering a WGLC on this document. :) Chris, as you doubtless realise, I am saying that this version is not ready for adoption. Intended status Informational? That to me is a show-stopper (even if you do not consider the misleading Abstract and so on to be - which I do!) Tom Petch Thanks, Chris. > > Tom Petch > > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to this draft. > > Thanks, > Chris. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03
From: Lsr on behalf of Christian Hopps Sent: 05 January 2021 09:19 This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/ Please indicate your support or objection by January 19th, 2021. Object, strongly. In an earlier version, there was one YANG module and the accompanying text related to that module. A second YANG module has been dropped into the I-D while the text is untouched. Thus the Abstract is wrong the Introduction is wrong IANA Considerations are wrong and so on. This second module lacks references while introducing technical objects such as udabm-length or r-flag with no indication where in the 68 documents credited to the LSR WG (plus those of ISO) information may be found to judge whether or not the YANG is suitable. The security considerations is out-of-date, the references do not reflect RFC published last year, YANG import lack references, the key references are listed as Informative. And, contrary to the announcement, the intended status of the I-D is Informational. I am surprised that anyone should consider this to be in a state fit for adoption! Tom Petch Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-yang-isis-reverse-metric-02.txt
From: Lsr on behalf of internet-dra...@ietf.org Sent: 18 December 2020 18:43 I still have an issue with the prefix in -02 The examples use rm: which I find a bit short. The module should be the same but uses isis-rmetric: which I find a bit long. isis-rm: would suit me Tom Petch A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Module for IS-IS Reverse Metric Author : Christian Hopps Filename: draft-ietf-lsr-yang-isis-reverse-metric-02.txt Pages : 15 Date: 2020-12-18 Abstract: This document defines a YANG module for managing the reverse metric extension to the the intermediate system to intermediate system routeing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-lsr-yang-isis-reverse-metric-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-yang-isis-reverse-metric-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-yang-isis-reverse-metric-01
From: Lsr on behalf of Michael Richardson via Datatracker Sent: 07 December 2020 02:49 Reviewer: Michael Richardson Review result: Ready This document is a short YANG module relating to RFC8500, and expertise in that RFC are required to be sure if all the right control bits are required. It has reasonable security consideration, although the words, "The lowest NETCONF layer is the secure transport layer" seems a bit awkward. I would instead write, "All [NETCONF] transactions run over a secure transport layer, which is SSH"... I think that that would be a mistake. The text in question is specified by YANG Guidelines RFC8407 and appears in (almost) all I-D with a YANG Module. The text is the consensus of the NETMOD WG. The Secure Transport layer is a defined part of the Netconf architecture and can be implemented by at least four protocols. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01
From: Acee Lindem (acee)
Sent: 10 December 2020 00:11
Speaking as WG member:
Hi Chris, Tom,
On 12/9/20, 6:03 AM, "Lsr on behalf of tom petch" wrote:
From: Lsr on behalf of Acee Lindem (acee)
Sent: 30 November 2020 18:14
Two thoughts
isis-rmetric is a bit long as a prefix - I note that the examples use rm
which is a bit short. Perhaps isis-rm
I agree.
te-metric contains the value if the sub-tlv is present. What if it is not
present?
I don’t see this described in RFC 8500 (while it is in the OSPF Reverse Metric
draft). This needs to be resolved.
Is there any way to tell if it is present or not?
Just get the config using NETCONF.
I know! it is just an aspect of NETCONF/YANG that I have never liked, fail
danger perhaps. I like objects that have a value that means that this has no
value, such as zero, minus one, maximum and so on but realise that this
protocol is not one of those:-(
Tom Petch
Thanks,
Acee
Tom Petch
As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric
augmentation is ready for publication. This begins a two week last call for the
subject draft. Please indicate your support or objection on this list prior to
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly
welcome.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01
From: Lsr on behalf of Acee Lindem (acee) Sent: 30 November 2020 18:14 Two thoughts isis-rmetric is a bit long as a prefix - I note that the examples use rm which is a bit short. Perhaps isis-rm te-metric contains the value if the sub-tlv is present. What if it is not present? Is there any way to tell if it is present or not? Tom Petch As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric augmentation is ready for publication. This begins a two week last call for the subject draft. Please indicate your support or objection on this list prior to 12:00 AM UTC on December 15th, 2020. Also, review comments are certainly welcome. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IESG approves mpls-base-yang
Who cares? Well it is a MISSREF for bfd-yang which is a MISSREF for ospf-yang inter alia so may be those dusty old I-D will come to life and see if they are still valid or not (some are not:-(. Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt
From: Tony Li on behalf of tony...@tony.li Sent: 15 September 2020 22:17 Our apologies. We’re on it. Thank you, -04 is much easier to digest although perhaps not easy:-( I think that the I-D needs to decide what to do with OpenConfig which appears a lot in one module and makes it hard to read. If this is going to be an IETF module, then I think that it all has to go, perhaps via an appendix while the I-D is under development. The lack of text makes it hard to know what is intended. I reverse engineer the YANG to find out what it is meant to do and lo and behold the YANG does just that. I think that the base OSPF YANG module gets it just right with its mix of text and tree diagram, so I can see what it is trying to do, see at a high level and then go to the detail of the YANG. Several other routing area I-D are similar although by no means all. Also the lack of references, or the minimal descriptions, or both make it hard to follow. so algorithm is uint8, connection type is uint8, what is an ID in number of IDs?, index is uint16, priority is uint8 but what is high what low? and so on. I should not need to know lsr-dynamic-flooding off by heart in order to make sense of this. And - Security Considerations is plain wrong; go read YANG Guidelines:-) - IANA Considerations ditto - is used as a placeholder for two different I-D - ietf-ospf-dynflood would be consistent and less error prone IMHO - RFC6991, RFC8349 need to be Normative references - Introduction should reference OSPFv3 - objects and identities relating to TLV need references - they are ever harder to find in the IETF literature - ospf should be capitalised, LEEF probably not - several abbreviations need expanding on first use perhaps in a terminology section; usually there is one such for YANG terminology - I wonder if ospf-dynamic-flooding would be a better feature name given there are the two of them side-by-side Tom Petch Tony > On Sep 15, 2020, at 9:04 AM, Acee Lindem (acee) > wrote: > > It looks like some unfortunate tab settings at least for the OSPF model... > Note that pyang can be used for formatting. > > pyang -f yang --yang-line-length 68 > > On 9/15/20, 11:47 AM, "Lsr on behalf of tom petch" behalf of ie...@btconnect.com> wrote: > >The formatting of this I-D seems to have gone wrong making it hard to read > and review. The indentation of successive lines of the YANG module is more > than it usually is. This was a problem with -01 that was not present in -02 > but has now returned in -03 > >Tom Petch > >From: I-D-Announce on behalf of > internet-dra...@ietf.org >Sent: 14 September 2020 22:15 >To: i-d-annou...@ietf.org >Subject: I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > >Title : YANG Data Model for Dynamic Flooding >Authors : Srinath Dontula > Tony Li >Filename: draft-dontula-lsr-yang-dynamic-flooding-03.txt >Pages : 26 >Date: 2020-09-14 > >Abstract: > This document defins YANG data models that can be used to configure > and manage Dynamic Flooding for IS-IS and OSPF. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding/ > >There are also htmlized versions available at: >https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-03 > > https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flooding-03 > >A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-dontula-lsr-yang-dynamic-flooding-03 > > >Please note that it may take a couple of minutes from the time of > submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >___ >I-D-Announce mailing list >i-d-annou...@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >___ >Lsr mailing list >Lsr@ietf.org >https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
From: Acee Lindem (acee) Sent: 29 September 2020 22:44 Hi Tom, We can add the references. See ACEE>. Yes please - it will make it easier for me to review On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" wrote: From: Lsr on behalf of internet-dra...@ietf.org Sent: 13 August 2020 05:37 I said before that it was tough to review because of a lack of references in the YANG module and that remains true. You have two Boolean to enable extended LSA on for ospf, one for area. Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it took me some time to find it. RFC8362 defines two parameters ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the model; yes you have a Boolean under area but I think its meaning requires a reading of RFC8362 Appendix B and that is missing and the description is unclear and the name is wrong. Also the RFC has a SHOULD in it which the model does not implement. You reference s.6.2 but I think that wrong, that it is Appendices A and B that describe this. ACEE> What is the SHOULD that isn't implemented? The very last sentence of RFC8362 about the interaction of ExtendedLSASupport and AreaExtendedLSASupport; YANG has 'must' not 'should' and I would be inclined to make this a YANG 'must' but it you think that that is too much, then a comment in the description is needed IMHO On type, you say there are three possible values. Precisely. Can you have the type set to 'ospf' and support ospfv3? If so, your model fails. Or does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of ospf per se? ACEE>"ospf" is the base identity for "ospfv2" and "ospfv3". So, if a container is applicable to both, no when constraint is needed. However, if it is applicable to the one or the other, a "when" constraint. It is common to do this in YANG. This module is applicable only to OSPFv3. Yes, my question is more about the base ospf model about the valid values that can appear in rt:type; is ospf per se a valid value of type or must it be either ospfv2 or ospfv3? The reference statement after the description could do with a title as you have for the revision description My point about link type is that you are augmenting ospf-yang which uses an enum so in places users will be required to use an enum and in others a uint8 which could be confusing ACEE> I don't get this. We don’t augment link-type. Yes, In base ospf.yang link type is YANG type enum but in this it is type unit8 so modelling the same object with two different data types I think might be confusing. Tom Petch Thanks, Acee Tom Petch A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt Pages : 27 Date: 2020-08-12 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt
The formatting of this I-D seems to have gone wrong making it hard to read and review. The indentation of successive lines of the YANG module is more than it usually is. This was a problem with -01 that was not present in -02 but has now returned in -03 Tom Petch From: I-D-Announce on behalf of internet-dra...@ietf.org Sent: 14 September 2020 22:15 To: i-d-annou...@ietf.org Subject: I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Data Model for Dynamic Flooding Authors : Srinath Dontula Tony Li Filename: draft-dontula-lsr-yang-dynamic-flooding-03.txt Pages : 26 Date: 2020-09-14 Abstract: This document defins YANG data models that can be used to configure and manage Dynamic Flooding for IS-IS and OSPF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-03 https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flooding-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-dontula-lsr-yang-dynamic-flooding-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
From: Lsr on behalf of internet-dra...@ietf.org Sent: 13 August 2020 05:37 I said before that it was tough to review because of a lack of references in the YANG module and that remains true. You have two Boolean to enable extended LSA on for ospf, one for area. Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it took me some time to find it. RFC8362 defines two parameters ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the model; yes you have a Boolean under area but I think its meaning requires a reading of RFC8362 Appendix B and that is missing and the description is unclear and the name is wrong. Also the RFC has a SHOULD in it which the model does not implement. You reference s.6.2 but I think that wrong, that it is Appendices A and B that describe this. On type, you say there are three possible values. Precisely. Can you have the type set to 'ospf' and support ospfv3? If so, your model fails. Or does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of ospf per se? The reference statement after the description could do with a title as you have for the revision description My point about link type is that you are augmenting ospf-yang which uses an enum so in places users will be required to use an enum and in others a uint8 which could be confusing Tom Petch A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt Pages : 27 Date: 2020-08-12 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-03.txt
Looking at some more technical aspects of this
/* Configuration */
"This augments the OSPFv3 protocol configuration
with segment routing.";
really?
leaf extended-lsa-support {
leaf extended-lsa-support {
why two? what does it mean if one is true and one false? (why not more
than two?:-)
I wonder too where this boolean is best placed; there seems to me to be
no obvious ospfv3 place for it so
"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:o
spf"
is probably as good as any.
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
is rt:type always set to ospfv3 as opposed to ospf? is there something
in ospf-yang that ensures this?
* Link State Database (LSDB) Augmentations
when "derived-from-or-self(/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type,"
+ "'ospfv3')" {
derived-from seems unnecessary for ospfv3, equality would do
grouping ipv4-link-local-tlv {
container ipv4-link-local-tlv {
description "IPv6 Link-Local LSA TLV";
IPv6 looks odd here
grouping ospfv3-e-lsa-area {
description "Area scope OSPFv3 Extended LSAs.";
container e-router {
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-router-lsa')" {
I see nothing derived from 'ospfv3-e-router-lsa' so I cannot see when
this is true
leaf type {
type uint8;
this is an enumeration in ospf-yang
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-network-lsa')"
likewise I cannot see this being true
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-inter-area-prefix-lsa')"
and again
when "derived-from(../../ospf:header/ospf:type,
'ospfv3-e-inter-area-router-lsa')"
and again
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-intra-area-prefix-lsa')"
I think you know this by now but this one would work but is not needed,
simple equality test would do.
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-as-external-lsa')"
again equality is all that seems to be needed
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-nssa-lsa')"
and again
when "derived-from-or-self(../../ospf:header/ospf:type,
'ospfv3-e-link-lsa')
and again
Tom Petch
- Original Message -
From:
To:
Cc:
Sent: Friday, August 07, 2020 7:03 PM
Subject: I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-03.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
> Title : YANG Model for OSPFv3 Extended LSAs
> Authors : Acee Lindem
> Sharmila Palani
> Yingzhen Qu
> Filename:
draft-ietf-lsr-ospfv3-extended-lsa-yang-03.txt
> Pages : 26
> Date: 2020-08-07
>
> Abstract:
>This document defines a YANG data model augmenting the IETF OSPF
YANG
>model to provide support for OSPFv3 Link State Advertisement (LSA)
>Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide
>extensible TLV-based LSAs for the base LSA types defined in RFC
5340.
>
>
> The IETF datatracker status page for this draft is:
>
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang
/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-03
>
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa
-yang-03
>
> A diff from the previous version is available at:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yan
g-03
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WGLC request for draft-ietf-lsr-ospfv3-extended-lsa-yang
From: Lsr on behalf of Yingzhen Qu Sent: 07 August 2020 22:55 Hi Chairs, On behalf of the authors, I’d like to request WG LC of “YANG Model for OSPFv3 Extended LSAs”: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ This is a tough read. I would like to compare the data structures with those in the RFC defining the LSA but the YANG module is devoid of such references. Adding those references would encourage me to review more. And there are a number of admin issues. Requirements lacks RFC8174 in the body of the I-D I see no upper case words in the YANG module but you include the boilerplate. Tree diagrams no reference means different I-D in different places import lack references security lacks TLS1.3 RFC8242 not in I-D References RFC8174 not in I-D References import OSPF must be Normative Tom Petch This model severs as a foundation for future OSPFv3 extensions using extended LSAs (RFC 8362) and will be augmented by those new features, such as OSPFv3 Extensions for Segment Routing. Please let us know if you need any other info. Thanks, Yingzhen ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04
From: Lsr on behalf of Loa Andersson Sent: 03 June 2020 08:20 Tony, I guess that this shows that we should take care naming our registries. In line please- On 02/06/2020 23:24, tony...@tony.li wrote: > > Hi Loa, > >> The code points are requested from "the IS-IS TLV Codepoints registry", >> howver the "IS-IS TLV Codepoints" is a name space with 14 different >> registries. I think the the registry you want to allocated code point >> from the "TLV Codepoints registry” > > > I apologize for the confusion, you are certainly correct. > > The confusion arises because the page is named “IS-IS TLV Codepoints” > and the registry is the “TLV Codepoints Registry” so to be precise, we > should request an allocation from the “IS-IS TLV Codepoints TLV > Codepoints Registry”. That does seem somewhat awkward and redundant > redundant. > > To reduce confusion in the future, perhaps the entire page should be > renamed to “IS-IS Codepoints”? In the party of the world there I'm active there is a tendency to call "the page" the "name space", that stops us from repeating "registry" to often, so we have name space, registry and sub-registry. This is as I understand it a terminology IANA understands, even if there is no formal acceptance of it. Loa, I try to persuade authors to follow RFC8126 (which I think IANA understands). It recognises the historical confusion with naming and recommends that, going forward, a two tier naming of Group and Registry be used. I see the TLV Codepoints Registry as part of the I S - I S (spaces added to fool the spam detectors) Group. That seems to me to be clear and unambiguous and not prolix. I think that its inclusion in the RFC makes it formally accepted by the IETF:-) Tom Petch Renaming the name space would require us to update a number of IS-IS documents. I would advice against that, but if the wg decides to do it try to help to get correct. For the time being I'd say that we want to allocate the code points from the "TLV Codepoints" reistry in the IS-IS TLV Codepoints" namespace. Doing that way it is also easier to find the correct registry. >/Loa > > Regards, > Tony > -- My mail server from time to time has come under DOS attacks, we are working to fix it but it may take some time. If you get denial of service sending to me plz try to use loa.pi.nu@gmail Loa Anderssonemail: l...@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] draft-hopps-lsr-yang-isis-reverse-metric-02
Christian
Some stray thoughts
/intermediate system routeing/intermediate system routing/
since we have to use the American style:-(
import ietf-routing { prefix "rt"; }
lacks a reference clause and the reference should be in the Normative
References
import ietf-isis { prefix "isis"; }
lacks a reference clause
IS-IS reverse metric functionality [RFC8500].
YANG module must be plain text and this looks like it is not.
Tom Petch
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt
Tony I suggest you have a read of RFC8407, not so much s.4, which is rather detailed, but the other sections. Tom Petch - Original Message - From: To: "tom petch" Cc: Sent: Saturday, September 07, 2019 3:51 AM Hi Tom, Thank you very much for your comments. We will address them in the -02 version of the draft. Tony > On Sep 6, 2019, at 1:40 PM, tom petch wrote: > > I am confused > > You have > > reference "RFC - YANG model for Open Shortest Path First (OSPF). > "RFC : A YANG data model for OSPF Dense topology"; > reference " RFC - Dynamic Flooding on Dense Graphs"; > > whereas is customarily used as a placeholder for the RFC which the > I-D becomes; I see no reference to the name at the start of the I-D, > namely > YANG Data Model for Dynamic Flooding > which must appear in the IANA Considerations, which it does not as they > are absent. > > Also, many lines are too long for an RFC which makes the I-D (too) > difficult to read on a screen. > > Tom Petch > > - Original Message - > From: > To: > Sent: Thursday, September 05, 2019 1:49 AM > Subject: [Lsr] Fwd: New Version Notification for > draft-dontula-lsr-yang-dynamic-flooding-00.txt > > > > Hi all, > > This is the first draft of a YANG model for Dynamic Flooding. > > We welcome your comments. Please be gentle as we are YANG n00bs. > > Regards, > Srinath & Tony > > >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Subject: New Version Notification for > draft-dontula-lsr-yang-dynamic-flooding-00.txt >> Date: September 4, 2019 at 5:47:26 PM PDT >> To: "Srinath Dontula" , "Tony Li" >> >> >> A new version of I-D, draft-dontula-lsr-yang-dynamic-flooding-00.txt >> has been successfully submitted by Tony Li and posted to the >> IETF repository. >> >> Name: draft-dontula-lsr-yang-dynamic-flooding >> Revision: 00 >> Title: YANG Data Model for Dynamic Flooding >> Document date: 2019-09-03 >> Group: Individual Submission >> Pages: 16 >> URL: > https://www.ietf.org/internet-drafts/draft-dontula-lsr-yang-dynamic-floo > ding-00.txt >> Status: > https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding > / >> Htmlized: > https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-00 >> Htmlized: > https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flo > oding >> >> >> Abstract: >> This document defins YANG data models that can be used to configure >> and manage Dynamic Flooding for IS-IS and OSPF. >> >> >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > > > > -- -- > > > >> ___ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Fwd: New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt
I am confused You have reference "RFC - YANG model for Open Shortest Path First (OSPF). "RFC : A YANG data model for OSPF Dense topology"; reference " RFC - Dynamic Flooding on Dense Graphs"; whereas is customarily used as a placeholder for the RFC which the I-D becomes; I see no reference to the name at the start of the I-D, namely YANG Data Model for Dynamic Flooding which must appear in the IANA Considerations, which it does not as they are absent. Also, many lines are too long for an RFC which makes the I-D (too) difficult to read on a screen. Tom Petch - Original Message - From: To: Sent: Thursday, September 05, 2019 1:49 AM Subject: [Lsr] Fwd: New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt Hi all, This is the first draft of a YANG model for Dynamic Flooding. We welcome your comments. Please be gentle as we are YANG n00bs. Regards, Srinath & Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-dontula-lsr-yang-dynamic-flooding-00.txt > Date: September 4, 2019 at 5:47:26 PM PDT > To: "Srinath Dontula" , "Tony Li" > > > A new version of I-D, draft-dontula-lsr-yang-dynamic-flooding-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. > > Name: draft-dontula-lsr-yang-dynamic-flooding > Revision: 00 > Title: YANG Data Model for Dynamic Flooding > Document date: 2019-09-03 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-dontula-lsr-yang-dynamic-floo ding-00.txt > Status: https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding / > Htmlized: https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flo oding > > > Abstract: > This document defins YANG data models that can be used to configure > and manage Dynamic Flooding for IS-IS and OSPF. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (YANG Data Model for OSPF Protocol) to Proposed Standard
I have been looking some more at this I-D and have some more doubts and
queries.
s.2.2
OLD
The area and area/interface containers respectively define the OSPF
configuration and operational state for OSPF areas and interfaces.
NEW
The area and area/interface containers define the OSPF
configuration and operational state for OSPF areas and interfaces
respectively.
The current text suggests area corresponds to configuration and
area/interface to operational state!
OLD
"WG Web: <http://datatracker.ietf.org/group/lsr/>
NEW
"WG Web: <https://datatracker.ietf.org/group/lsr/>
I am puzzled by the use of derived-from...
container router {
when "derived-from-or-self(../../header/type, "
+ "'ospf:ospfv2-router-lsa')" {
why is this derived-from-or-self when I can see nothing derived from the
base type?
container network {
when "derived-from-or-self(../../header/type, "
+ "'ospfv2-network-lsa')" {
ditto
container summary {
when "derived-from(../../header/type, "
+ "'ospfv2-summary-lsa-type')" {
why is this not derived-from-or-self when there are derivations from the
base type?
when "derived-from(../../header/type, "
+ "'ospfv2-external-lsa-type')" {
description
"Only applies to AS-external LSAs and NSSA LSAs.";
Yes, since they are derived-from external-lsa but external-lsa per se
will be excluded which I assume is intended
identity operation-mode { description "OSPF operation mode.";
I cannot see any explanation of where this is used or what it is
router capabilities (RFC7770) appears in the YANG but is not itself a
feature; is there an assumption that all current routers will support
RFC7770?
lsa-id
sometimes dotted-quad, sometimes uint32, sometimes both; why?
grouping ospfv2-lsa {
container header {
must "(derived-from(type, "
description
"Opaque type and ID only apply to Opaque LSAs.";
The must and the description match but why are they part of container
header and not part of the leaves?
Tom Petch
- Original Message -
From: "tom petch"
Sent: Friday, July 05, 2019 5:30 PM
I think that this could do with a few tweaks.
RFC 7884 is in the YANG module but not in the I-D references nor in the
body of the I-D.
The names of the TLV are not quite the same as in IANA and since new TLV
are not regarded as updates to RFC7770, then precision is called for in
order to find them with confidence via IANA
I cannot find router-address-tlv in IANA nor is there a YANG reference
clause and since there was some confusion over router-id in 2018, this
is one I want to check against its RFC, whatever that is.
The RPC can disrupt routing; elsewhere I have seen such actions limited
by a default
nacm:deny all
so users have to be positively configured to invoke the RPC.
I am unclear about rpc clear-neighbor. Yes, it clears the adjacency but
what then? Is it held down, allowed to come back up or what?
rpc or action? I have yet to work out the pros and cons of each but was
rather expecting action as opposed to rpc for these.
leaf cost {type uint16
mostly have a range, but some do not; should they?
typedef ospf-metric { type uint32 { range "0 .. 16777215";
but
leaf cost { type ospf-metric { range "0..16777214";
looks odd; if intended, I suggest adding a note of explanation
some leaf metric are type ospf-metric others are type uint16; again
looks odd (but may be intended)
references to bfd-yang are not consistent
RFC - YANG Data Model for Bidirectional
Forwarding Detection (BFD).
draft-ietf-bfd-yang-xx.txt:
YANG Data Model for Bidirectional Forwarding Detection (BFD)";
I think the former clearer
I notice that many of the YANG enumeration have numeric values, others
do not, which makes me curious; not wrong but since YANG does not put
them on the wire, I think that having no numeric value is commoner
With priority
e.g. list unreserved-bandwidth {
leaf priority {
which is high and which is low?
Likewise with boolean e.g.
leaf best { type boolean; description
"Indicates if the alternate is the preferred.";
does true mean the alternate is preferred?
This I-D is big - 125pp - and I will not finish reviewing it by July
17th but expect to do so some time later in the month - I will post
again when I have.
Tom Petch
- Original Message -
From: "The IESG"
To: "IETF-Announce"
Cc: ; "Stephane Litkowski"
; ;
;
Sent: Tuesday, July 02, 2019 5:55 PM
Subject: [Lsr] Last Call: (YANG Data Model
for OSPF Protocol) to Proposed Standard
>
> The IESG has received a re
Re: [Lsr] IETF 105 LSR Working Group Meeting Minutes
There is an item in the minutes referring to 'YANG update' - which draft is that? Tom Petch - Original Message - From: "Acee Lindem (acee)" To: Sent: Thursday, July 25, 2019 9:27 PM > I think we had some very good discussions in our sessions this week. I ’ve uploaded the minutes for the both LSR sessions on Monday. Thanks much to Yingzhen Qu for taking them. > > https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00 > > Thanks, > Acee ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (YANG Data Model for OSPF Protocol) to Proposed Standard
I think that this could do with a few tweaks.
RFC 7884 is in the YANG module but not in the I-D references nor in the
body of the I-D.
The names of the TLV are not quite the same as in IANA and since new TLV
are not regarded as updates to RFC7770, then precision is called for in
order to find them with confidence via IANA
I cannot find router-address-tlv in IANA nor is there a YANG reference
clause and since there was some confusion over router-id in 2018, this
is one I want to check against its RFC, whatever that is.
The RPC can disrupt routing; elsewhere I have seen such actions limited
by a default
nacm:deny all
so users have to be positively configured to invoke the RPC.
I am unclear about rpc clear-neighbor. Yes, it clears the adjacency but
what then? Is it held down, allowed to come back up or what?
rpc or action? I have yet to work out the pros and cons of each but was
rather expecting action as opposed to rpc for these.
leaf cost {type uint16
mostly have a range, but some do not; should they?
typedef ospf-metric { type uint32 { range "0 .. 16777215";
but
leaf cost { type ospf-metric { range "0..16777214";
looks odd; if intended, I suggest adding a note of explanation
some leaf metric are type ospf-metric others are type uint16; again
looks odd (but may be intended)
references to bfd-yang are not consistent
RFC - YANG Data Model for Bidirectional
Forwarding Detection (BFD).
draft-ietf-bfd-yang-xx.txt:
YANG Data Model for Bidirectional Forwarding Detection (BFD)";
I think the former clearer
I notice that many of the YANG enumeration have numeric values, others
do not, which makes me curious; not wrong but since YANG does not put
them on the wire, I think that having no numeric value is commoner
With priority
e.g. list unreserved-bandwidth {
leaf priority {
which is high and which is low?
Likewise with boolean e.g.
leaf best { type boolean; description
"Indicates if the alternate is the preferred.";
does true mean the alternate is preferred?
This I-D is big - 125pp - and I will not finish reviewing it by July
17th but expect to do so some time later in the month - I will post
again when I have.
Tom Petch
- Original Message -
From: "The IESG"
To: "IETF-Announce"
Cc: ; "Stephane Litkowski"
; ;
;
Sent: Tuesday, July 02, 2019 5:55 PM
Subject: [Lsr] Last Call: (YANG Data Model
for OSPF Protocol) to Proposed Standard
>
> The IESG has received a request from the Link State Routing WG (lsr)
to
> consider the following document: - 'YANG Data Model for OSPF Protocol'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2019-07-17. Exceptionally, comments may
be
> sent to i...@ietf.org instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a YANG data model that can be used to
configure
>and manage OSPF. The model is based on YANG 1.1 as defined in RFC
>7950 and conforms to the Network Management Datastore Architecture
>(NDMA) as described in RFC 8342.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic
Engineering (Experimental - Independent Submission Editor stream)
> rfc1765: OSPF Database Overflow (Experimental - IETF stream)
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg
A somewhat arbitrary choice of message to reply to, in order to say that
other protocols do have layers, e.g. igmp in
draft-ietf-pim-igmp-mld-yang
but they have taken a different approach. They have such as
grouping interface-global-config-attributes {
grouping interface-common-config-attributes {
grouping interface-level-config-attributes {
which, as this shows, are groupings, which are then in parallel, rather
than in a hierarchy. The relationship is specified in text as
" For a
configuration node at the interface level, there may exist a
corresponding configuration node with the same name at the
interface-global level. The value configured on a node at the
interface level overrides the value configured on the corresponding
node at the interface-global level "
Clearly you could have some fairly sophisticated YANG to suppress the
interface-global value when that at the interface-level is configured,
but they don't, they rely on correct implementation! Also, this
structure is not, IMHO, readily apparent in the tree diagram unless you
know what to look for.
Tom Petch
- Original Message -
From: "Martin Bjorklund"
To:
Cc: ; ;
;
Sent: Monday, June 10, 2019 9:04 AM
> Hi,
>
> Qin Wu wrote:
> > I think what they are looking for in RFC7950 is generic overridden
> > rule, i.e., a parent node statement can be overridden by its child
> > node substatement.
>
> See Per's reply to the netmod list. In summary, in this case you
> should do:
>
> container priority {
> leaf value {
> type uint8;
> default 64;
> }
> container level-1 {
> leaf value {
> type uint8;
> description
> "If not configured, use the value of ../../value.";
> }
> }
> container level-2 {
> leaf value {
> type uint8;
> description
> "If not configured, use the value of ../../level-1/value.";
> }
> }
> }
>
>
>
> /martin
>
>
>
>
> >
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen
> > Schoenwaelder
> > 发送时间: 2019年6月9日 23:28
> > 收件人: Xufeng Liu
> > 抄送: lsr@ietf.org; NETMOD WG
> > 主题: Re: [netmod] A question on the parameter overriding in
> > draft-ietf-isis-yang-isis-cfg
> >
> > Hi,
> >
> > YANG does not have 'levels'. This seems to be an ISIS specific
> > question you should ask on the ISIS list.
> >
> > /js
> >
> > On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> > > In Section 2.3. and many other locations, the current IS-IS model
> > > applies the parameter overriding rule as below:
> > >
> > > [Quote]:
> > >
> > > 2.3
> > >
<https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2.
.3>.
> > > Per-Level Parameters
> > >
> > >
> > >Some parameters allow a per level configuration. In this case,
the
> > >parameter is modeled as a container with three configuration
> > >locations:
> > >
> > >o a top-level container: corresponds to level-1-2, so the
> > > configuration applies to both levels.
> > >
> > >o a level-1 container: corresponds to level-1 specific
parameters.
> > >
> > >o a level-2 container: corresponds to level-2 specific
parameters.
> > >
> > >+--rw priority
> > >| +--rw value? uint8
> > >| +--rw level-1
> > >| | +--rw value? uint8
> > >| +--rw level-2
> > >| +--rw value? uint8
> > >
> > >Example:
> > >
> > >
> > >250
> > >
> > >100
> > >
> > >
> > >200
> > >
> > >
> > >
> > >An implementation SHOULD prefer a level specific parameter over
a
> > >level-all parameter. As example, if the priority is 100 for
the
> > >level-1, 200 for the level-2 and 250 for the top-level
configuration,
> > >the implementation should use 100 for the level-1 and 200 for
the
> > >level-2.
> > >
> > > [End of Quote]
> > >
> > >
> > > In the model, all three value leaves above have a default
statement
> > > “default 64”, which brings up my ques
