Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Thanks Yingzhen. Yes I am good with that.
Regards,Reshad.
On Monday, January 22, 2024, 02:39:17 PM EST, Yingzhen Qu
wrote:
Hi Reshad,
Thanks for the review.
The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with more
content, so I thought it might be easier to read with a container. But you're
right, it's not following the YANG traditions, how about the following?
container sid-binding-tlvs { list sid-binding-tlv { key
"prefix"; uses sid-binding-tlv; description "Sid/label
binding TLV, type 149."; } description "List of sid/label
binding TLVs."; } container mt-sid-binding-tlvs { list
mt-sid-binding-tlv { key "prefix mt-id"; uses sid-binding-tlv;
leaf mt-id { type uint16; description "A
12-bit field containing the non-zero ID of the topology."; }
description "Multi-Topology SID/Label binding TLV, type 150.";
reference "RFC 8667 - IS-IS Extensions for Segment Routing,
Section 2.5"; } description "List of multi-topology
sid/label binding TLVs."; }
Thanks,Yingzhen
On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman wrote:
Hi,
Typically we have a container (plural) including a list (singular). In -20 it
was done the other way round. Since this is read-only, IIRC we don't need the
container including a list as we do for read-write. Is the container there for
convenience?
Regards,Reshad.
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp:
+--ro sid-binding-tlvs* []
| +--ro sid-binding-tlv
| +--ro prefix?inet:ip-prefix
| +--ro range? uint16
| +--ro sid-binding-flags
| | +--ro flags* identityref
| +--ro prefix-sid-sub-tlvs* []
| | +--ro prefix-sid-sub-tlvs
| | +--ro prefix-sid-sub-tlv* [sid]
| |+--ro prefix-sid-flags
| || +--ro flags* identityref
| |+--ro algorithm? identityref
| |+--ro sid uint32
| +--ro sid-sub-tlvs* []
| | +--ro sid-sub-tlv
| | +--ro length? uint8
| | +--ro sid? uint32
| +--ro unknown-tlvs
|+--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value?yang:hex-string
+--ro mt-sid-binding-tlvs* []
+--ro mt-sid-binding-tlvs
+--ro prefix?inet:ip-prefix
+--ro range? uint16
+--ro sid-binding-flags
| +--ro flags* identityref
+--ro prefix-sid-sub-tlvs* []
| +--ro prefix-sid-sub-tlvs
| +--ro prefix-sid-sub-tlv* [sid]
|+--ro prefix-sid-flags
|| +--ro flags* identityref
|+--ro algorithm? identityref
|+--ro sid uint32
+--ro sid-sub-tlvs* []
| +--ro sid-sub-tlv
| +--ro length? uint8
| +--ro sid? uint32
+--ro unknown-tlvs
| +--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value?yang:hex-string
+--ro mt-id? uint16On Saturday, January 20, 2024,
06:53:52 PM EST, Reshad Rahman wrote:
[Yingzhen]: Thanks for catching this. I've updated the description. I
looked at the changes in -20. That grouping is now gone and the
(mt-)sid-binding-tlvs lists have no key, is that the intent?Also container
mt-sid-binding-tlvs should be renamed to mt-sid-binding-tlv.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Hi, Typically we have a container (plural) including a list (singular). In -20 it was done the other way round. Since this is read-only, IIRC we don't need the container including a list as we do for read-write. Is the container there for convenience? Regards,Reshad. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/isis:isis/isis:database /isis:levels/isis:lsp: +--ro sid-binding-tlvs* [] | +--ro sid-binding-tlv | +--ro prefix?inet:ip-prefix | +--ro range? uint16 | +--ro sid-binding-flags | | +--ro flags* identityref | +--ro prefix-sid-sub-tlvs* [] | | +--ro prefix-sid-sub-tlvs | | +--ro prefix-sid-sub-tlv* [sid] | |+--ro prefix-sid-flags | || +--ro flags* identityref | |+--ro algorithm? identityref | |+--ro sid uint32 | +--ro sid-sub-tlvs* [] | | +--ro sid-sub-tlv | | +--ro length? uint8 | | +--ro sid? uint32 | +--ro unknown-tlvs |+--ro unknown-tlv* [] | +--ro type? uint16 | +--ro length? uint16 | +--ro value?yang:hex-string +--ro mt-sid-binding-tlvs* [] +--ro mt-sid-binding-tlvs +--ro prefix?inet:ip-prefix +--ro range? uint16 +--ro sid-binding-flags | +--ro flags* identityref +--ro prefix-sid-sub-tlvs* [] | +--ro prefix-sid-sub-tlvs | +--ro prefix-sid-sub-tlv* [sid] |+--ro prefix-sid-flags || +--ro flags* identityref |+--ro algorithm? identityref |+--ro sid uint32 +--ro sid-sub-tlvs* [] | +--ro sid-sub-tlv | +--ro length? uint8 | +--ro sid? uint32 +--ro unknown-tlvs | +--ro unknown-tlv* [] | +--ro type? uint16 | +--ro length? uint16 | +--ro value?yang:hex-string +--ro mt-id? uint16On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman wrote: [Yingzhen]: Thanks for catching this. I've updated the description. I looked at the changes in -20. That grouping is now gone and the (mt-)sid-binding-tlvs lists have no key, is that the intent?Also container mt-sid-binding-tlvs should be renamed to mt-sid-binding-tlv. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Hi Yingzhen,
Please see inline.
On Thursday, January 18, 2024, 04:49:28 PM EST, Yingzhen Qu
wrote:
HI Reshad,
Thanks for the review. I've uploaded version -20 to address your comments.
Details below inline.
Thanks,Yingzhen
On Sat, Jan 13, 2024 at 4:24 PM Reshad Rahman via Datatracker
wrote:
Reviewer: Reshad Rahman
Review result: Ready with Issues
Hi all,
This is my YANG Doctor review of -19. Thanks to the authors for making the
effort to align with draft-ietf-ospf-yang (as previously requested).
Comments
Section 3 (YANG Tree)
- There are a few instances of perfix-sid-flags, should bd prefix-sid-flags
[Yingzhen]: fixed.
- For the list below, can there be overlaps between different entries? If not,
this should be documented (ideally should have been documented in RFC9020)
+--rw protocol-srgb {sr-mpls:protocol-srgb}?
+--rw srgb* [lower-bound upper-bound]
+--rw lower-bound uint32
+--rw upper-bound uint32
[Yingzhen]: There should not be overlaps. Agreed with you, this should have
been documented in RFC 9020.
YANG Model
- The identities such as r-bit, n-bit etc should all have a reference (not just
the document but also the section)
[Yingzhen]: I added reference to each base identity.
- All those identities are called x-bit but the description says flag. Which
terminology is typically used in IS-IS?
[Yingzhen]: changed to -flag.
- Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
sure if we need to know)?
[Yingzhen]: Same as ospf-sr-mpls.yang, added length, and updated sid
description.
- For global-blocks and local-blocks, a reference would help.
[Yingzhen]: Done.
- In grouping sid-sub-tlv, is the container sid-sub-tlv needed?
[Yingzhen]: A container would help to identify the boundary of a TLV. In an
ISIS LSP, there are multiple TLVs and sub-tlvs.
- In grouping srlb , can there be an overlap of the advertised local blocks?
Need some enhanced description here iMO. Same question for sr-capability and
global blocks.
[Yingzhen]: please see the above answers.
- In list global-block, why not add a key? I’m assuming the sid would be
unique? Same comment for local-block.
[Yingzhen]: SRGB is defined in RFC 9020, which is common for both OSPF and
ISIS. Here, we're defining protocol specific SRGB, and the key is defined in
the grouping in the ietf-segment-routing-common.yang. SRLB is defined in RFC
9020, which applies to all protocols.
- In grouping srms-preference, leaf preference, no need for the range 0..255
since it is a uint8.
[Yingzhen]: fixed.
- Nit: a few instances of “This group …”, it should be “This grouping …”
[Yingzhen]: fixed.
- Leaf ‘af’, nit/suggestion: I would rename to address-family.
[Yingzhen] : Done.
- In grouping segment-routing-binding-tlv, leaf range, is that description
accurate?
[Yingzhen]: Thanks for catching this. I've updated the description. I
looked at the changes in -20. That grouping is now gone and the
(mt-)sid-binding-tlvs lists have no key, is that the intent?Also container
mt-sid-binding-tlvs should be renamed to mt-sid-binding-tlv.
- Augment with neighbor-system-id, should the leaf node be mandatory?
[Yingzhen]: added "mandatory true". Also did the same for ospf.
- Container selection-tie-breakers, can both protection types be enabled
simultaneously?
[Yingzhen]: yes, it's possible to enable both of them, one or none.
There should be an appendix with a fairly complete config example and also an
operational state example.
[Yingzhen]: Operational state is not easy to do with the IGP database since we
don't have an implementation yet. I agree that it's not easy but
that's the case for most YANG documents at IETF. I've found yanglint to be a
very useful tool for this. Up to the WG to decide.
Regards,Reshad.
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] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
Hi Acee, On Wednesday, January 17, 2024, 12:42:48 PM EST, Acee Lindem wrote: Hi Reshad, Thanks for the follow-up review. > On Jan 13, 2024, at 15:30, Reshad Rahman via Datatracker > wrote: > > Reviewer: Reshad Rahman > Review result: Ready with Issues > > Hi all, > > This is my YANG Doctor review of -28, I had previously reviewed -20. Thanks to > the authors for addressing my previous comments. There is 1 comment in my > initial review which concerns RFC9020, I am not convinced yet and may send > another email (or errata). > > Comments > > > Should the title explicitly call out OSPFv2 and OSPFv3? The reason I’m asking > is because OSPF may imply v2 only, e.g. RFC8665 says “OSPF Extensions for > Segment Routing” but then the abstract says OSPFv2. While we haven’t been consistent, the base model (RFC 9129) uses simply OSPF to refer to both OSPFv2 and OSPFv3. Ok. > > Section 2. “OSPF base model[RFC9129]”, nit: add a space before the reference Sure. > > In the following, can there be overlaps? If not, this should be documented > (ideally should have been documented in RFC9020) > > +--rw srgb > | +--rw srgb* [lower-bound upper-bound] > | +--rw lower-bound uint32 > | +--rw upper-bound uint32 No overlaps but we this is a RFC 9020 issue. Ok. This is probably obvious to SR experts, but not to others. > > Section 2.1 (the YANG module) > > - In grouping ospfv2-prefix-sid-sub-tlvs, leaf-list flags should have a > reference? Same for v3. I have a reference at the grouping level. It doesn’t change for the flags. I’m hesitant to repeat it. Ok. > > - The grouping ospfv2-extended-prefix-range-tlvs has an ‘af’ address family > leaf which is a uint8, why not use address-family from RFC8294 with the > appropriate restrictions. But since this is OSPFv2 specific, is address family > still needed? For v3, I believe the af leaf is needed, although I’d rename it > to address-family and would use address-family enum from RFC8294. I’ll use the enum from RFC 8294. It shouldn’t be omitted for OSPFv2 since it is included in the ecodings. Ok. > > - The grouping ospfv2-extended-prefix-range-tlvs: should there be a range for > prefix-length? Same question, but but different range needed, for OSPFv3. No - this is not supported. I was never a big fan of the range functionality in the IGPs. Ok. > > - In list local-block-tlv, description of leaf range-size has “…The return of > a > zero value”. Nit: change to “A value of zero…” Sure. > > - In container srms-preference-tlv, leaf preference. Nit: “with with 255”. Fixed. > > - Should leaf neighbor-id be mandatory? If not, what happens when it’s not > set, > does it need a default value? I believe the description needs to indicate what > happens when it is set or not set. If you specify an unknown neighbor-id including invalid ID, it won’t be used. Specification is optional. Typo in latest: neighorr > > - In ti-lfa container: the enable flag is not mandatory and does not have a > default value, you should add a default value or make it mandatory. Other > choice is a presence container. Ok - I defaulted it to false like the other LFA features in ietf-ospf.yang. I also changed it to “enabled” Consistent with ietf-ospf.yang. Ok. > > - In the selection-tie-breakers container, can both tie-breakers be enabled > simultaneously? Yes. I’ve updated the description to indicate this but am not going to attempt to describe the TI-LFA selection algorithm in the description. Ok. > > - For leaf use-segment-routing-path, the description has “…is in effect only > when remote-lfa is enabled”. I did not see any remote-lfa leaf node, not sure > if this is referring to a feature. I think the description needs to be > modified > and a reference would be very helpful here. The reference would be the base mode container which this is augmenting. I don’t know that adding a reference makes sense unless you’re going to add a reference to every augmentation. I missed the fact that it was referring to the parent container it's containing. This leaf node is conditional on remote-lfa-sr feature, it is a child of remote-lfa so I don't understand the point of the comment "…is in effect only when remote-lfa is enabled”, it actually threw me off. > > Appendix A. There is only 1 (simple) example and it covers v2 only. Please add > a v3 example also, ideally with more config data than the current example e.g. > with the neighbor-id (since that augment is in this document). Having an > operational state example for OSPFv2 and OSPFv3 would also really be helpful. > I > realize examples can be painful... We’ll take this under advisement but it won’t b
Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
Hi Acee, Sounds good! Regards,Reshad. On Tuesday, January 16, 2024, 12:45:40 PM EST, Acee Lindem wrote: Hi Reshad, On Jan 16, 2024, at 11:41, Reshad Rahman wrote: Hi, Apologies if this has been discussed before but I didn't follow this document. - Should interface-id and neighbor-interface-id be of type if:if-index instead of uint32? I took a look at RFC8362, still not clear to me. It could very well be the if-index but it doesn’t have to me. It is whatever the neighbor choses to use to uniquely identify its interfaces. Excerpted from RFC 5340, Appendix A.3.2: Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]). - Should leaf metric be of type ospf-metric or ospf-leaf-metric instead of uint16? The 24 bit metrics should be ospf:ospf-metric. The 16-bit metric should be ospf:ospf-link-metric. I’ll update these in the next revision. Thanks,Acee Regards,Reshad. On Thursday, January 11, 2024, 09:36:03 AM EST, The IESG wrote: 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. 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 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
Hi, Apologies if this has been discussed before but I didn't follow this document. - Should interface-id and neighbor-interface-id be of type if:if-index instead of uint32? I took a look at RFC8362, still not clear to me.- Should leaf metric be of type ospf-metric or ospf-leaf-metric instead of uint16? Regards,Reshad. On Thursday, January 11, 2024, 09:36:03 AM EST, The IESG wrote: 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. 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] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Reviewer: Reshad Rahman
Review result: Ready with Issues
Hi all,
This is my YANG Doctor review of -19. Thanks to the authors for making the
effort to align with draft-ietf-ospf-yang (as previously requested).
Comments
Section 3 (YANG Tree)
- There are a few instances of perfix-sid-flags, should bd prefix-sid-flags
- For the list below, can there be overlaps between different entries? If not,
this should be documented (ideally should have been documented in RFC9020)
+--rw protocol-srgb {sr-mpls:protocol-srgb}?
+--rw srgb* [lower-bound upper-bound]
+--rw lower-bounduint32
+--rw upper-bounduint32
YANG Model
- The identities such as r-bit, n-bit etc should all have a reference (not just
the document but also the section)
- All those identities are called x-bit but the description says flag. Which
terminology is typically used in IS-IS?
- Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
sure if we need to know)?
- For global-blocks and local-blocks, a reference would help.
- In grouping sid-sub-tlv, is the container sid-sub-tlv needed?
- In grouping srlb , can there be an overlap of the advertised local blocks?
Need some enhanced description here iMO. Same question for sr-capability and
global blocks.
- In list global-block, why not add a key? I’m assuming the sid would be
unique? Same comment for local-block.
- In grouping srms-preference, leaf preference, no need for the range 0..255
since it is a uint8.
- Nit: a few instances of “This group …”, it should be “This grouping …”
- Leaf ‘af’, nit/suggestion: I would rename to address-family.
- In grouping segment-routing-binding-tlv, leaf range, is that description
accurate?
- Augment with neighbor-system-id, should the leaf node be mandatory?
- Container selection-tie-breakers, can both protection types be enabled
simultaneously?
There should be an appendix with a fairly complete config example and also an
operational state example.
Regards,
Reshad.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
Reviewer: Reshad Rahman Review result: Ready with Issues Hi all, This is my YANG Doctor review of -28, I had previously reviewed -20. Thanks to the authors for addressing my previous comments. There is 1 comment in my initial review which concerns RFC9020, I am not convinced yet and may send another email (or errata). Comments Should the title explicitly call out OSPFv2 and OSPFv3? The reason I’m asking is because OSPF may imply v2 only, e.g. RFC8665 says “OSPF Extensions for Segment Routing” but then the abstract says OSPFv2. Section 2. “OSPF base model[RFC9129]”, nit: add a space before the reference In the following, can there be overlaps? If not, this should be documented (ideally should have been documented in RFC9020) +--rw srgb | +--rw srgb* [lower-bound upper-bound] | +--rw lower-bounduint32 | +--rw upper-bounduint32 Section 2.1 (the YANG module) - In grouping ospfv2-prefix-sid-sub-tlvs, leaf-list flags should have a reference? Same for v3. - The grouping ospfv2-extended-prefix-range-tlvs has an ‘af’ address family leaf which is a uint8, why not use address-family from RFC8294 with the appropriate restrictions. But since this is OSPFv2 specific, is address family still needed? For v3, I believe the af leaf is needed, although I’d rename it to address-family and would use address-family enum from RFC8294. - The grouping ospfv2-extended-prefix-range-tlvs: should there be a range for prefix-length? Same question, but but different range needed, for OSPFv3. - In list local-block-tlv, description of leaf range-size has “…The return of a zero value”. Nit: change to “A value of zero…” - In container srms-preference-tlv, leaf preference. Nit: “with with 255”. - Should leaf neighbor-id be mandatory? If not, what happens when it’s not set, does it need a default value? I believe the description needs to indicate what happens when it is set or not set. - In ti-lfa container: the enable flag is not mandatory and does not have a default value, you should add a default value or make it mandatory. Other choice is a presence container. - In the selection-tie-breakers container, can both tie-breakers be enabled simultaneously? - For leaf use-segment-routing-path, the description has “…is in effect only when remote-lfa is enabled”. I did not see any remote-lfa leaf node, not sure if this is referring to a feature. I think the description needs to be modified and a reference would be very helpful here. Appendix A. There is only 1 (simple) example and it covers v2 only. Please add a v3 example also, ideally with more config data than the current example e.g. with the neighbor-id (since that augment is in this document). Having an operational state example for OSPFv2 and OSPFv3 would also really be helpful. I realize examples can be painful... Regards, Reshad. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)
I support adoption of this document by the WG. Regards,Reshad. On Friday, November 17, 2023, 12:24:12 PM EST, Yingzhen Qu wrote: Hi, This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) Please send your support or objection to the list before December 9th, 2023. An extra week is allowed for the US Thanksgiving holiday. Thanks,Yingzhen ___ 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] [yang-doctors] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang
Hi Acee, Understood. I do realize that there can be good reasons for differences between the 2 documents. Regards,Reshad. On Tuesday, November 14, 2023, 01:22:23 PM EST, Acee Lindem wrote: Hi Reshad, Note that the SR encodings contain a lot of the same information but are different in the two protocols. It wouldn’t be feasible to use common groupings as it is more importation to be consistent with the data blocks that we are augmenting than the SR extensions in the other protocol. If the IGPs were exactly the same, there would only be one On Nov 14, 2023, at 12:17, Reshad Rahman wrote: 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) The LSDB models for RFC 9129 (OSPF) and RFC 9130 (IS-IS) are somewhat different. It is more important to be consistent with the base models than the other protocol. - No global blocks in ISIS IS-IS has global blocks. 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 - No capabilities in OSPF We have augmentations for capabilities. Refer to https://datatracker.ietf.org/doc/html/rfc8665#name-segment-routing-capabilities Thanks, Acee 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: > > Hi, > > 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 > 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-algorithm* identityref > +--ro sid-range-tlvs > | +--ro sid-range-tlv* [] > | +--ro range-size? rt-types:uint24 > | +--ro sid-sub-tlv > | +--ro sid? uint32 > +--ro local-block-tlvs > | +--ro local-block-tlv* [] > | +--ro range-size? rt-types:uint24 > | +--ro sid-sub-tlv > | +--ro sid? uint32 > +--ro srms-preference-tlv > +--ro preference? uint8 > > > > Disclaimer: I don't follow LSR... > > Regards, > Reshad. > ___ > yang-doctors mailing list > yang-doct...@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors ___ 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
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: > > Hi, > > 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 > 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-algorithm* identityref > +--ro sid-range-tlvs > | +--ro sid-range-tlv* [] > | +--ro range-size? rt-types:uint24 > | +--ro sid-sub-tlv > | +--ro sid? uint32 > +--ro local-block-tlvs > | +--ro local-block-tlv* [] > | +--ro range-size? rt-types:uint24 > | +--ro sid-sub-tlv > | +--ro sid? uint32 > +--ro srms-preference-tlv > +--ro preference? uint8 > > > > Disclaimer: I don't follow LSR... > > Regards, > Reshad. > ___ > yang-doctors mailing list > yang-doct...@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang
Hi, 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 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-algorithm* identityref +--ro sid-range-tlvs | +--ro sid-range-tlv* [] | +--ro range-size?rt-types:uint24 | +--ro sid-sub-tlv |+--ro sid? uint32 +--ro local-block-tlvs | +--ro local-block-tlv* [] | +--ro range-size?rt-types:uint24 | +--ro sid-sub-tlv |+--ro sid? uint32 +--ro srms-preference-tlv +--ro preference? uint8 Disclaimer: I don't follow LSR... Regards,Reshad. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] draft-ietf-isis-sr-yang and draft-ietf-ospf-sr-yang
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 justifie:- 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-algorithm* identityref +--ro sid-range-tlvs | +--ro sid-range-tlv* [] | +--ro range-size?rt-types:uint24 | +--ro sid-sub-tlv |+--ro sid? uint32 +--ro local-block-tlvs | +--ro local-block-tlv* [] | +--ro range-size?rt-types:uint24 | +--ro sid-sub-tlv |+--ro sid? uint32 +--ro srms-preference-tlv +--ro preference? uint8 Disclaimer: I don't follow LSR... Regards,Reshad.___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [yang-doctors] Yangdoctors early review of draft-ietf-ospf-sr-yang-20
Hi Acee, All good with me. Regards,Reshad. On Friday, April 14, 2023, 01:13:28 PM EDT, Acee Lindem wrote: Hi Reshad, Thanks for the review. You raised some very good points and especially the point about the OSPFv3 MPLS encoding being missing. We may delay the document until these are added. However, we will address your comments in the next revision of the document. On Apr 3, 2023, at 23:18, Reshad Rahman wrote: Line-breaks (hopefully) fixed below. On Monday, April 3, 2023, 11:08:26 PM EDT, Reshad Rahman via Datatracker wrote: Reviewer: Reshad Rahman Review result: Ready with Issues Main comments = - Please add lots of references in the YANG. There are many (most/all?) nodes e.g. m-bit, protocol-srgb etc etc, and probably types, which need references to the relevant sections in corresponding RFCs. We’ll add these. - The document needs a least 1,probably more, examples. Yes. - The abstract mentions OSPF, the overview mentionsOSPFv2 only and the YANG module has OSPFv2 and OSPFv3. The authors will need to discuss this - it is only complete for OSPFv2 due to the OSPFv3 dependence on the extended LSA YANG model (https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/) which didn’t exist when this document was first written. We may want to add and delay publication. - sr-algorithm should be a leafref to an algorithm somewhere, right now it's a uint8. I changed this to sr-cmn:prefix-sr-algorithm. - No need to redefine uint24, it's already define in RFC8294. Fixed. - Leaf preference, no need for range 0..255 since it's a uint8 Fixed. - Looking at RFC9020, I see that containersegment-routing, in grouping sr-control-plane, is non-presence and leaf receive has default value true, meaning receive is true by default even if the container hasn’t been created. Is that the intention? And is it the desired behaviour in OSPF? If no, you can add a refine statement. My guess though is that is a mistake in RFC9020. This leaf would be ignored if “enabled" is false (which is the default) in the same grouping. If “enabled” is “true”, then it would be applicable. Questions = - extended-prefix-range-tlvs is used only for ospfv2. Is that on purpose. Since there's an "af" node in the grouping, I assumed it'd be used for ospfv3 also. BTW 'af' is defined as uint8, there's an address-family type in RFC6991 and that should be used instead. See discussion above on OSPFv3. - Is uint16 sufficient for range-size? Yes. See section 3.2 or RFC 8665. - I see augment ospf:ospfv2 when rt:type = ospfv2, is the when-stmt needed? The ospfv2container should only exist for ospfv2? Yes - the encoding is completely different for OSPFv3. - Leaf sid is a uint32. In SR models, is the Sid always represented as a uint32 or is there a type defined. Andshould it be a choice for 20-bit label v/s 32-bit SID. It is not always a label - see section 5 of RFC 8665. - List lan-adj-sid-sub-tlv in container lan-adj-sid-sub-tlvs, no need for a key? It is not read-only and there can be one for each neighbor on the LAN. I believe we need a key. Thanks,Acee Regards, Reshad. ___ yang-doctors mailing list yang-doct...@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors ___ 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] [yang-doctors] Yangdoctors early review of draft-ietf-ospf-sr-yang-20
Line-breaks (hopefully) fixed below. On Monday, April 3, 2023, 11:08:26 PM EDT, Reshad Rahman via Datatracker wrote: Reviewer: Reshad Rahman Review result: Ready with Issues Main comments = - Please add lots of references in the YANG. There are many (most/all?) nodes e.g. m-bit, protocol-srgb etc etc, and probably types, which need references to the relevant sections in corresponding RFCs. - The document needs a least 1,probably more, examples. - The abstract mentions OSPF, the overview mentionsOSPFv2 only and the YANG module has OSPFv2 and OSPFv3. - sr-algorithm should be a leafref to an algorithm somewhere, right now it's a uint8. - No need to redefine uint24, it's already define in RFC8294. - Leaf preference, no need for range 0..255 since it's a uint8 - Looking at RFC9020, I see that containersegment-routing, in grouping sr-control-plane, is non-presence and leaf receive has default value true, meaning receive is true by default even if the container hasn’t been created. Is that the intention? And is it the desired behaviour in OSPF? If no, you can add a refine statement. My guess though is that is a mistake in RFC9020. Questions = - extended-prefix-range-tlvs is used only for ospfv2. Is that on purpose. Since there's an "af" node in the grouping, I assumed it'd be used for ospfv3 also. BTW 'af' is defined as uint8, there's an address-family type in RFC6991 and that should be used instead. - Is uint16 sufficient for range-size? - I see augment ospf:ospfv2 when rt:type = ospfv2, is the when-stmt needed? The ospfv2container should only exist for ospfv2? - Leaf sid is a uint32. In SR models, is the Sid always represented as a uint32 or is there a type defined. Andshould it be a choice for 20-bit label v/s 32-bit SID. - List lan-adj-sid-sub-tlv in container lan-adj-sid-sub-tlvs, no need for a key? Regards, Reshad. ___ yang-doctors mailing list yang-doct...@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Yangdoctors early review of draft-ietf-ospf-sr-yang-20
Reviewer: Reshad Rahman Review result: Ready with Issues Main comments = - Please add lots of references in the YANG. There are many (most/all?) nodes e.g. m-bit, protocol-srgb etc etc, and probably types, which need references to the relevant sections in corresponding RFCs. - The document needs a least 1, probably more, examples. - The abstract mentions OSPF, the overview mentions OSPFv2 only and the YANG module has OSPFv2 and OSPFv3. - sr-algorithm should be a leafref to an algorithm somewhere, right now it's a uint8. - No need to redefine uint24, it's already define in RFC8294. - Leaf preference, no need for range 0..255 since it's a uint8 - Looking at RFC9020, I see that container segment-routing, in grouping sr-control-plane, is non-presence and leaf receive has default value true, meaning receive is true by default even if the container hasn’t been created. Is that the intention? And is it the desired behaviour in OSPF? If no, you can add a refine statement. My guess though is that is a mistake in RFC9020. Questions = - extended-prefix-range-tlvs is used only for ospfv2. Is that on purpose. Since there's an "af" node in the grouping, I assumed it'd be used for ospfv3 also. BTW 'af' is defined as uint8, there's an address-family type in RFC6991 and that should be used instead. - Is uint16 sufficient for range-size? - I see augment ospf:ospfv2 when rt:type = ospfv2, is the when-stmt needed? The ospfv2 container should only exist for ospfv2? - Leaf sid is a uint32. In SR models, is the Sid always represented as a uint32 or is there a type defined. And should it be a choice for 20-bit label v/s 32-bit SID. - List lan-adj-sid-sub-tlv in container lan-adj-sid-sub-tlvs, no need for a key? Regards, Reshad. ___ 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
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" wrote: > On Apr 5, 2022, at 09:48, Acee Lindem (acee) 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. 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" 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) 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" wrote: >> >> 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
Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110
Adding John (AD). On Tuesday, July 27, 2021, 10:45:07 a.m. EDT, tom petch wrote: 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
