Subject: [OSPF] AD review of draft-ietf-ospf-ttz-04

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Dec 2016 18:14:52 -0500

As is customary, I have done my AD review of draft-ietf-ospf-ttz-04.
First, I would like to thank the authors, Huaimo, Renwei, Alvaro, Yi,  Vic,
& Mehmet, as well as the contributors & the WG for their work on this
document.

With this number of authors, it is necessary to either select a small
number of editors or provide significant justification for how each author
has contributed to the document.
The draft cannot proceed to IETF Last Call until that is done.

In my review below, I have found a number of issues with this document.
Several are significant enough technical concerns that may add non-trivial
text to the draft and thus require addressing before IETF Last Call.

If these issues are addressed with an updated document by Dec 15, it is
possible that the draft could make the Jan 5 IESG telechat.

1) Please clarify somewhere in the introduction that this is only 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."

What is meant by "the operation for migration will continue".  PLEASE be
extremely clear and detailed in the document.   I first read it as meaning
that the rest of the network would continue to do the migration - since
other routers are getting the TTZ LSA OP=M.    That would, of course,
strand the unmigrated router.

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.

Just FYI for the future, this would be even more helpful if any of the
error paths or failure cases and race conditions were examined and tested.

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."   Depending on the failure behavior I asked about in (11),
you might
have 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 depend upon the propagation delay within the area.

Regards,
Alia

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 14 Dec 2016 01:48:15 +0000

Hi Alia,

    Thank you very much for your detailed review of draft-ietf-ospf-ttz-04.  Your review has been discussed with the authors and we hope you will find the new version addresses your major or minor issues. Please find our responses in-line below:

[HC]: Huaimo Chen on behalf of authors

> As is customary, I have done my AD review of draft-ietf-ospf-ttz-04.  First, I would like to thank the authors, Huaimo, Renwei, Alvaro, Yi,  Vic, & Mehmet, as well as the contributors & the WG for their work on this document.
>
> With this number of authors, it is necessary to either select a small number of editors or provide significant justification for how each author has contributed to the document.

[HC]: The original idea of TTZ draft is from Renwei and Huaimo. Alvaro has made significant contributions to TTZ draft, including TTZ configurations, migrations to TTZ and rolling back from TTZ, and definitions of some data formats. Yi has contributed to constructing LSAs for TTZ and discovery of TTZ neighbors. Vic and Mehmet have contributed to the requirements and operations on TTZ. Vic made a good presentation on TTZ in IETF and answered some questions about TTZ.

> In my review below, I have found a number of issues with this document.   Several are significant enough technical concerns that may add non-trivial text to the draft and thus require addressing before IETF Last Call.
>
> If these issues are addressed with an updated document by Dec 15, it is possible that the draft could make the Jan 5 IESG telechat.
>
> 1) Please clarify somewhere in the introduction that this is only for OSPFv2.

[HC]: In the introduction, "... extensions to OSPFv2 ..." is stated.

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

[HC]: Replaced "TTZ-LSA-Type (9)" with "TTZ-LSA-Type (TBD)" and
removed "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?

[HC]: Added specification on the TLV-Length, and
more details on TTZ ID in Sec 5.1 and Sec 11.1, which should answer these questions.

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

[HC]: Added text about when flag Z is set to 0 and reference to Sec 6.4.

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

[HC]: Added reference and clarification accordingly as you suggested.

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

[HC]: Changed the first sentence to disconnect it from the second one.
They are not directly related.

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

[HC]: Explicitly stated that it is based on configurations.

> " When   another TTZ router receives the LSA with OP for N, it advertises its
> 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.

[HC]: The receiving TTZ router does not originate a new TTZ control LSA.
It forwards/floods the LSA with OP for N.
Added "it forwards the LSA" after receiving the LSA.
The LSA means the TTZ control LSA.
This may help clarify "stops advertising its TTZ LSAs" not include
the TTZ control LSA received.

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

[HC]: Operators should follow a correct sequence of operations:
At first, configure to advertise normal LSAs and stop advertising TTZ LSAs.
And then configure to roll back from TTZ.
Some details are added in Sec 11.2 (around the end of Sec 11.2) to describe what happens
in the case you mentioned.

> 6) Sec 7.1:  "also by adding the stub links for the loopback addresses in the TTZ to
> How does a TTZ Edge Router determine set of loopback addresses in the TTZ to be advertised?

[HC]: Added "according to configuration policy of operators"
to indicate that the loopback addresses are determined based
on configurations.

> 7)  Sec 8.1 "   If two ends of the link have different TTZ IDs or only one end is
>    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.

