Skip to main content

RIFT Applicability and Operational Considerations


Jim Guichard

No Objection

Deb Cooley
Roman Danyliw
Zaheduzzaman Sarker

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

Jim Guichard
Deb Cooley
No Objection
Erik Kline
No Objection
Comment (2024-06-09 for -15) Not sent
# Internet AD comments for draft-ietf-rift-applicability-15
CC @ekline

* comment syntax:

* "Handling Ballot Positions":

## Comments

* I'm not a big fan of all this 8505 ND registration stuff, as it really
  doesn't seem applicable to the vast majority of intended RIFT
  implementations, nor is it something with much support or operational
  experience outside IoT networks.  It feels like the topic has been forced
  into the document.

  But it's all informational, so :shrug:.
John Scudder
No Objection
Comment (2024-06-12 for -15) Sent
Thanks for this document. (This time, with intended ballot position!)

One nit, “1:/+1 protection schemes” really? I assume “1:/+1” is some kind of tricky compression of “1:1 or 1+1” but please just write it out.
Murray Kucherawy
No Objection
Comment (2024-06-13 for -15) Sent
The shepherd writeup is 3 1/2 years old.  It still shows Alvaro as the responsible AD.  Are we sure it's still current?
Roman Danyliw
No Objection
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-06-12 for -15) Sent
# Éric Vyncke, INT AD, comments for /draft-ietf-rift-applicability-15

Thank you for the work put into this document. 

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

Special thanks to Jeffrey Zhang for the shepherd's write-up including the WG consensus *but* it lacks the justification of the intended status and uses the old template (the latter point does not really matter though).

I hope that this review helps to improve the document,



# COMMENTS (non-blocking)

## Generic

Some contents appear to overlap a lot with the actual RIFT specification, OTOH this text is easier to read that the actual spec.

Are sections about implementations (section 5.6), advantages of RITF (section 5) really part of "applicability" ?

## Title

s/RIFT Applicability/RIFT Applicability and Operational Considerations/ IMHO, there is a difference between "applicability" and "operational considerations", i.e., the former does not include the latter.

## Section 1

s/identifies topology miscablings/identifies miscablings/ ? As I am unsure whether an abstract concept (topology) can be miscabled.

## Section 2

`These terms should be consistent` suggest being more assertive by s/should be/are/.

## Section 4

I was about to DISCUSS it... please add RFC 5340 (OSPFv3) to the list.

## Section 4.2.1

About ring-based protection (last paragraph), isn't it still useful to handle the case when one horizontal link fails ?

## Section 4.2.2

`RIFT implementations can be extended` and `The RIFT specification itself does not provide the exact details` make me wonder whether this section should be removed.

## Section 4.2.3

This section repeats a lot of explanations about RIFT that were already stated earlier. It also re-expands DAG, which was already done.

What is the 'this' in `This can be achieved with a ring as` ? Suggest to merge the last two bullets to make it clear.

## Section 4.3.2

Is the term "metro fabric" well understood in the IETF community ? 

## Section 4.3.3

Should there be informational references to BGP and PNNI ?

## Section 4.3.4

Suggest explaining what is the purpose of the fabric in `to use fabrics` 

## Section 5

Suggest moving the leading part of this section in to-be-created "RIFT Advantages in Applicable Topologies" section (and anyway unsure whether this content belongs to an applicability I-D).

# NITS (non-blocking / cosmetic)

## Section 4.1

s/gateway to the internet/gateway to the Internet/

## Section 5.14