Hi WG,

During the IETF-95, I discussed this open point in PCEP-SR draft with Jeff
and Jon and also pointed out that the generic TE-Yang is using 5 tuple as a
key in LSP-state information.

https://tools.ietf.org/html/draft-ietf-teas-yang-te-03#section-3.4

   module: ietf-te
      +--rw te!
         +--ro lsps-state
         |  +--ro lsp*
         [source destination tunnel-id lsp-id extended-tunnel-id type]
         |     +--ro source                    inet:ip-address
         |     +--ro destination               inet:ip-address
         |     +--ro tunnel-id                 uint16
         |     +--ro lsp-id                    uint16
         |     +--ro extended-tunnel-id        inet:ip-address
         |     +--ro type                      identityref


​​

​     ​
​....t
he RSVP-TE [RFC3209 <https://tools.ietf.org/html/rfc3209>] YANG model
augmentation of the TE
   model is covered in [I-D.ietf-teas-yang-rsvp
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-03#ref-I-D.ietf-teas-yang-rsvp>],
and other signaling

   protocol model(s) (e.g. for Segment-Routing TE) are expected to also
   augment the TE generic model.


​I could see benefit in having this information for SR-TE LSP (and have an
LSP Identifier TLV) in PCEP messages.


What does the authors of the drafts (SR, Yang..) and the WG think about it?

Regards,
Dhruv

On Fri, Feb 12, 2016 at 11:14 AM, Dhruv Dhody <dhruv.dh...@huawei.com>
wrote:

> Hi Jeff,
>
>
>
> [PCEP-SR] did not change the format of the stateful PCE messages (i.e.
> RBNF of PCRpt/PCUpd); and [STATEFUL-PCE] does not have END-POINTS object in
> those messages.
>
> Only PCInitiate message [PCE-INITIATE] has END-POINTS object.
>
>
>
> In the implementations I am aware of, LSP Identifiers TLV is carried in
> PCEP-SR.
>
> One way to find middle ground would be, to make LSP Identifiers TLV as
> optional for PCEP-SR, with a use-case during delegation of a PCC configured
> LSP via PCRpt message.
>
>
>
> Regards,
>
> Dhruv
>
> [PCEP-SR]
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-06.txt
>
> [STATEFUL-PCE] https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13
>
> [PCE-INITIATE]
> https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05
>
>
>
>
>
>
>
> *From:* Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
> *Sent:* 12 February 2016 06:42
> *To:* Robert Varga; Dhruv Dhody; draft-ietf-pce-segment-rout...@ietf.org;
> draft-ietf-pce-stateful-...@tools.ietf.org
> *Cc:* pce@ietf.org; pce-cha...@tools.ietf.org
>
> *Subject:* Re: [Pce] Query on Usage of LSP Identifier TLV in SR
>
>
>
> Hi Robert,
>
>
>
> I disagree with you, I don’t think we need RSVP-TE semantics here, in the
> implementations I'm aware of LSP Identifiers TLV is not used.
>
> END-POINTS object is used to identify the tunnel endpoint addresses.
>
>
>
> I do agree that SR draft should be clear about this and we will update it.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *Robert Varga <n...@hq.sk>
> *Date: *Thursday, October 22, 2015 at 04:29
> *To: *Dhruv Dhody <dhruv.dh...@huawei.com>, "
> draft-ietf-pce-segment-rout...@ietf.org" <
> draft-ietf-pce-segment-rout...@ietf.org>, "
> draft-ietf-pce-stateful-...@tools.ietf.org" <
> draft-ietf-pce-stateful-...@tools.ietf.org>
> *Cc: *"pce@ietf.org" <pce@ietf.org>, "pce-cha...@tools.ietf.org" <
> pce-cha...@tools.ietf.org>
> *Subject: *Re: [Pce] Query on Usage of LSP Identifier TLV in SR
>
>
>
> On 10/12/2015 07:58 AM, Dhruv Dhody wrote:
>
> Hi Authors,
>
>
>
> In the stateful PCE draft [1], it says –
>
> The LSP Identifiers TLV MUST be included in the LSP object in PCRpt
>
> messages for RSVP-signaled LSPs.
>
>
>
> The SR draft [2] did not mention anything about LSP Identifier TLV.
>
> And in implementations that I am aware of, SR-TE LSP still uses the
> LSP-Identifier TLV. Is that correct? (I personally think so!!)
>
>
>
> If yes, do you think there is a need to update –
>
> -      [1] to say all LSPs (and not just RSVP-signaled).
>
> -      Or [2] to say that LSP-Identifier TLV are also applicable to SR
> and MUST be included.
>
>
>
>
> The wording in stateful draft is meant to proscribe behavior for RSVP (as
> that is what RFC5440 assumes), while allowing different setup mechanisms (
> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify
> their own LSP identifier format.
>
> In this spirit I think the SR draft should be updated to explicitly state
> that SR reuses the same identifier format as RSVP (or whatever is
> appropriate).
>
> Bye,
> Robert
>
>
>
>
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
>
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
>
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
>
> 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!
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to