Skip to main content

OSPF Advertisement of Tunnel Encapsulations
draft-ietf-ospf-encapsulation-cap-09

Revision differences

Document history

Date Rev. By Action
2021-04-20
09 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-03-08
09 (System) RFC Editor state changed to AUTH48
2021-02-16
09 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-01-26
09 (System) RFC Editor state changed to REF from EDIT
2021-01-15
09 (System) RFC Editor state changed to EDIT from MISSREF
2018-03-27
09 Alvaro Retana Notification list changed to Acee Lindem <acee@cisco.com>, aretana.ietf@gmail.com from Acee Lindem <acee@cisco.com>
2018-03-27
09 Alvaro Retana Shepherding AD changed to Alvaro Retana
2017-10-26
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-10-26
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-10-25
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-10-24
09 (System) RFC Editor state changed to MISSREF
2017-10-24
09 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-10-24
09 (System) Announcement was received by RFC Editor
2017-10-24
09 (System) IANA Action state changed to In Progress
2017-10-24
09 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-10-24
09 Cindy Morgan IESG has approved the document
2017-10-24
09 Cindy Morgan Closed "Approve" ballot
2017-10-24
09 Cindy Morgan Ballot approval text was generated
2017-10-24
09 Cindy Morgan Ballot writeup was changed
2017-10-24
09 Alia Atlas IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-10-10
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-10
09 Bruno Decraene New version available: draft-ietf-ospf-encapsulation-cap-09.txt
2017-10-10
09 (System) New version approved
2017-10-10
09 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Robert Raszuk , Luay Jalil , Xiaohu Xu
2017-10-10
09 Bruno Decraene Uploaded new revision
2017-10-02
08 Alia Atlas Waiting on authors for a few more changes.
2017-10-02
08 Alia Atlas IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2017-09-23
08 Benoît Claise [Ballot comment]
Trusting the group, doc. shepherd and responsible AD that the right things will happen.
2017-09-23
08 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2017-09-20
08 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Susan Hares.
2017-09-18
08 Suresh Krishnan [Ballot comment]
Thanks for addressing my DISCUSS and COMMENT points
2017-09-18
08 Suresh Krishnan [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss
2017-09-18
08 Bruno Decraene New version available: draft-ietf-ospf-encapsulation-cap-08.txt
2017-09-18
08 (System) New version approved
2017-09-18
08 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Robert Raszuk , Luay Jalil , Xiaohu Xu
2017-09-18
08 Bruno Decraene Uploaded new revision
2017-09-10
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-09-10
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-09-10
07 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-07.txt
2017-09-10
07 (System) New version approved
2017-09-10
07 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Xiaohu Xu , Robert Raszuk , Luay Jalil
2017-09-10
07 Xiaohu Xu Uploaded new revision
2017-08-31
06 Wesley Eddy Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Joseph Touch.
2017-08-31
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg.
2017-08-31
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead
2017-08-30
06 Suresh Krishnan
[Ballot discuss]
* There seems to be an difference between this document's definition of sub-TLVs (with 2 octet types and lengths) and those of RFC5512 …
[Ballot discuss]
* There seems to be an difference between this document's definition of sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet types and lengths). So I am surprised to see the document point to the RFC5512 based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can you please explain how these sub-TLVs are encoded on the wire to be compatible with this draft?
2017-08-30
06 Suresh Krishnan
[Ballot comment]
* IANA considerations

Looks like the value 65535 is included both as experimental and reserved. Suggest changing

OLD:
65500-65535    Experimental      …
[Ballot comment]
* IANA considerations

Looks like the value 65535 is included both as experimental and reserved. Suggest changing

OLD:
65500-65535    Experimental                              This document

NEW:
65500-65534    Experimental                              This document
2017-08-30
06 Suresh Krishnan [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan
2017-08-30
06 Adam Roach
[Ballot comment]
Section 5 specifies that unknown Sub-TLVs are ignored, but that known-and-invalid Sub-TLVs ruin the whole TLV. It seems a bit odd that a …
[Ballot comment]
Section 5 specifies that unknown Sub-TLVs are ignored, but that known-and-invalid Sub-TLVs ruin the whole TLV. It seems a bit odd that a less capable implementation would be able to act on an announcement of a tunnel, yet a more capable one would not -- and that's the exact consequence of this arrangement. It would seem to make more sense to allow implementations to ignore invalid Sub-TLVs as if they didn't know them.

Section 7.2 allocates the value 65535 twice (once as "Experimental", once as "Reserved").

I believe that this mechanism introduces an attack vector that is not discussed in the Security Considerations section. Specifically: because this allows routers to send OSPF announcements containing arbitrary tunnel termination addresses, it can cause other routers to attempt to connect to arbitrary third parties; and, since (by my admittedly shaky understanding of OSPF), I can distribute this information to a large community of routers with a single message by sending it to an RR, I can easily cause a *lot* of routers to potentially send such traffic. For example, if I were able to inject an announcement that has (a) a tunnel type of 13 ("MPLS in UDP Encapsulation"), (b) an "Endpoint Sub-TLV" of a victim web server that I know runs QUIC, and (c) a "UDP Destination Port" of 443, wouldn't this result in a potential DDoS of that web server?

I don't know what the security model of OSPF is or how difficult it would be to mount this attack (or even how bad it would be compared to other attacks one might mount in OSPF), but it seems that a brief treatment of this -- along with any operational mitigation techniques that might be employed against it -- should be part of the Security Considerations.
2017-08-30
06 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-08-30
06 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-08-30
06 Alvaro Retana
[Ballot comment]
I think there's a normative conflict in these two pieces of text; the first one from Section 3, and the second from Section …
[Ballot comment]
I think there's a normative conflict in these two pieces of text; the first one from Section 3, and the second from Section 5:

  ...If the Encapsulation Capability
  TLV appears more than once in an OSPF Router Information LSA, only
  the first occurrence MUST be processed and others MUST be ignored.

...

  Any unknown Sub-TLVs MUST be ignored and skipped upon receipt.

  If a Sub-TLV is invalid, its Tunnel Encapsulation TLV MUST be ignored
  and skipped.  However, other Tunnel Encapsulation TLVs MUST be
  considered.



The text from Section 3 says that only the first TLV [*] is to be processed -- but during such processing the receiver may find an invalid sub-TLV, which then mandates (in Section 5) for other TLVs to be considered.

I think that the easy solution is to change the second "MUST" from Section 3 for a "SHOULD".


It would be nice to describe what is an "invalid" sub-TLV, and that "invalid" is not the same as "unknown" (right?)...but that an "unknown [tunnel] types are to be ignored and skipped upon receipt", which would result in processing the second (if any) TLV.


[*] Benoit's ballot pointed at the need for consistency in the names.
2017-08-30
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-08-30
06 Benoît Claise
[Ballot discuss]
1. I agree with Tim Wicinski's OPS DIR point about IANA.

    The content appears to be fine, but there are some …
[Ballot discuss]
1. I agree with Tim Wicinski's OPS DIR point about IANA.

    The content appears to be fine, but there are some outdated (the biggest one is
    5226 replaced by 8126), but its the IANA section which appears the most
    confusing.

    7.1 OSPF Router Information (RI) Registry -  appears fine

    7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry

    This one defines the values being defined/allocated from "This Document" but in
    Section 5, each Sub-TLV is defined in other documents, so it's totally
    confusing.

2. It's not clear which of the following sub-TLVs are required/relevant/interconnected in the Encapsulation Capability TLV

            0    Reserved                                  This document
            1    Encapsulation                            This document
            2    Protocol Type                            This document
            3    Endpoint                                  This document
            4    Color                                    This document
            5    Load-Balancing Block                      This document
            6    IP QoS                                    This document
            7    UDP Destination Port                      This document

The only hint is:

      Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
      TLVs as defined in Section 5.

Zero? really, what's the point?
Now, from an operational point of view, which sub-TLVs are required/make sense?
Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation
Could we have multiple identical sub-TLVs? Ex: Color
2017-08-30
06 Benoît Claise
[Ballot comment]
- Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The Tunnel Encapsulation Type Sub-TLV"
I guess that:
OLD:

The Tunnel Encapsulation Type …
[Ballot comment]
- Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The Tunnel Encapsulation Type Sub-TLV"
I guess that:
OLD:

The Tunnel Encapsulation Type Sub-TLV is structured as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


NEW:
The Encapsulation Capability TLV is structured as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In section 7.1, should it be?
OLD:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Tunnel Capabilities                    This document

NEW:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Encapsulation Capabilities            This document

OR:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Tunnel Encapsulation Capabilities      This document


- Then there is a discrepancy between Sub-TLVs and Value in the related text

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation Attribute Sub-TLVs", and the following text updated:

  Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
      TLVs as defined in Section 5.

- Then, reading section 5, I see yet another name: "OSPF Tunnel Encapsulation Attribute Sub-TLVs" Section 7.2.

You should re-read the document to be consistent with your naming convention, in the text and in the IANA sections.
2017-08-30
06 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2017-08-29
06 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2017-08-29
06 Ben Campbell [Ballot comment]
I agree with Mirja's comment concerning the IANA considerations.
2017-08-29
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-08-29
06 (System) IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed
2017-08-29
06 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-08-29
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-08-29
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-08-29
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-08-29
06 Tim Wicinski Request for Last Call review by OPSDIR Partially Completed: Has Issues. Reviewer: Tim Wicinski. Sent review to list.
2017-08-28
06 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-08-28
06 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-08-28
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ospf-encapsulation-cap-06. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ospf-encapsulation-cap-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

Note: We sent the following question to the authors --> We understand that reservations about the requests made in the IANA Considerations section of this draft have been raised in the GENART review. We would like to know how the authors intend to resolve those comments before providing a formal review for IESG Last Call.

The IANA Services Operator understands that, upon approval of this document, the current draft of the document has two actions which we must complete.

First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters/

a single, new TLV will be registered as follows:

Value: [ TBD-at-registration ]
TLV Name: Tunnel Capabilities
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the OSPF Tunnel Encapsulation Attribute Sub-TLVs registry.

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registration rules for the new registry are as follows:

The values in the range 1-255 are to be allocated using the "Standards Action" registration procedure as defined in [RFC8126].

The values in the range 256-65499 are to be allocated using the "First Come, First Served" registration procedure.

There are initial registrations in the new registry as follows:

Value Name Reference
----------- --------------------- -------------
0 Reserved [ RFC-to-be ]
1 Encapsulation [ RFC-to-be ]
2 Protocol Type [ RFC-to-be ]
3 Endpoint [ RFC-to-be ]
4 Color [ RFC-to-be ]
5 Load-Balancing Block [ RFC-to-be ]
6 IP QoS [ RFC-to-be ]
7 UDP Destination Port [ RFC-to-be ]
8-65499 Unassigned
65500-65535 Experimental [ RFC-to-be ]
65535 Reserved [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
2017-08-28
06 Mirja Kühlewind
[Ballot comment]
I agree with the gen-art review (Thanks Pete!) that the new registry should point to the RFCs that define the actually Sub-TLV (behavior). …
[Ballot comment]
I agree with the gen-art review (Thanks Pete!) that the new registry should point to the RFCs that define the actually Sub-TLV (behavior). I would simply recommend to reference both RFCs, this document and the respective other RFC/draft that defines the details.
2017-08-28
06 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-08-28
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2017-08-27
06 Spencer Dawkins [Ballot comment]
It surprised me to learn that this capability wasn't already in OSPF! Thanks for doing the work.
2017-08-27
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-08-27
06 Alia Atlas Ballot has been issued
2017-08-27
06 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2017-08-27
06 Alia Atlas Created "Approve" ballot
2017-08-27
06 Alia Atlas Ballot writeup was changed
2017-08-21
06 Pete Resnick Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Pete Resnick. Sent review to list.
2017-08-17
06 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2017-08-17
06 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2017-08-17
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2017-08-17
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2017-08-15
06 Wesley Eddy Request for Last Call review by TSVART is assigned to Joseph Touch
2017-08-15
06 Wesley Eddy Request for Last Call review by TSVART is assigned to Joseph Touch
2017-08-15
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2017-08-15
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2017-08-14
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-08-14
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2017-08-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-encapsulation-cap@ietf.org, ospf@ietf.org, Acee Lindem , akatlas@gmail.com, …
The following Last Call announcement was sent out (ends 2017-08-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-encapsulation-cap@ietf.org, ospf@ietf.org, Acee Lindem , akatlas@gmail.com, acee@cisco.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Advertising Tunneling Capability in OSPF) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'Advertising Tunneling
Capability in OSPF'
  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
ietf@ietf.org mailing lists by 2017-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Networks use tunnels for a variety of reasons.  A large variety of
  tunnel types are defined and the ingress needs to select a type of
  tunnel which is supported by the egress and itself.  This document
  defines how to advertise egress tunnel capabilities in OSPF Router
  Information Link State Advertisement (LSAs).





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/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:
    draft-ietf-idr-tunnel-encaps: The BGP Tunnel Encapsulation Attribute (None - IETF stream)



2017-08-14
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-08-14
06 Cindy Morgan Last call announcement was generated
2017-08-11
06 Alia Atlas Last call was requested
2017-08-11
06 Alia Atlas Last call announcement was generated
2017-08-11
06 Alia Atlas Ballot approval text was generated
2017-08-11
06 Alia Atlas Ballot writeup was generated
2017-08-11
06 Alia Atlas IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-08-11
06 Alia Atlas Placed on agenda for telechat - 2017-08-31
2017-07-17
06 Bruno Decraene New version available: draft-ietf-ospf-encapsulation-cap-06.txt
2017-07-17
06 (System) New version approved
2017-07-17
06 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Xiaohu Xu , Robert Raszuk , Luay Jalil
2017-07-17
06 Bruno Decraene Uploaded new revision
2017-07-03
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-07-03
05 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-05.txt
2017-07-03
05 (System) New version approved
2017-07-03
05 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Xiaohu Xu , Robert Raszuk , Luay Jalil
2017-07-03
05 Xiaohu Xu Uploaded new revision
2017-06-29
04 Alia Atlas A few minor changes (as per email sent on June 29) are needed.
Then it will need another short WGLC.
2017-06-29
04 Alia Atlas IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2017-06-23
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-06-23
04 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-04.txt
2017-06-23
04 (System) New version approved
2017-06-23
04 (System) Request for posting confirmation emailed to previous authors: Luis Contreras , Bruno Decraene , Xiaohu Xu , Robert Raszuk , Luay Jalil
2017-06-23
04 Xiaohu Xu Uploaded new revision
2017-06-14
03 Alia Atlas
As is customary, I have done my AD review of draft-ietf-ospf-encapsulation-cap-03.
First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis, and …
As is customary, I have done my AD review of draft-ietf-ospf-encapsulation-cap-03.
First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis, and Luay - for their work on this useful document.

I do have a few concerns that need addressing before the draft can progress.

Major:

1) First, the draft talks about what information is sent - but nothing about how it is to be understood or used.  That'd be ok if there were a clear reference to a document that discussed the related procedures.  A quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be the right place to start - but it's procedures are BGP-focused and while there are many similarities, there may be interesting differences as well. 
For instance, for the Color sub-TLV, is the 4 byte color value expected to represent the same meaning in OSPF as in BGP?  Can a BGP route with a particular color extended community then have the OSPF tunnel to use selected from only those tunnels with the same color?  What does the Color TLV mean in a purely OSPF context?  Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains the Color Sub-TLV.  In that case, packet P SHOULD
  NOT be sent through the tunnel identified in that TLV, unless U1 is
  carrying the Color Extended Community that is identified in U2's
  Color Sub-TLV.") doesn't seem to strictly apply.

Semantics and behavior need to be specified - not just the encodings, and that is all this draft currently has.

2) Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation Sub-TLV and Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 - but that draft defines not merely the format, but allocates an IANA registry for additional sub-types that can appear and defines the format and contents of the sub-TLV based upon the tunnel type.  I'm nearly certain that you mean that these sub-tlvs use not merely the same format (does variable length fields based upon the allocated type cause issues for OSPF sub-TLV parsing???) but can contain any values and sub-TLVs defined in the relevant IANA registry. As it is written now, there is no reference to the registry or ability to easily support more tunnel types in the future.

3) It is unfortunate that Geneve, which is the agreed encapsulation for NVO3, is not included in the set of tunnels but VXLAN-GPE, which is not going to be a standard, is.
I know this is duplicating what is in draft-ietf-idr-tunnel-encaps-06 but it emphasizes the need to assume additional Tunnel Types and related Encapsulation Sub-TLVs will be defined.

