OSPF Topology-Transparent Zone
draft-ietf-ospf-ttz-06

Request for posting confirmation emailed to previous authors: "Huaimo Chen" , "Yi Yang" , "Mehmet Toy" , "Renwei Li" , "Vic liu" , ospf-chairs@ietf.org, "Alvaro Retana"

[Ballot comment]

- section 13: I don't agree that there are no new
security considerations, and in fact you seem to raise
one so I'd suggest dropping the "nothing to see here"
pseudo-boilerplate;-)

- section 13: If a router inside a TTZ is borked, then
mechanisms that detect borked routers won't work as
well from outside the TTZ I guess (e.g. they might
identify the wrong router as the borked one). And
contrary-wise, hiding topology may help in that it may
make it harder for an attacker to find a desirable
target. Did anyone think about this? (This is not a
discuss only because I'm not familiar enough with ospf
but I bet a beer that hiding topology will create more
new security issues that are not described here;-)

- 8.1: Did I miss where "Z flag" was described?

- nit: six authors again, plus 2 contributors plus 4
"other authors." I really don't get why it's not
possible to reduce to 5 in cases like this.

[Ballot discuss]
Thank you for working on this important spec.

I would like to recommend its approval, but before that I had a request for a clarification, inspired by Orit Levin's Gen-ART review.

In Section 5.1, what specifically is the requirement regarding OSPF TTZ/TTZID uniqueness. It just says "unique within a network". For instance, if I have TTZID 17 under Area 0 and Area 223 among the same set of routers implementing multiple Areas simultaneously, is that allowed? Or are different Areas automatically different networks?

Can you specify an algorithm or rule, or make the current wording more precise?

[Ballot comment]
I had some high-level context that took a while to build, but after I got through the following comments, I found the document clear to read for a non-OSPF guy. Thank you for that.

The Introduction gives a fairly clear idea of what a TTZ is useful for, but the Abstract doesn't say anything about that. If we still think that people read Abstracts separately from RFCs, it would be useful to add a one-sentence summary naming the use cases that you've already identified for the Introduction.

Perhaps something like "Topology Transparent Zones" allow network operators to restructure the areas in their network, and provide services while the reorganization is taking place, with fewer disruptions." But you folks would know best.

I'm curious why

  A TTZ ID is a 32-bit number that is unique for identifying a TTZ.
  The TTZ ID SHOULD NOT be 0.

is not a MUST. Could you give an example of why that would be a good idea?

I found

  A TTZ hides the internal topology of the TTZ from the outside.  It
  does not directly advertise any internal information about the TTZ to
  a router outside of the TTZ.

very helpful, but it doesn't appear until the top of page 7. Perhaps it would be useful to put this into the Introduction (and, maybe even the Abstract). I had been wondering whether that was true from the beginning of the document, so it seems useful to say so much earlier.

[Ballot comment]
Questions on IANA section (not an OSPF expert, so please excuse me if I misunderstood something):
- Don't you have to register both LS types 9 and 10 somehow?
- And do the "Types for new TLVs in the new TTZ LSA" create a new registry or is this an existing one?

Other minor comments:
- What's a DR? Please spell this out!
- There is only little normative language used in this doc. Potentially some more normative language could make things clearer. However I don't have concrete proposals what to change and I believe the most important parts are in normative language. So there is no urgent need to change anything but maybe another check would be good to make sure normative language is used where needed.

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

The IANA Services Operator has completed its review of draft-ietf-ospf-ttz-05.txt. 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.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Opaque Link-State Advertisements (LSA) Option Types subregistry of the Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types registry located at:

https://www.iana.org/assignments/ospf-opaque-types/

a single new value is to be registered as follows:

Value: [ TBD-at-registration ]
Opaque Type: TTZ LSA
Reference: [ RFC-to-be ]

Second, the current draft makes the following request:

IANA is requested to assign Types for new TLVs in the new TTZ LSA as follows:

Type Name Allowed in
1 TTZ ID TLV TTZ LSA of LS Type 10 and 9
2 TTZ Router TLV TTZ LSA of LS Type 10
3 TTZ Options TLV TTZ LSA of LS Type 10 and 9

