Skip to main content

Advertising Layer 2 Bundle Member Link Attributes in OSPF
draft-ietf-lsr-ospf-l2bundles-10

Yes

John Scudder

No Objection

Erik Kline
Paul Wouters
Zaheduzzaman Sarker
(Martin Duke)

Note: This ballot was opened for revision 06 and is now closed.

John Scudder
Yes
Éric Vyncke
Yes
Comment (2022-10-04 for -06) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-l2bundles-06
CC @evyncke

Thank you for the work put into this document: it is short, clear, and will be useful.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. A follow up on the Ericsson IPR would be welcome though if there is any update.

As a side note, yet another definition for the overloaded "SID" ;-)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### IEEE802.1AX as informative ?

The only occurence of IEEE802.1AX appears to me as informative: ` for instance a Link Aggregation Group (LAG) [IEEE802.1AX]`
=> suggest to change the reference type to informative rather than normative.

### Section 2

```
   ... Therefore advertisements of member links MUST NOT
   be done when the member link becomes operationally down or it is no
   longer a member of the identified L2 bundle.
```

OTOH, if the information is for an external party (e.g., a controler), having information of an operationally-down link could be useful. Are the authors sure that this would never be used ?

### Section 2, length field

`Length: Variable.` while it is probably obvious, it would probably not hurt to specify the units and what is included.

### Section 2, extensibility

Should there be some text on how to decide applicable/non-applicable for any new link attribute TLV that could be added in the coming years ?

## 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. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
Erik Kline
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2022-10-04 for -06) Sent
Thank you to Russ Mundy for the SECDIR review.

I support Lars Eggert DISCUSS position.  It would be clearer if the the Y/N status indicated by Figure 2 were document via an additional column in the https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-tlv-sub-tlvs registry.  Same observation for Y/N/X in Figure 3 and https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs.
Zaheduzzaman Sarker
No Objection
Alvaro Retana Former IESG member
Yes
Yes (2022-10-05 for -07) Sent
When the L2 Bundle Member Attributes TLV for BGP-LS was specified in rfc9085, the OSPF functionality (in this document) was not defined.

It would be great if this document formally Updated rfc9085 to indicate that the information for the L2 Bundle Member Attributes TLV can also be derived from the L2 Bundle Member Attributes sub-TLV.
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2022-10-05 for -07) Sent for earlier
# GEN AD review of draft-ietf-lsr-ospf-l2bundles-06

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IqLhVi63YKAt6GINPOKUQ0sGt3g).

## 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.

### Typos

#### Section 2, paragraph 3
```
-    assymetric for an OSPF link depending on the underlying layer 2
-      -
+    asymmetric for an OSPF link depending on the underlying layer 2
+       +
```

### Grammar/style

#### Section 2, paragraph 2
```
member link is operationally up. Therefore advertisements of member links MU
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2, paragraph 19
```
which the OSPF protocol operates. Therefore the security considerations of th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## 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
Martin Duke Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2022-10-04 for -06) Sent
Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like the fact that the LAG member information that is being propagated isn't of any relevance to OSPF routing itself, and OSPF is being used only as a generic information propagation mechanism.  However, I acknowledge that horse has probably bolted long ago.

One point that is not clear to me, is the configuration/management of this feature:  Is the expectation that OSPF implementations that support this RFC would automatically propagate bundle member information? Or would this be disabled by default and need to be enabled through configuration?   If there is configuration associated with this feature then would it be part of a updated version of the standard OSPF YANG model, or is it via YANG module augmentation to the base OSPF YANG module?  If this is configurable then having an informational reference to how/where this OSPF feature can be configured would likely be helpful.

Regards,
Rob