Skip to main content

OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
RFC 8687

Yes

(Martin Vigoureux)

No Objection

(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Ignas Bagdonas)
(Suresh Krishnan)

Recuse


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

Roman Danyliw (was Discuss) No Objection

Comment (2019-08-27)
Thank you for addressing my Discuss item.

Warren Kumari No Objection

Comment (2019-08-07 for -06)
"NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term.

I ran out of cycles, and so am relying on the OpsDir review; thanks Tim.

Éric Vyncke No Objection

Comment (2019-08-05 for -06)
Alvara, Anton, Michael,

Thank you for the work done for this document.

Just curious about section 3: OSPFv2 routers send their IPv6 address(es) and OSPFv3 routers send their IPv4 address(es). But, what happens when OSPFv3 routers are multi-topology ? Should they also send their IPv6 address(es)? Of course, in this case, the issue fixed by your memo does not exist ;-) Probably worth mentioning anyway that OSPFv3 multi-topology does not need this feature.

Regards,

-éric

Alvaro Retana Recuse

Comment (2019-08-05 for -06)
I am a co-author.

(Martin Vigoureux; former steering group member) Yes

Yes (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -06)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2019-08-07 for -06)
Section 4

Do the two steps listed have to happen in a particular order in order to
avoid breakage?

(Deborah Brungard; former steering group member) No Objection

No Objection (for -06)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -06)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-07-30 for -06)
Sec 1: "This document updates [RFC5786] so that a router can also announce
   one or more local X-AF addresses using the corresponding Local
   Address sub-TLV.  Routers using the Node Attribute TLV [RFC5786] can
   include non-TE enabled interface addresses in their OSPF TE
   advertisements, and also use the same sub-TLVs to carry X-AF
   information, facilitating the mapping described above."
I wonder if this text should use normative language (s/can/MAY/) as this is the part that actually updates RFC5786, however, I didn't check the exact wording in RFC5786...

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -06)