IANA Question --> Are these types to be the initial entries in a new registry, or are they to be added to an existing one? If they are to be added to an existing one, please specify the name and location of the registry. If the are to be the initial entries for a new registry please consult RFC 5226 for information on how to specify and create a new registry.

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
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-ospf-ttz@ietf.org, akatlas@gmail.com, ospf@ietf.org, "padma.ietf@gmail.com" , padma.ietf@gmail.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENSION OF Last Call:  (OSPF Topology-Transparent Zone) to Experimental RFC


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Topology-Transparent Zone'
  as Experimental RFC

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-01-03. 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


  This document presents a topology-transparent zone in an OSPF area.
  A topology-transparent zone comprises a group of routers and a number
  of links connecting these routers.  Any router outside of the zone is
  not aware of the zone.  The information about the links and routers
  such as a link down inside the zone is not advertised to any router
  outside of the zone.




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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1721/
  https://datatracker.ietf.org/ipr/2701/

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-ospf-ttz@ietf.org, akatlas@gmail.com, ospf@ietf.org, "padma.ietf@gmail.com" , padma.ietf@gmail.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF Topology-Transparent Zone) to Experimental RFC


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Topology-Transparent Zone'
  as Experimental RFC

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 2016-12-30. 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


  This document presents a topology-transparent zone in an OSPF area.
  A topology-transparent zone comprises a group of routers and a number
  of links connecting these routers.  Any router outside of the zone is
  not aware of the zone.  The information about the links and routers
  such as a link down inside the zone is not advertised to any router
  outside of the zone.




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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1721/
  https://datatracker.ietf.org/ipr/2701/

Request for posting confirmation emailed to previous authors: "Huaimo Chen" , "Yi Yang" , "Renwei Li" , " vic" , "Mehmet Toy" , ospf-chairs@ietf.org, "Alvaro Retana"

1) Please clarify somewhere in the introduction that this is for OSPFv2.

2) In Sec 6.1:  Replace the TTZ-LSA-Type (9) with TTZ-LSA-Type (TBD).  It's unfortunate that an early allocation wasn't done, but if you want to suggest a value for the allocation, that should be in the IANA considerations section.
Remove the sentence "Where TTZ-LSA-Type is 9, the exact number is to be assigned by IANA."

3) In Sec 6.2:  Please specify what the TLV-Length is.  Please specify what a TTZ ID is in the text; what are valid values?  What are the concerns for allocation?  What is the uniqueness?  I assume that it is an arbitrary non-zero value that is specified by configuration on a TTZ Router & needs to be unique in the OSPF network.  Can a TTZ router have only one TTZ ID?

"It sets flag Z to 1 after it has  migrated to TTZ."  Please clarify - how long is flag Z set?  When is flag Z cleared?  I see some details in Sec 6.4 - please at least add a forward reference as well as indicating when flag Z is cleared.

4) Sec 6.3:  The reference for Link Type for IANA is [RFC 4940].  Please clarify that while the Link Type field is 8 bits, the values 128-255 are reserved, which allows this reuse of the bottom 7 bits.

5) Sec 6.4:  "When another TTZ router receives the LSA
  with OP for T, it originates its TTZ LSA as described below.

  Migrating to TTZ (M): After a user configures a TTZ router to migrate
  to TTZ, migrating to TTZ is triggered."

The first sentence contradicts the second.  I think the first is saying that when a TTZ router receives a new TTZ Router LSA from its neighbor, the receiving TTZ router starts migrating - but the second sentence states that the migration only happens on configuration.  Please clarify the actual behavior.

"For a TTZ internal router, it also updates its TTZ indication LSA
  with Z = 1.  For a TTZ edge router, it updates its TTZ router LSA
  with Z = 1 and its router LSA for virtualizing the TTZ."
I assume that a TTZ router determines whether it is internal or external based
upon how its links are configured instead of any learned data?  Please explicitly
state how this is done.

" When  another TTZ router receives the LSA with OP for N, it advertises its
  normal LSAs and stops advertising its TTZ LSAs."
Does that TTZ router also originate new TTZ Control LSA so the change spreads?
Please clarify whether "stops advertising its TTZ LSAs" includes the TTZ Control LSA
that it just originated?  I assume not - but a literal reading of the text doesn't tell.

"  Rolling back from TTZ (R): After a user configures a TTZ router to
  roll back from TTZ, rolling back from TTZ is triggered.  The TTZ
  router originates a TTZ Control LSA having a TTZ Options TLV with OP
  for R and rolls back from TTZ.  When another TTZ router receives the
  LSA with OP for R, it also rolls back from TTZ."

