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

Adrian Farrel <adrian@olddog.co.uk> Sat, 31 December 2022 17:32 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E13C14F746; Sat, 31 Dec 2022 09:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdu-eIaRIaUT; Sat, 31 Dec 2022 09:32:19 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247AFC14F73F; Sat, 31 Dec 2022 09:32:18 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 2BVHWFV8005499; Sat, 31 Dec 2022 17:32:15 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0405E4604B; Sat, 31 Dec 2022 17:32:15 +0000 (GMT)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D87274603D; Sat, 31 Dec 2022 17:32:14 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Sat, 31 Dec 2022 17:32:14 +0000 (GMT)
Received: from LAPTOPK7AS653V ([85.255.234.76]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 2BVHWCij018218 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 31 Dec 2022 17:32:14 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, 'TEAS WG' <teas@ietf.org>
Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
References: <CA+YzgTtea0kGY3KG8L_+nzJGKsB5v43M_+rB4a=V8rWzxC-R2w@mail.gmail.com>
In-Reply-To: <CA+YzgTtea0kGY3KG8L_+nzJGKsB5v43M_+rB4a=V8rWzxC-R2w@mail.gmail.com>
Date: Sat, 31 Dec 2022 17:32:12 -0000
Organization: Old Dog Consulting
Message-ID: <00ae01d91d3d$d269f430$773ddc90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01D91D3D.D26C6530"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJhJhSQoViu5vu+6/5Bsz8Wq7aOva14L1SA
Content-Language: en-gb
X-Originating-IP: 85.255.234.76
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=qC2rL5efulFwAcRHMN7HI /7A8Luq55qH0TGvL8e6cDg=; b=tDZeYD8EKS8FWMQ1KDJwx57MwnUAtIdqazb4E QMsfGf1EKhFiqR+TFd/OgsMLdnLWIN2Ir/Kd9HXmFWr71VezLrecJxkFexRgNnuA ZHOOA3da62fNVqoV+OSIbqS9qfxNZIXgP3MQil9r6WpYeLfzZdsD/LzRSKeF8WnX 3kHZWm/yKoD/MK2HySvnQXyq1R0gTvqwb5ZyOLE62HbJ8xpLHzVeKEGNbBPOKBwl wZyF7v6xTjxj+d8SS8tU8nI1Wi1AlCPlHUdr4gN6NESHq6pt6KrzrEjJH8k056M0 8OimLp9j7ldK2vSCerPGXXns7bxepuAYFboIbuiSPlfcEIF+Q==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27358.001
X-TM-AS-Result: No--23.493-10.0-31-10
X-imss-scan-details: No--23.493-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27358.001
X-TMASE-Result: 10--23.492700-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFpfsB4HYR80ZnFPUrVDm6jtWQ3R4k5PTnAxkLdkW7C5qlKC SV79DbqwhI7uvji8nitbt6imOqY8z8I1PXTjdX0UCbJWswK4n1Kb+3jd3k4RfmuyajlFLKLVDBs Hp9ZCSqzMJ/T9+8TxQEBbvvgVD0b6rVflBLZuaVljLoC0DLthl7JOtZXi/DJfUrzkbjREjNLVOC IlEhiCO4mqFO2zmhlJBt+ZjFMtGVy2DgCxqSHVW8IkzTqL3E/WkKAa/khZ3iRl3sLG6knmdbflO SzUm3Nzxfnac5qfYXhajKQ9L/HFrUabKAwppBdSbb4JyMK+kzB6oAClUVGQPCBQRBOQhaJi+MDY hfPaDFxk9GphLmOs2Ct3iTl8Q4UR8HpDMTPRotkEClJgjzpjqJbRfsVvs4VIMnTEcPZ5c0qeogC /cYy6SE/u2Mzbp/URkrM6og8RGSxaSb0pBpxm6CcK0wQEhQduJ4cwIYL6KudmpUN+9N+Zfvl+hN lUoH3vJ7JdVKQueDnfKKmQCZGZgCFXDo5KmtxCLGQFtelDl4s/djoNyDmZbTqIqUx4xEH9PLvQa zfJ0mOnceLJy5PCoDRW3SH9+s8Wz7SJf0EvgnXgBAJugumgYAT2OEnoCt48bPfGfHxv+pEqA5Ia mxBA3OswT7gm8Pvp/EOoChtRad2RTfgfKCWeWoh/ebSxR/Hn1KDIlODIu+UrXQa6mSZlS88Oalp DJEQlYG9kc/EZj+XNV3UGGzvqJERfCdMIZ+bd/Sl5cYQQGW8O8pJojG7qSlcbfIj2Ta9sKlgCas XEiGIuRO12BAo03lJ7qurUfgrV/7PvFa8I/I+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPCy5/tFZ u9S3M+9+OQ9U/5fvECLuM+h4RB+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6mt88d1b_7fUy5UMOAKPmBhtCOE>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-controller-inter-work-09
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Dec 2022 17:32:24 -0000

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"

 

---

 

Title

 

s/System/Systems/

 

---

 

Abstract

 

s/issue/issues/

 

s/-vendor/-vendor,/

 

Should expand "ACTN"

 

---

 

1.

 

s/More generic description for/A more generic description of/

s/with centralized/with a centralized/

s/in transport/in a transport/

 

---

 

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

 

---

 

2.2

 

s/and standard/and a standard/

 

---

 

OLD

2.3. GMPLS Control Interwork with Centralized Controller System 

NEW

2.3. GMPLS Control Interworking with a Centralized Controller System 

END

 

---

 

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/

 

---

 

Figure 1

 

s/interworks/interworking/

 

---

 

3.

 

s/need/needs/

 

---

 

3.1

 

s/property/properties/

 

---

 

4.

 

s/In centralized/In a centralized/

s/system, centralized/system, the centralized/

s/at the GMPLS network/in the GMPLS network/

 

---

 

4.1

s/OSPF protocol/OSPF/

 

OTN and WSON need to be expanded

 

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

 

---

 

4.3

 

s/Besides, these/These/

 

---

 

5.

 

s/Yang/YANG/

 

---

 

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?

 

---

 

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.

 

---

 

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/

 

---

 

6.

 

s/setup LSPs/set up LSPs/

 

---

 

7.1

 

s/element(s)/elements/

 

---

 

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)

 

---

 

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?

 

---

 

7.2

 

Please expand BRPC and H-PCE on first use

 

---

 

7.3.1

 

Please expand NMS and VNTM

 

---

 

7.3.2

 

s/then can/can then/

 

Please expand ERO

 

---

 

7.3.3

 

Please expand FA/FA-LSP

 

s/separated GMPLS/separate GMPLS/

s/one of the both layer/one of the layer/

 

---

 

7.4.2

 

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

8234?

 

---

 

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

 

---

 

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

 

---

 

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

 

---

 

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.

 

---

 

7.5

 

s/It can be/This can be/

 

From: Teas <teas-bounces@ietf.org> On Behalf Of Vishnu Pavan Beeram
Sent: 28 December 2022 12:11
To: TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <teas-chairs@ietf.org>
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