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

["Zhangxian (Xian)" <[e-mail]>]

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?

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

Hi Xian,

Thanks for your review and comments. Inline for responses.

From: "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>
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 @ https://github.com/ietf-mpls-yang/te


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:

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

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

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

Regards,
Tarek

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

Regards,
Xian