What if the TTZ router (call it X) that receives the LSA with OP=R hasn't already gotten
an LSA with OP=N  so X isn't advertizing its normal LSAs nor has it stopped advertising its
other TTZ LSAs?

6) Sec 7.1:  "also by adding the stub links for the loopback addresses in the TTZ to
      be accessed outside of the TTZ."
How does a TTZ Edge Router determine set of loopback addresses in the TTZ to be advertised?
I don't see a clear way for a TTZ Internal Router to indicate that.

7) Sec 8.1 "  If two ends of the link have different TTZ IDs or only one end is
  configured with TTZ ID, no TTZ adjacency over the link will be
  "formed"." 
  Can a TTZ router have multiple TTZ IDs?  Are the TTZ IDs per router?  Is it possible to migrate from one TTZ ID to
  another TTZ ID without migrating away from TTZ, configuring all the future-TTZ routers,
  and then migrating back to TTZ?  Please clarify such as "A router MUST use at most one TTZ ID.
  If multiple  LSA D-LSAs are received from a neighbor with different TTZ IDs, then no TTZ adjacency
  will be formed even if one of the TTZ IDs match" or perhaps a TTZ adjacency is formed??  Maybe the
  lowest TTZ ID is used.  The real point is to be extremely clear on the mandatory behavior.

" D-LSA is not received for sometime such as 60 minutes or is
      flushed."  There needs to be a specific MUST description - for instance.
  "If the D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or is explicitly flushed, then the TTZ adjacency MUST be
  removed.  The D-LSA-MAX-RETRANSMIT-TIME SHOULD be set to 60 minutes, but MAY be configurable."

8) Sec 9.1:  The advertisement rules make sense, but it would be more helpful to indicate HOW the TTZ Edge Router determines that an LSA is about a TTZ internal resource.  For instance, before advertising a Router LSA to a non-TTZ neighbor, the TTZ Edge Router should determine that it does not have a matching TTZ Router LSA.  As far as I can tell, a TTZ Internal Router advertises both a Router LSA and a TTZ Router LSA - where the Router LSA is suppressed by the TTZ Edge Routers??  By being clear on how a TTZ Edge Router can make the decision, you avoid questions on race conditions during migration and different misinterpretations.

9) Sec 10:  This section implies that a TTZ Edge Router originates a TTZ Router LSA that contains both TTZ-external and TTZ-internal links - and that TTZ Router LSA is different from the Router LSA that is generated.  In Sec 7, "For a TTZ edge router, its normal Router LSA content is copied into a TTZ Router TLV with the modifications described in section 6, and a TTZ router LSA containing this TLV is constructed and advertised."  but Section 7.1 describes how the TTZ Edge Router changes its normal Router LSA.  I think you need to clarify in both Sec 7 and Sec 7.1 exactly what is in the TTZ Edge Router's TTZ Router LSA.  I can conclude that it has to be the Router LSA for the TTZ Edge Router as if no TTZ were configured - but that isn't said that the contradiction between Sec 6 & Sec 7.1 can cause confusion.

"This can be achieved by adding a flag into every link stored in LSDB and
  setting this flag to 1 in every link in these router LSAs, which
  indicates that the link is unusable.  It computes routes using the
  TTZ topology (i.e., using LSAs for representing the TTZ) and the
  topology outside of the TTZ, excluding any unusable links."
This sounds like a very inefficient way.  Why wouldn't a router simply use the
TTZ Router LSA for every TTZ Router and the regular Router LSA if the originating
router didn't also originate a TTZ Router LSA?

10) Sec 11.1:  This implies that a router can have different TTZ IDs on its different links.  Is that the case?!?
Consider the case where there is a router X with the following:
        link X.1  TTZ ID = none
        link X.2  TTZ ID = 10          router Y is another edge router in TTZ 10
        link X.3  TTZ ID = 20          router Z is another edge router in TTZ 20

Now, when X advertises its Router LSA, it will advertise X.1,  virtual-TTZ-ID-10.to_Y, and virtual-TTZ-ID-20.to_Z.
I don't know what X puts into its TTZ Router LSA for TTZ ID=10 or ID=20.  I guess it would originate
    X.1, virtual-TTZ-ID-10.to_Y and X.3 for TTZ-ID=20  and
    X.1, X.2, virtual-TTZ-ID-20.to_Z for TTZ-ID=10