[HC]: A TTZ router can have multiple TTZ IDs on its multiple links,
each of which has a different TTZ ID. TTZ ID is per link.
The usage of TTZ IDs are added and clarified in Sec 11.1.
In current extensions to OSPFv2, we can not migrate from
one TTZ ID to another TTZ ID without migrating away from TTZ.
One TTZ with a TTZ ID can be roll/migrate back to a part of area,
and then migrate to another TTZ with another TTZ ID.
Multiple D-LSAs are received one after another.
When one of the D-LSAs is received from a neighbor with
same TTZ ID, a TTZ adjacency is formed.
When another D-LSA is received from the same neighbor with
different TTZ ID, the TTZ adjacency is removed.
Revised Sec 8.1 using conformance language.

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

[HC]: Changed the text according to your suggestion.

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

[HC]: Added descriptions about how the TTZ Edge Router
determines that an LSA is about a TTZ internal link state.
A TTZ internal router advertises a router LSA and
a TTZ indication LSA, which indicating the router LSA
is about a TTZ internal link state.

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

[HC]: Updated the text in Sec 7 to clarify.

> 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

[HC]: The implementation is removed.
The idea you described will work.

> 10) Sec 11.1:  This implies that a router can have different TTZ IDs on its different links.  Is that the case?!?
>          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
> 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."

[HC]: Yes. That is the case.
Added the missing text accordingly.

> 11) Sec 11.2:  "a user issues a CLI command on one router in the TTZ"   How about configures instead of CLI command?
> extremely clear and detailed in the document.   I first read it as meaning that the rest of the network would continue to do the migration - since other routers are getting the TTZ LSA OP=M.    That would, of course, strand the unmigrated router.

[HC]: Changed CLI command to configuration or configure
according to your suggestion.
Updated the text to be more specific.
Replaced "For rolling back from TTZ, it is similar." with
detailed descriptions on correct sequence of operations
for rolling back from TTZ.
Revised the paragraph with specific specification and details.

> 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.
>
> Just FYI for the future, this would be even more helpful if any of the error paths or failure cases and race conditions were examined and tested.

[HC]: Removed personal judgments as you suggested.
Moved Sec 13 to an Appendix.

> 13) Sec 14:  "The mechanism described in this document does not raise any new
>   single area."   Depending on the failure behavior I asked about in (11), you might
> have 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.

[HC]: Added something accordingly as you suggested.

> 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 depend upon the propagation delay within the area.

[HC]: Updated the main draft accordingly as you suggested.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Dec 2016 10:55:58 -0500

Hi Huaimo,

Thank you for the updated draft that addresses my comments.

I am concerned about the attack vector that the op-code migration opens,
but at least it is documented and this is experimental.

I will move this to IETF Last Call and place it on the IESG telechat for
January 5.

Regards,
Alia

On Tue, Dec 13, 2016 at 8:48 PM, Huaimo Chen <[email-masked]> wrote:

> Hi Alia,
>
>
>
>     Thank you very much for your detailed review of
> draft-ietf-ospf-ttz-04.  Your review has been discussed with the authors
> and we hope you will find the new version addresses your major or minor
> issues. Please find our responses in-line below:
>
>
>
> [HC]: The original idea of TTZ draft is from Renwei and Huaimo. Alvaro has
> made significant contributions to TTZ draft, including TTZ configurations,
> migrations to TTZ and rolling back from TTZ, and definitions of some data
> formats. Yi has contributed to constructing LSAs for TTZ and discovery of
> TTZ neighbors. Vic and Mehmet have contributed to the requirements and
> operations on TTZ. Vic made a good presentation on TTZ in IETF and answered
> some questions about TTZ.
>
>
>
>
>
> > In my review below, I have found a number of issues with this
> document.   Several are significant enough technical concerns that may add
> non-trivial text to the draft and thus require addressing before IETF Last
> Call.
>
> >
>
> > 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
> > "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.
>
>
>
> >    Can a TTZ router have multiple TTZ IDs?  Are the TTZ IDs per router?
> Is it possible to migrate from one TTZ ID to
>
> >   "If the D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or
> is explicitly flushed, then the TTZ adjacency MUST be
>
> > 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:
>
> > 11) Sec 11.2:  "a user issues a CLI command on one router in the TTZ"
> How about configures instead of CLI command?
>
> > extremely clear and detailed in the document.   I first read it as
> meaning that the rest of the network would continue to do the migration -
> since other routers are getting the TTZ LSA OP=M.    That would, of course,
> > have 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

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 16 Dec 2016 15:59:16 +0000

Hi Alia,

    Thank you very much for your time and valuable comments, which have improved the quality of the draft a lot.

Best Regards,
Huaimo
From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, December 16, 2016 10:56 AM
To: Huaimo Chen
Cc: OSPF List; [email-masked]
Subject: Re: AD review of draft-ietf-ospf-ttz-04

Hi Huaimo,

I am concerned about the attack vector that the op-code migration opens, but at least it is documented and this is experimental.

I will move this to IETF Last Call and place it on the IESG telechat for January 5.

Regards,
Alia

On Tue, Dec 13, 2016 at 8:48 PM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Regards,
Alia