Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-controller-inter-work-09

["Linyi (Yi)" <[e-mail]>]

Dear Adrian,

Thank you for your detailed review on the draft. Please see below the replies in-line with [Authors].
We’ll post the new revision (-10) before the deadline of the upcoming IETF 116th, if you could agree on our replies and changes.
Thank you.

B.R.
Yi LIN

HUAWEI Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
http://www.huawei.com<http://www.huawei.com/>
---------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!

发件人: Teas [mailto:[e-mail]] 代表 Adrian Farrel
发送时间: 2023年1月1日 01:32
收件人: 'Vishnu Pavan Beeram' <[e-mail]>; 'TEAS WG' <[e-mail]>
抄送: 'TEAS WG Chairs' <[e-mail]>
主题: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-controller-inter-work-09

Hi all,

I've read this draft as part of working group last call, and I think is
ready to progress for publication.

Plenty of nits, below.

Happy New Year,

Adrian

===

Throughout:
According to RFC 6241, you should use "NETCONF"
According to RFC 8040, you should use "RESTCONF"

[Authors] OK

---

Title

s/System/Systems/

[Authors] OK

---

Abstract

s/issue/issues/

s/-vendor/-vendor,/

Should expand "ACTN"

[Authors] OK

---

1.

s/More generic description for/A more generic description of/
s/with centralized/with a centralized/
s/in transport/in a transport/

[Authors] OK

---

2.1

   the controller can also collect node and link
   resources in the network

Technically, the controller doesn't collect the resources. Perhaps...

   the controller can also collect information about node and link
   resources in the network

[Authors] OK

---

2.2

s/and standard/and a standard/

[Authors] OK

---

OLD
2.3. GMPLS Control Interwork with Centralized Controller System
NEW
2.3. GMPLS Control Interworking with a Centralized Controller System
END

[Authors] OK

---

2.3

s/Besides the GMPLS/Besides GMPLS/
s/a NE/an NE/
s/initiate LSP/initiate LSPs/
s/element were/elements were/
s/control can be purely/control is purely/
s/GMPLS capability/GMPLS capabilities/
s/LSAs for/LSAs, for/
s/using for example/using, for example,/
s/the e.g. [RFC8795] Yang/the, e.g., [RFC8795] YANG/
s/domain and export/domain, and export/
s/create topology graph/create a topology graph/
s/To setup a/To set up a/
s/exploit e.g. [TE-Tunnel] Yang/exploit, e.g., [TE-Tunnel] YANG/
s/between the GMPLS/between GMPLS/
s/domain(s)/domains/  (twice)
s/controller(s)/controllers/
s/if exists/if it exists/

[Authors] OK

---

Figure 1

s/interworks/interworking/

[Authors] OK
---

3.

s/need/needs/

[Authors] OK
---

3.1

s/property/properties/

[Authors] OK

---

4.

s/In centralized/In a centralized/
s/system, centralized/system, the centralized/
s/at the GMPLS network/in the GMPLS network/

[Authors] OK

---

4.1
s/OSPF protocol/OSPF/

OTN and WSON need to be expanded

s/flexi-grid network/flexi-grid networks/

[Authors] OK

---

4.3

s/Besides, these/These/

[Authors] OK

---

5.

s/Yang/YANG/

[Authors] OK

---

In section 5 where you say that a controller can interact with another
controller using [PAT-COMP], why do you not also mention that
controllers can interact with each other using PCEP?

[Authors] We do not mention PCEP here for the reason that we had a specific section (Section 5.2) describing PCE and PCEP usage. The YANG for path computation request is exactly in the scope of this paragraph.
So we have 3 methods for path computation:
1)      YANG path computation request (in Section 5)
2)      GMPLS source node (in Section 5.1)
3)      PCE and PCEP (in Section 5.2)
We suggest to make the text originally in Section 5 as Section 5.1, and change the original Section 5.1 and 5.2 to Section 5.2 and 5.3 accordingly. I.e.:
OLD
5. Path Computation
Once a controller learns …
5.1. Constraint-based Path Computing in GMPLS Control
In GMPLS control, a routing path …
5.2. Path Computation Element (PCE)
PCE has been introduced …
NEW
5. Path Computation
5.1 Controller-based Path Computation
Once a controller learns …
5.2. Constraint-based Path Computing in GMPLS Control
In GMPLS control, a routing path …
5.3. Path Computation Element (PCE)
PCE has been introduced …
END

---