4) Sec 4: Is there a reason to create a new IGP Tunnel Encapsulation Types registry instead of reusing BGP Tunnel Encapsulation Attribute Tunnel Types (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types)?  The latter is FCFS and the proposed registry is Standards Action.  There are already differences and collisions between the two (i.e. value 15).
What would happen if an Encapsulation Sub-TLV needed to include a Tunnel Type? Which registry would it pull from? Would the value used depend on the protocol it was signaled in?

5) I-D.ietf-idr-tunnel-encaps has to be a normative reference.

6) Given that some of the references are to in progress documents for the tunnel types, is it expected that the values will correspond to future versions or are they nailed to this particular version or something else?


Nits:

a) Sec 1:"Partial deployment of IPv6 in IPv4 networks or IPv6 in IPv4
      networks as described in [RFC5565]"
s/IPv6 in IPv4/IPv4 in IPv6 for one of the two
2017-06-14
03 Alia Atlas IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2017-05-19
03 Amy Vezza Changed consensus to Yes from Unknown
2017-05-19
03 Amy Vezza Intended Status changed to Proposed Standard from None
2017-05-19
03 Acee Lindem
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to OSPF Router Informational
      (RI) to advertise multiple node tunnel capabilities and associated
      tunnel parameters (e.g., endpoint). These tunnel capabilities can
      then be used to determine whether an OSPF router can act as the
      endpoint for a specific tunnel type (i.e., encapsulation).