I think it could be made to work, but there's some missing text if this is a real case.  I suspect what you want is:
"If one link of a router is configured with a particular TTZ ID, other links of that router can either have no TTZ ID
or have the same particular TTZ ID.  Two links of the same router MUST NOT have different TTZ IDs configured."

11) Sec 11.2:  "a user issues a CLI command on one router in the TTZ"  How about configures instead of CLI command?
We are heading towards a brave new world of NetConf.

"  Thirdly, a user checks whether a router in the TTZ is ready for
  migration to TTZ.  A router in the TTZ is ready after it has received
  all the necessary information from all the routers in the TTZ.  This
  information may be displayed on a router through a CLI command."
All necessary information isn't descriptive or useful!  Please be specific.
I think what is needed is to have received the TTZ Router LSAs from all
TTZ Edge Routers.  This check depends upon the operator, since which
routers are TTZ Edge Routers depends on the intended network topology
and not a specific router's configuration.

bottom of p. 19 "For rolling back from TTZ, it is similar.":
This is a normative specification.  PLEASE specify it exactly.

" After a router receives a TTZ LSA with OP for M for 3) from another
  router, it checks whether 2) is performed through checking if it has
  received/originated TTZ LSAs.  If it has not, it issues an error and
  logs the error.  The operation for migration will continue."

So - how does a TTZ network with one misconfigured router in the middle work?
Does it cause issues?  That router doesn't think it is a TTZ Edge Router - so it doesn't
get virtual links to it from the other TTZ Edge Routers - and its neighbors don't think
that they are TTZ Edge Routers, so again no virtual links.    If I go by
reading of Sec 9.1, then the neighbor routers won't flood their Router LSA to the misconfigured
router because the neighbor routers believe they are in the TTZ - just with some links without
a TTZ adjacency??!  As best as I can tell, a router  link this is stranded and unreachable. 
WHY isn't it preferable to have the router start to generate and advertise the TTZ information.

Is the same stranding of a router in TTZ mode when migrating away from TTZ expected?

12) Sec 13:  The implementation experience is good to see, but please remove personal judgments
like "easy" and straightforward".  Normally the implementation experience section is removed from
internet-drafts when they are published as an RFC.  Please move Sec 13 to an Appendix with a suitable
note to the RFC Editor for removal.  If you strongly want to leave it in, we can discuss additional clean-up.

13) Sec 14:  "The mechanism described in this document does not raise any new
  security issues for the OSPF protocols since a TTZ is enclosed in a
  single area."  I think you've introduced the ability to cause at least all TTZ internal routers to
be isolated and stranded if one malicious router sends a TTZ LSA with OP=R into a running TTZ.
I'm not positive that you don't have a similar scenario for OP=M; that case needs to be thought
through - you may just end up with isolated regions of routers.

At a minimum, something that prevents injection attacks is really important, given these issues.

14) Appendix A:  Please move this into the main draft and use normative language and indicate whether these
are fixed constants or subject to configuration.  I will note that 0.1 seconds is only 100 ms and whether it is practical
can easily depend upon the propagation delay within the area.

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

      An Experimental 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 for a Topology Transparent Zone
      within an area which is hidden from the rest of the network. The TTZ
      can still route or provide services end to end by creating virtual links
      to all its edge routers.

Working Group Summary:

    There has been some discussion on the draft in the wg and it is a
    natural extension in OSPF. There was discussion on the mailing list
    with respect to TTZ transitions during the WG last call and these
    were addressed in a revision of the draft.

Document Quality:

      This document has been a WG document for a little over 1 year.
      It is stable, without changes to the technical solution for more
      than six months.

Personnel:

      Padma Pillay-Esnault 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.

      Yes.
      https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ospf-ttz
     

      There wasn't any discussion. IPR on drafts is quite common.

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

      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).
 
      Under Registry Name:
    "OSPF Opaque Link-State Advertisements (LSA) Option Types",
    a new Opaque type registry value 9 for Topology-Transparent Zone (TTZ)
    LSA is requested.

http://www.iana.org/assignments/ospf-opaque-types/ospf-opaque-types.xhtml


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

      A new Opaque type registry value 9

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