5.1

   In GMPLS control, a routing path is computed by the ingress node
   [RFC3473] and is based on the ingress node TED. Constraint-based
   path computation is performed according to the local policy of the
   ingress node.

This *may* be true, but it is also possible for the request to set up
the LSP to arrive with the path explicitly specified. This option is
available on most CLI implementations.

[Authors] Since this section is about constraint-based path computing, we think it’s not necessary to mention the option about explicit ERO. So how about:
OLD
In GMPLS control, a routing path is computed by the ingress node [RFC3473] and is based on the ingress node TED. Constraint-based path computation is performed according to the local policy of the ingress node.
NEW
In GMPLS control, a routing path may be computed by the ingress node ([RFC3473]) based on the ingress node TED. In this case, constraint-based path computation is performed according to the local policy of the ingress node.
END
---

5.2

s/compute path/compute paths/

OLD
   the Traffic Engineering
   Database (TED), which maintains the link resources in the network
NEW
   the Traffic Engineering
   Database (TED), which maintains a view of the link resources in the
   network
END

s/efficiently improve/efficiently improves/
s/In PCE Initiation/With PCE-Initiated LSPs/
s/PCC to/PCC to perform/
s/In centralized/In a centralized/
s/architecture can be found at/architectures can be found in/

[Authors] OK
---

6.

s/setup LSPs/set up LSPs/

[Authors] OK
---

7.1

s/element(s)/elements/

[Authors] OK

---

7.2

s/request coordination/require coordination/
s/of such asymmetrical segment/of such asymmetrical segments/
s/links are also needed/links also need/
s/If the resource of inter-domain/If the resources of inter-domain/
s/using IETF Topology model/using the IETF Topology YANG model/
s/Once that the/Once the/
s/boarder/border/  (four times)

[Authors] OK

---

7.2 option 2)

   For example, the
   path segment 1 and 3 in Figure 3 are asymmetrical segments, because
   one end of the segment requires mapping GE into ODU0, while the
   other end of the segment requires setting up ODU0 cross-connect.

The introduction of GE and ODU0 in this example suddenly seems very
technical when we were previously happy with abstract examples. While
this is certainly an example, would it be possible to generalise it?

[Authors] Agree to generalise the example, by using “client signal” instead of “GE”, and using “Server layer tunnel” instead of “ODU0”. Please see below:
OLD
Note that path segments in the source domain and the destination
domain are “asymmetrical” segments, because the configuration of
client signal mapping into server layer tunnel is needed at only one
end of the segment, while configuration of server layer cross-
connect is needed at the other end of the segment. For example, the
path segment 1 and 3 in Figure 3 are asymmetrical segments, because
one end of the segment requires mapping GE into ODU0, while the
other end of the segment requires setting up ODU0 cross-connect.
                    +------------------------+
                    |    Orchestrator(MD)    |
                    +-----------+------------+
                                |
   +---------------+     +------V-------+     +---------------+
   |  Controller   |     |  Controller  |     |  Controller   |
   +-------+-------+     +------+-------+     +-------+-------+
           |                    |                     |
  +--------V--------+   +-------V--------+   +--------V--------+
  |Client           |   |                |   |           Client|
  |Signal   Domain 1|   |    Domain 2    |   |Domain 3   Signal|
  |(GE)             |   |                |   |            (GE) |
  |  |   ODU0 tunnel|   |                |   |              |  |
  |+-+-+       ^    |   |                |   |            +-+-+|
  || | |  +--+ |+--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
  || | |  |  | ||  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
  || ******************************************************** ||
  ||   |  |  |  |  || . ||  |  |  |  |  || . ||  |  |  |  |   ||
  |+---+  +--+  +--+| . |+--+  +--+  +--+| . |+--+  +--+  +---+|
  +-----------------+ . +----------------+ . +-----------------+
   .                  .                    .                  .
   .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
           Figure 3: Example of asymmetrical path segment
