Skip to main content

OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
draft-ietf-ospf-xaf-te-07

Revision differences

Document history

Date Rev. By Action
2019-11-24
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-11-14
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-10-01
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-08-29
07 (System) IANA Action state changed to No IANA Actions from In Progress
2019-08-27
07 (System) RFC Editor state changed to EDIT
2019-08-27
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-08-27
07 (System) Announcement was received by RFC Editor
2019-08-27
07 (System) IANA Action state changed to In Progress
2019-08-27
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-08-27
07 Amy Vezza IESG has approved the document
2019-08-27
07 Amy Vezza Closed "Approve" ballot
2019-08-27
07 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-08-27
07 Martin Vigoureux Ballot approval text was generated
2019-08-27
07 Roman Danyliw [Ballot comment]
Thank you for addressing my Discuss item.
2019-08-27
07 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2019-08-21
07 Kathleen Moriarty Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kathleen Moriarty. Sent review to list.
2019-08-16
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-16
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-08-16
07 Alvaro Retana New version available: draft-ietf-ospf-xaf-te-07.txt
2019-08-16
07 (System) New version approved
2019-08-16
07 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Michael Barnes , Alvaro Retana , lsr-chairs@ietf.org
2019-08-16
07 Alvaro Retana Uploaded new revision
2019-08-08
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-08-08
06 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-08-07
06 Benjamin Kaduk [Ballot comment]
Section 4

Do the two steps listed have to happen in a particular order in order to
avoid breakage?
2019-08-07
06 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-08-07
06 Roman Danyliw
[Ballot discuss]
An easy item to address.  Per Section 5,  “Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to …
[Ballot discuss]
An easy item to address.  Per Section 5,  “Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops”, the impact could also include providing access to an attacker.  Perhaps:

OLD:
Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops.

NEW:
Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing; traffic loops; or expose the traffic to attacker inspection or modification.
2019-08-07
06 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2019-08-07
06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-08-07
06 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-08-07
06 Warren Kumari
[Ballot comment]
"NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is …
[Ballot comment]
"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.
2019-08-07
06 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-08-05
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-08-05
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-08-05
06 Alvaro Retana [Ballot comment]
I am a co-author.
2019-08-05
06 Alvaro Retana [Ballot Position Update] New position, Recuse, has been recorded for Alvaro Retana
2019-08-05
06 Éric Vyncke
[Ballot comment]
Alvara, Anton, Michael,

Thank you for the work done for this document.

Just curious about section 3: OSPFv2 routers send their IPv6 address(es) …
[Ballot comment]
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
2019-08-05
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-07-30
06 Mirja Kühlewind
[Ballot comment]
Sec 1: "This document updates [RFC5786] so that a router can also announce
  one or more local X-AF addresses using …
[Ballot comment]
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...
2019-07-30
06 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-07-22
06 Tim Chown Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list.
2019-07-15
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Tim Chown
2019-07-15
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Tim Chown
2019-07-12
06 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2019-07-12
06 Cindy Morgan Placed on agenda for telechat - 2019-08-08
2019-07-12
06 Martin Vigoureux Ballot has been issued
2019-07-12
06 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2019-07-12
06 Martin Vigoureux Created "Approve" ballot
2019-07-12
06 Martin Vigoureux Ballot writeup was changed
2019-07-11
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-07-11
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ospf-xaf-te-06, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ospf-xaf-te-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-07-11
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-07-09
06 Ben Niven-Jenkins Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ben Niven-Jenkins. Sent review to list.
2019-06-30
06 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2019-06-28
06 Min Ye Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins
2019-06-28
06 Min Ye Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins
2019-06-28
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2019-06-28
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2019-06-28
06 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-06-28
06 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-06-27
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-06-27
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-07-11):

From: The IESG
To: IETF-Announce
CC: martin.vigoureux@nokia.com, lsr-chairs@ietf.org, Acee Lindem , lsr@ietf.org, …
The following Last Call announcement was sent out (ends 2019-07-11):

From: The IESG
To: IETF-Announce
CC: martin.vigoureux@nokia.com, lsr-chairs@ietf.org, Acee Lindem , lsr@ietf.org, draft-ietf-ospf-xaf-te@ietf.org, acee@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF Routing with Cross-Address Family Traffic Engineering Tunnels) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPF Routing with Cross-Address Family
Traffic Engineering Tunnels'
  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 2019-07-11. 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


  When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
  network, the Multiprotocol Label Switching (MPLS) TE Label Switched
  Paths (LSP) infrastructure may be duplicated, even if the destination
  IPv4 and IPv6 addresses belong to the same remote router.  In order
  to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must
  be computed over MPLS TE tunnels created using information propagated
  in another OSPF instance.  This issue is solved by advertising cross-
  address family (X-AF) OSPF TE information.

  This document describes an update to RFC5786 that allows for the easy
  identification of a router's local X-AF IP addresses.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-06-27
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-06-27
06 Martin Vigoureux Requested Last Call review by RTGDIR
2019-06-27
06 Martin Vigoureux Last call was requested
2019-06-27
06 Martin Vigoureux Ballot approval text was generated
2019-06-27
06 Martin Vigoureux Ballot writeup was generated
2019-06-27
06 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-06-27
06 Martin Vigoureux Last call announcement was generated
2019-06-26
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-06-26
06 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-06.txt
2019-06-26
06 (System) New version approved
2019-06-26
06 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , lsr-chairs@ietf.org, Alvaro Retana , Michael Barnes
2019-06-26
06 Anton Smirnov Uploaded new revision
2019-06-20
05 Martin Vigoureux IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-06-18
05 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2019-03-22
05 Alvaro Retana Shepherding AD changed to Martin Vigoureux
2019-03-21
05 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 Traffic Engineering
      to include allow tunnel endpoints for both IPv4 and IPv6 to be
      advertised in the OSPF traffic engineering LSAs for either OSPFv2
      or OSPFv3. In cases where the topologies are congruent, this allows
      TE information to be only advertised in one of the two.

      Non-normative text also describes how this information is used
      across address families in the TE tunnel computation.

