Re: [OSPF] Spencer Dawkins' No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

[Spencer <[e-mail]>]

Hi, Huaimo,

On 1/4/2017 10:00 PM, Huaimo Chen wrote:
> Hi Spencer,
>
>      Thank you very much for your time and valuable comments.
>      Your comments are addressed inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: Wednesday, January 04, 2017 5:27 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Spencer Dawkins' No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ospf-ttz-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-ttz/
>
>
>
> ----------------------------------------------------------------------
> 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.
> [HC]: We will put it into the Abstract as you suggested.
>
> 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?
> [HC]: A different number is used to identify a different TTZ. In general, this number is not zero. For example, we use number 100 for a TTZ, and number 200 for another TTZ. Number 0 is special. A TTZ (Topology Transparent Zone) can be considered as an improved Area in OSPF. A different number is used to identify a different Area. Number 0 is used to identify a backbone Area. From this, MUST is not used.

So, would it be correct to say

    A TTZ ID is a 32-bit number that is unique for identifying a TTZ.
    The TTZ ID SHOULD NOT be 0, to avoid confusion with Area 0, used to identify a backbone Area.

?

What I was asking about, was why someone would need to use 0 as a TTZ 
ID. From your explanation, I'm understanding that this isn't a MUST NOT 
because TTZ ID 0 would work just fine in OSPF, but would be more likely 
to cause confusion. Is that true?

If so, I'd be happier with SHOULD NOT, if the document hinted at the 
reason for this.

Thanks for the quick response!

Spencer

> 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.
> [HC]: We will put this into the Introduction and Abstract as you suggested.
>
>