NEW
Note that path segments in the source domain and the destination
domain are “asymmetrical” segments, because the configuration of
client signal mapping into server layer tunnel is needed at only one
end of the segment, while configuration of server layer cross-
connect is needed at the other end of the segment. See the example
in Figure 3.
                    +------------------------+
                    |    Orchestrator(MD)    |
                    +-----------+------------+
                                |
   +---------------+     +------V-------+     +---------------+
   |  Controller   |     |  Controller  |     |  Controller   |
   +-------+-------+     +------+-------+     +-------+-------+
           |                    |                     |
  +--------V--------+   +-------V--------+   +--------V--------+
  |Client   Domain 1|   |    Domain 2    |   | Domain 3  Client|
  |Signal           |   |                |   |           Signal|
  |  |  Server layer|   |                |   |              |  |
  |  |     tunnel   |   |                |   |              |  |
  |+-+-+       ^    |   |                |   |            +-+-+|
  || | |  +--+ |+--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
  || | |  |  | ||  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
  || ******************************************************** ||
  ||   |  |  |  |  || . ||  |  |  |  |  || . ||  |  |  |  |   ||
  |+---+  +--+  +--+| . |+--+  +--+  +--+| . |+--+  +--+  +---+|
  +-----------------+ . +----------------+ . +-----------------+
   .                  .                    .                  .
   .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
           Figure 3: Example of asymmetrical path segment
END

---

7.2

Please expand BRPC and H-PCE on first use

[Authors] OK

---

7.3.1

Please expand NMS and VNTM

[Authors] OK
---

7.3.2

s/then can/can then/

Please expand ERO

[Authors] OK
---

7.3.3

Please expand FA/FA-LSP

s/separated GMPLS/separate GMPLS/
s/one of the both layer/one of the layer/

[Authors] OK
---

7.4.2

If you are going to mention APS, shouldn't you reference RFCs 7271 and
8234?

[Authors] Added the references to [RFC7271] and [RFC8234].

---

7.4.2

To avoid making a recommendation from this Informational document and so
bringing up the debate about using "RECOMMENDED", how about...

OLD
      In the scenario of
      interworking between GMPLS and centralized controller system, it
      is recommended to still use these distributed mechanisms rather
      than centralized mechanism (i.e., the controller triggers the
      protection switchover). This can significantly shorten the
      protection switching time.
NEW
      In the scenario of
      interworking between GMPLS and centralized controller system,
      using these distributed mechanisms rather  than centralized
      mechanism (i.e., the controller triggers the protection
      switchover) can significantly shorten the protection switching
      time.
END

[Authors] OK
---

7.4.3

   -  Pre-planned LSP rerouting (including shared-mesh restoration):

      In pre-planned protecting, the protecting LSP is established only
      in the control plane in the provisioning phase, and will be
      activated in the data plane once failure occurs.

This is confusing! The bullet heading uses "rerouting" and the text says
"protecting" (should be "protection" not "protecting"). Is it
intentional that two terms are used, or should they be the same?
(Compare with the next bullet.)

[Authors] These terms (working LSP, protecting LSP) are from RFC4872. We suggest to keep consistency with that RFC on the terms used for pre-planned LSP rerouting.
Please see Section 8 of RFC4872: https://www.rfc-editor.org/rfc/rfc4872#section-8
PS: We’ve noticed that RFC4872 uses “protecting LSP” in most places. Only one “protection LSP” is used in Section 9.

---

7.4.5

Another case of "recommended" can be handled as...

OLD
   If a PLR detects that failure occurs, it is recommended to still use
   the distributed mechanisms described in [RFC4090] to switch the
   traffic to the related detour LSP or bypass tunnel, rather than in a
   centralized way. This can significantly shorten the protection
   switching time.
NEW
   If a PLR detects that failure occurs, it may significantly shorten
   the protection switching time by using the distributed mechanisms
   described in [RFC4090] to switch the traffic to the related detour
   LSP or bypass tunnel, rather than in a centralized way.
OLD

[Authors] OK
---

7.5

   Once a controller is shut down, the network
   should operate as well.

I think this is ambiguous. Clearly, with the controller shut down you
cannot expect the same level of operation (no new LSPs, for example).
So you may mean...

   If the controller is shut down or disconnected from the network, it
   is highly desirable that all of the services currently provisioned
   in the network continue to function and carry traffic. Furthermore,
   protection switching to pre-established paths should also function.
   Additionally, it is desirable to provide protection mechanisms, such
   as redundancy, so that full operational control can be maintained
   even when one instance of the controller fails.

[Authors] OK

---

7.5

s/It can be/This can be/

[Authors] OK



From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Vishnu Pavan Beeram
Sent: 28 December 2022 12:11
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] WG Last Call: draft-ietf-teas-gmpls-controller-inter-work-09

All,

This starts a three-week working group last call on
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-controller-inter-work/

The working group last call ends on January 18th, 2023.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Note: There is no IPR disclosed for this draft.

Thank you,
Pavan and Lou