Working Group Summary:

      There was concern that the document didn't satisfy a real
      requirement and was unnecessary. Much of the debate transpired
      in the IS-IS WG. Subsequently, consensus was reached on the
      attendant use cases. 

Document Quality:

      This document has been a WG document for more than 1 1/2 yeara
      and has been stable other than addressing minor comments.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. The corresponding document has been
      accepted in as a WG document in the IS-IS WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No. Publication has been requested for the RFC 4970 BIS draft.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      This document defines a new OSPF Router Information LSA
      TLV, Tunnel Capabilities TLV, to the OSPF Router Information (RI)
      TLVs Registry. Additionally, two new registeries are created, one
      for IGP tunnel encapsulation types and another for tunnel
      encapsulation attribute Sub-TLVs.

      The IANA actions are clear. However, the created registries should
      be verified for correctness.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      Both the new registries require "Standards Action". Hence, they
      will be reviewed by current WG experts.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2017-05-19
03 Acee Lindem Responsible AD changed to Alia Atlas
2017-05-19
03 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-05-19
03 Acee Lindem IESG state changed to Publication Requested
2017-05-19
03 Acee Lindem IESG process started in state Publication Requested
2017-05-19
03 Acee Lindem Changed document writeup
2017-05-19
03 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-03.txt
2017-05-19
03 (System) New version approved
2017-05-19
03 (System)
Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras …
Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras , ospf-chairs@ietf.org
2017-05-19
03 Xiaohu Xu Uploaded new revision
2017-05-17
02 Acee Lindem Notification list changed to Acee Lindem <acee@cisco.com>
2017-05-17
02 Acee Lindem Document shepherd changed to Acee Lindem
2017-04-24
02 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-02.txt
2017-04-24
02 (System) New version approved
2017-04-24
02 (System)
Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras …
Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras , ospf-chairs@ietf.org
2017-04-24
02 Xiaohu Xu Uploaded new revision
2017-04-16
01 (System) Document has expired
2016-10-13
01 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-01.txt
2016-10-13
01 (System) New version approved
2016-10-13
00 (System)
Request for posting confirmation emailed to previous authors: "Xiaohu Xu" , "Bruno Decraene" , "Luay Jalil" , "Uma Chunduri" , "Robert Raszuk" , ospf-chairs@ietf.org, …
Request for posting confirmation emailed to previous authors: "Xiaohu Xu" , "Bruno Decraene" , "Luay Jalil" , "Uma Chunduri" , "Robert Raszuk" , ospf-chairs@ietf.org, "Luis Contreras"
2016-10-13
00 Xiaohu Xu Uploaded new revision
2015-11-09
00 Acee Lindem This document now replaces draft-xu-ospf-encapsulation-cap instead of None
2015-10-14
00 Xiaohu Xu New version available: draft-ietf-ospf-encapsulation-cap-00.txt