Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"

[Huaimo Chen <[e-mail]>]

Hi Acee,

Thank you very much for your comments.

Best Regards,
Huaimo
From: Acee Lindem (acee) [mailto:[e-mail]]
Sent: Monday, February 08, 2016 6:29 PM
To: Huaimo Chen; OSPF WG List; [e-mail]
Subject: Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"

Hi Huaimo,

From: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 8, 2016 at 12:03 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"


Hi Acee,



    Thank you very much for your valuable comments.

    My answers/explanations are inline below.



Best Regards,

Huaimo

-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]]
Sent: Friday, February 05, 2016 7:32 PM
To: Acee Lindem (acee); OSPF WG List; [e-mail]<mailto:[e-mail]>
Subject: Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"



The WG Last Call has ended. I do have a couple minor comments.



   1. Section 1 list the advantages for setting up an LSP over a TTZ as

opposed

      to an area. The details of this are not described in the document so

this

      should either be removed or the document should explicitly state the

details

      of LSP setup are out of scope.

[Huaimo]: This will be removed from the document.

Great.




   2. In section 11.2, I can see some race conditions if different TTZ

status is

      configured on different routers in the TTZ during the

migration/rollback

      period. This is addressed by saying a warning message will be issued

if

      this occurs. How is this detected and will the conflicting operation

be

      rejected?

[Huaimo]: We will add some details about the detection and operation.

The conflicting/racing condition/operation can be detected on a router on which a configuration is issued.

When a configuration for controlling an action for migration/rollback is issued on a router, the router should check whether the action is in a correct sequence of actions for migration/rollback through using the information it has. For migrating a part of an area to a TTZ, the correct sequence of actions is as follows in general:

1) configure TTZ on every router in the part of the area to be migrated to TTZ;

2) configure on one router in the TTZ to trigger every router in the TTZ to generate and distribute TTZ information for migration; and

3) configure on one router in the TTZ to trigger every router in the TTZ to migrate to TTZ.

For rolling back from TTZ, it is similar.

After receiving a configuration on a router to migrate to TTZ, which is for action 3), the router checks whether action 2) is performed through checking if it has received/originated a TTZ LSA with T=1. If it has not, it gives a warning to an operator (generation and distribution of TTZ information for migration to TTZ are not done yet) and rejects the configuration at this time.

After a router receives a TTZ LSA with M=1 for action 3) from another router, it checks whether action 2) is performed through checking if it has received/originated a TTZ LSA with T=1. If it has not, it should give a warning. The operation for migration will continue.

After receiving a configuration on a router to generate and distribute TTZ information, which is for action 2), the router checks whether action 1) is performed through checking if TTZ is configured on it. If it is not, it gives a warning to an operator (TTZ is not configured on it yet) and rejects the configuration at this time.

I guess my concern is a sequence such as migration started from multiple routers followed by rollback from multiple routers. This testing scenario is probably something that could be addressed should the protocol move to standards track.
[Huaimo]: I will keep this in my mind.




   3. I guess one misconfigured router (no TTZ ID configured) will keep

migration

      to TTZ from occurring. What happens if a misconfigured router is

introduced

      on a broadcast link? Do all routers on the link revert to non-TTZ

operation?

[Huaimo]: You are right. When there is one mis-configured router on a broadcast link, this link will not be migrated to TTZ. If a mis-configured router is introduced on a broadcast link, this broadcast link will be revert to non-TTZ link. In other words, each of the routers on the link reverts the status for its connection to the link to non-TTZ.

Once the TTZ is migrated, it seems it may be better just not to form adjacencies with the misconfigured router.
[Huaimo]: I agree with your opinion. Some description about this will be added into the document.

Thanks,
Acee





I also have a number of editorial comments but will send those offline.

[Huaimo]: We will address them accordingly.



Thanks,

Acee





On 1/17/16, 3:30 PM, "OSPF on behalf of Acee Lindem (acee)"

<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:



>This is the start of the WG last call for the “OSPF Topology Transparent

>Zone” protocol extensions draft. We’ve had a number of discussions on this

>and Huawei has a prototype implementation. The WG last call will end at

>12:00 AM PDT on February 1st, 2016. For your convenience, here is a URL:

>

>https://datatracker.ietf.org/doc/draft-ietf-ospf-ttz/

>

>Thanks,

>Acee and Abhay

>

>_______________________________________________

>OSPF mailing list

>[e-mail]<mailto:[e-mail]>

>https://www.ietf.org/mailman/listinfo/ospf