Working Group Summary:

      There has been some confusion on how this is used and the draft
      has gone through iterations to separate the normative advertisement
      from the TE tunnel computation itself. This has now been clarified
      and there are no objections to the draft.

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications, as well as, separation of the advertisement from
      the TE tunnel computation.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director. However, he is also
      a co-author and may need to recuse himself.

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

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

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

      It updates RFC 5786. This will be added to the Abstract.

(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).
 
      The document has no IANA actions.

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

      None.

(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.
2019-03-21
05 Acee Lindem Responsible AD changed to Alvaro Retana
2019-03-21
05 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from WG Document
2019-03-21
05 Acee Lindem IESG state changed to Publication Requested from I-D Exists
2019-03-21
05 Acee Lindem IESG process started in state Publication Requested
2019-03-21
05 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 Traffic Engineering
      to include allow tunnel endpoints for both IPv4 and IPv6 to be
      advertised in the OSPF traffic engineering LSAs for either OSPFv2
      or OSPFv3. In cases where the topologies are congruent, this allows
      TE information to be only advertised in one of the two.

      Non-normative text also describes how this information is used
      across address families in the TE tunnel computation.

Working Group Summary:

      There has been some confusion on how this is used and the draft
      has gone through iterations to separate the normative advertisement
      from the TE tunnel computation itself. This has now been clarified
      and there are no objections to the draft.

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications, as well as, separation of the advertisement from
      the TE tunnel computation.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director. However, he is also
      a co-author and may need to recuse himself.

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

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

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

      It updates RFC 5786. This will be added to the Abstract.

(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).
 
      The document has no IANA actions.

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

      None.

(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.
2018-12-10
05 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-05.txt
2018-12-10
05 (System) New version approved
2018-12-10
05 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Michael Barnes , Alvaro Retana
2018-12-10
05 Anton Smirnov Uploaded new revision
2018-10-22
04 Alvaro Retana New version available: draft-ietf-ospf-xaf-te-04.txt
2018-10-22
04 (System) New version approved
2018-10-22
04 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Michael Barnes , Alvaro Retana
2018-10-22
04 Alvaro Retana Uploaded new revision
2018-10-12
03 Acee Lindem Notification list changed to Acee Lindem <acee@cisco.com>
2018-10-12
03 Acee Lindem Document shepherd changed to Acee Lindem
2018-10-12
03 Acee Lindem Changed consensus to Yes from Unknown
2018-10-12
03 Acee Lindem Intended Status changed to Proposed Standard from None
2018-10-03
03 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-03.txt
2018-10-03
03 (System) New version approved
2018-10-03
03 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Michael Barnes , Alvaro Retana
2018-10-03
03 Anton Smirnov Uploaded new revision
2018-05-03
02 Ben Niven-Jenkins Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ben Niven-Jenkins. Sent review to list.
2018-04-26
02 Min Ye Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins
2018-04-26
02 Min Ye Request for Last Call review by RTGDIR is assigned to Ben Niven-Jenkins
2018-04-20
02 Min Ye Request for Last Call review by RTGDIR is assigned to Thomas Morin
2018-04-20
02 Min Ye Request for Last Call review by RTGDIR is assigned to Thomas Morin
2018-04-19
02 Acee Lindem Requested Last Call review by RTGDIR
2018-04-19
02 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-02.txt
2018-04-19
02 (System) New version approved
2018-04-19
02 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Alvaro Retana , lsr-chairs@ietf.org, Michael Barnes
2018-04-19
02 Anton Smirnov Uploaded new revision
2018-04-19
01 (System) Document has expired
2018-02-28
01 Cindy Morgan Notification list changed to none
2018-02-28
01 Cindy Morgan Changed group to Link State Routing (LSR) from Open Shortest Path First IGP (OSPF)
2017-10-16
01 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-01.txt
2017-10-16
01 (System) New version approved
2017-10-16
01 (System) Request for posting confirmation emailed to previous authors: Anton Smirnov , Alvaro Retana , Michael Barnes
2017-10-16
01 Anton Smirnov Uploaded new revision
2017-07-30
00 (System) Document has expired
2017-01-26
00 Acee Lindem This document now replaces draft-smirnov-ospf-xaf-te instead of None
2017-01-26
00 Anton Smirnov New version available: draft-ietf-ospf-xaf-te-00.txt
2017-01-26
00 (System) WG -00 approved
2017-01-26
00 Anton Smirnov Set submitter to "Anton Smirnov ", replaces to draft-smirnov-ospf-xaf-te and sent approval email to group chairs: ospf-chairs@ietf.org
2017-01-26
00 Anton Smirnov Uploaded new revision