Re: [Teas] Some comments to RSVP and TE YANG model

"Zhangxian (Xian)" <> Mon, 19 October 2015 09:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E14831A8795 for <>; Mon, 19 Oct 2015 02:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g5mOUhGY0z5P for <>; Mon, 19 Oct 2015 02:13:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88F331A876F for <>; Mon, 19 Oct 2015 02:13:00 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BYZ13535; Mon, 19 Oct 2015 09:12:58 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 19 Oct 2015 10:12:56 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 17:12:47 +0800
From: "Zhangxian (Xian)" <>
To: "Tarek Saad (tsaad)" <>
Thread-Topic: Some comments to RSVP and TE YANG model
Thread-Index: AdDqBDTbygC9JZr0T6edq4rb/yWC7geVyQ4AAHxqtkA=
Date: Mon, 19 Oct 2015 09:12:47 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B54AD0562SZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: "Chenxia (D)" <>, Dhruv Dhody <>, "" <>
Subject: Re: [Teas] Some comments to RSVP and TE YANG model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2015 09:13:06 -0000

Hi, Tarek,

Thank you for your reply.

All looks fine to me,  except the following point left unanswered:

For RSVP-TE YANG model:
4: how is the lsp-source different from the base module’s source?

From: Tarek Saad (tsaad) []
Sent: 2015年10月17日 4:41
To: Zhangxian (Xian)
Cc: Chenxia (D); Dhruv Dhody;
Subject: Re: Some comments to RSVP and TE YANG model

Hi Xian,

Thanks for your review and comments. Inline for responses.

From: "Zhangxian (Xian)" <<>>
Subject: Some comments to RSVP and TE YANG model

Hi, Tarek,

   I have read in the detail the part I am very interested (mostly related to LSP states) and have the following comments. Hope it is helpful for the next iteration.

For TE YANG model:
1: Bandwidth information is missing?
[TS]: this was added in the latest version @

2: why is “type” part of the key for lsps-state? I think five-tuple information should be sufficient.
[TS]: P2MP and P2P tunnels can share the 5-tuple but differ in the type (I.e. Type is a differentiator, e.g. when have 2 tunnels (p2p and p2mp) sharing the same 5-tuples).

3: for the downstream-info and upstream-info, we/people naturally can see that for ingress no upstream and egress no downstream. But in the yang code, it would be better with a ‘when’ statement to confine this. Similar to that of the lsp-timers.
[TS]: yes, these checks are added in the latest version of the model.

Another 3 side questions:

A)     For upstream-info; phop is better than nhop.
[TS]: corrected.

B)     What is the difference between neighbor and nhop/phop?
[TS]: neighbor indicates the neighbor node-id, and nhop/phop indicates the next/previous-hop address on the link/interface.

C)     Label currently is only 32 bit, what should I do if I argument this model and my label is in a different format?
[TS]: we plan to address this by defining a generic (union) definition of the label (for PSC it will continue to be uint32). This is on our TODO.

For RSVP-TE YANG model:
4: how is the lsp-source different from the base module’s source?

5: local-recording-desired: do you intend to say label recording, which is specified in the cited RFC?
[TS]: correct. We are reusing the RFC and IANA naming for it (e.g. rfc3209 section 4.7.1) but I agree it could be made more explicit..

6: end-to-end rerouting (not routing), boundary & segment-based are mutually exclusive: have you considered using one value to express this, instead of three?.
[TS]: yes, this was grouped into one leaf that takes 1 of the above as value.

7: for the RRO and ERO, Now, they organize as:

-incoming ERO
     +incoming ERO list
-outgoing ERO
+outgoing ERO list
-incoming RRO
     +incoming RRO list
-outgoing RRO
+outgoing RRO list

wonder why they do not organize as below?

     +incoming ERO list
+outgoing ERO list
     +incoming RRO list
+outgoing RRO list

[TS]: agreed, the latter seems more user-friendly. we’ve made the change the latest version.


Do you see any specific reasons why/why not organize in the other way?