Re: [Pce] New Version Notification for draft-ietf-pce-pcep-stateful-pce-gmpls-08.txt

[Leeyoung <[e-mail]>]

Hi,

I believe this update satisfies among others the comment made by Adrian on SRP B flag to indicate bidirectional LSP setup which was raised by Quan.

Comments will be welcome.

Thanks.
Young
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, February 26, 2018 10:36 AM
To: Zafar Ali <[e-mail]>; Oscar de Dios <[e-mail]>; Zhangfatai (Fatai Zhang) <[e-mail]>; Zhangxian (Xian) <[e-mail]>; Oscar Gonzalez de Dios <[e-mail]>; Leeyoung <[e-mail]>; Ramon Casellas <[e-mail]>
Subject: New Version Notification for draft-ietf-pce-pcep-stateful-pce-gmpls-08.txt


A new version of I-D, draft-ietf-pce-pcep-stateful-pce-gmpls-08.txt
has been successfully submitted by Young Lee and posted to the IETF repository.

Name:		draft-ietf-pce-pcep-stateful-pce-gmpls
Revision:	08
Title:		Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
Document date:	2018-02-26
Group:		pce
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-stateful-pce-gmpls-08.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/
Htmlized:       https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-08
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls-08
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-08

Abstract:
   The Path Computation Element (PCE) facilitates Traffic Engineering
   (TE) based path calculation in large, multi-domain, multi-region, or
   multi-layer networks. The PCE communication Protocol (PCEP) has been
   extended to support stateful PCE functions where the PCE retains
   information about the paths already present in the network, but
   those extensions are technology-agnostic. This memo provides
   extensions required for PCEP so as to enable the usage of a stateful
   PCE capability in GMPLS-controlled networks.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--- Begin Message ---

So, I think Quan is asking how to use a PCInitiate message to cause the creation of a "co-routed" bidirectional LSP that is achieved in the signaling plane by a single Path/Resv exchange.

That is *G*MPLS function, but an answer would still be useful.

Now, on a PCReq you need the B-bit to tell the PCE to compute a bidirectional path. But what you should be looking at is the PCRep message. That is, how does the PCE indicate that a bidirectional path has been returned? And the answer is two points:

1. Since the requester asked for a bidirectional path, and since a path has been computed, the PCC has every right to assume that the path can be used for a bidirectional LSP.

2. The RP Object is present on the PCRep and also contains thee B-flag.

Now, note that the PCInitiate most closely follows the PCRep. That is, it flows from PCE to PCC and indicates the path of the LSP to be set up.

Now, the PCInitiate carries the SRP Object, not the RP Object (just like PCUpd message).

There is a flags field in the SRP Object, but the only bit defined is in 8281 for LSP removal.

So, to expand on Quan's question: how do we Update an LSP that was set up with the B-flag in the RP object, and how do we create an bidirectional LSP using PCInitiate message?

It is fine if the answer is "This is GMPLS function that possibly should not have been in 5440, and we need to look at some additional work for GMPLS extensions for 8231 and 8281."

draft-ietf-pce-pcep-stateful-pce-gmpls is a starting point and should, perhaps, define a B flag for the SRP on the PCUpd that would then also be available automatically on the PCInitiate.

Yours ramblingly,
Adrian




From: Pce [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 24 January 2018 09:21
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [Pce] 答复: Re: A question about RFC8281 PCE-initiated LSPs.

Hi Dhruv,


I agree PCInitiate message including the ASSOCIATION Object may create a new LSP.

But it still need to create bi-directional LSP by two messages.

In some scenario, like PTN, we need to establish a bi-directional LSP by one message of a PCE request.

In my opinion, this is the requirement to create a bi-directional LSP by a  PCInitiate message.


Thanks,
Quan



--------------------------------------------------------------------------------
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pce] A question about RFC8281 PCE-initiated LSPs.

--------------------------------------------------------------------------------

To: "xiong.quan at zte.com.cn" <xiong.quan at zte.com.cn>, "draft-barth-pce-association-bidir at ietf.org" <draft-barth-pce-association-bidir at ietf.org>
Subject: Re: [Pce] A question about RFC8281 PCE-initiated LSPs.
From: Dhruv Dhody <dhruv.dhody at huawei.com>
Date: Tue, 23 Jan 2018 11:21:15 +0000
Accept-language: en-GB, zh-CN, en-US
Archived-at: <https://mailarchive.ietf.org/arch/msg/pce/Vx2UV03boBu2HHvP4qWETgxHr90>
Cc: "edward.crabbe at gmail.com" <edward.crabbe at gmail.com>, "inaminei at google.com" <inaminei at google.com>, "msiva at cisco.com" <msiva at cisco.com>, "robert.varga at pantheon.tech" <robert.varga at pantheon.tech>, "pce at ietf.org" <pce at ietf.org>, "hu.fangwei at relay.zte.com.cn" <hu.fangwei at relay.zte.com.cn>, "julien.meuric at orange.com" <julien.meuric at orange.com>, "jonathan.hardwick at metaswitch.com" <jonathan.hardwick at metaswitch.com>
Delivered-to: pce at ietfa.amsl.com
In-reply-to: <[e-mail]>
List-archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-help: <mailto:[e-mail]?subject=help>
List-id: Path Computation Element <pce.ietf.org>
List-post: <mailto:[e-mail]>
List-subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:[e-mail]?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:[e-mail]?subject=unsubscribe>
References: <[e-mail]>
Thread-index: AQHTlB0CgKqVuxcwbkmqwLTk/0dyLaOBTApQ
Thread-topic: [Pce] A question about RFC8281 PCE-initiated LSPs.

--------------------------------------------------------------------------------
Hi Quan,



As per [1]:
       A PCE initiating a new LSP, can include the association group
   information.  This is done by including the ASSOCIATION Object in a

   PCInitiate message.



So when a new LSP is created by PCE, you could still indicate the association. The association is not limited to existing LSPs.



Hope this helps! Let me know if I understood your question correctly!



Regards,

Dhruv



[1] https://tools.ietf.org/html/draft-ietf-pce-association-group-04#section-5.2.1



From: xiong.quan at zte.com.cn [mailto:xiong.quan at zte.com.cn]
Sent: 23 January 2018 13:07
To: Dhruv Dhody <dhruv.dhody at huawei.com>; draft-barth-pce-association-bidir at ietf.org
Cc: edward.crabbe at gmail.com; inaminei at google.com; msiva at cisco.com; robert.varga at pantheon.tech; pce at ietf.org; hu.fangwei at relay.zte.com.cn; julien.meuric at orange.com; jonathan.hardwick at metaswitch.com
Subject: Re: [Pce] A question about RFC8281 PCE-initiated LSPs.



Hi Dhruv,


Thank you for the reply!O(∩_∩)O~

I agree two created PCE-initiated LSPs may be associated by ASSOCIATION object as discussed in draft-barth-pce-association-bidir.

But if there is no LSP existed, how to request a bi-directional TE LSP from PCE in PCE initiated operation?


Quan Xiong

--------------------------------------------------------------------------------
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pce] A question about RFC8281 PCE-initiated LSPs.

--------------------------------------------------------------------------------

To: "xiong.quan at zte.com.cn" <xiong.quan at zte.com.cn>, "edward.crabbe at gmail.com" <edward.crabbe at gmail.com>, "inaminei at google.com" <inaminei at google.com>, "msiva at cisco.com" <msiva at cisco.com>, "robert.varga at pantheon.tech" <robert.varga at pantheon.tech>
Subject: Re: [Pce] A question about RFC8281 PCE-initiated LSPs.
From: Dhruv Dhody <dhruv.dhody at huawei.com>
Date: Tue, 23 Jan 2018 03:28:27 +0000
Accept-language: en-GB, en-US
Archived-at: <https://mailarchive.ietf.org/arch/msg/pce/ryZRIHK4zGoqSAsxMFQetTWDjbY>
Cc: "hu.fangwei at relay.zte.com.cn" <hu.fangwei at relay.zte.com.cn>, "pce at ietf.org" <pce at ietf.org>, "draft-barth-pce-association-bidir at ietf.org" <draft-barth-pce-association-bidir at ietf.org>
Delivered-to: pce at ietfa.amsl.com
In-reply-to: <OF60BFF49D.2F7F81DC-ON48258217.0026FFA8-4825821E.000BA102 at zte.com.cn>
List-archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-help: <mailto:pce-request at ietf.org?subject=help>
List-id: Path Computation Element <pce.ietf.org>
List-post: <mailto:pce at ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request at ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request at ietf.org?subject=unsubscribe>
References: <OF60BFF49D.2F7F81DC-ON48258217.0026FFA8-4825821E.000BA102 at zte.com.cn>
Thread-index: AQHTk+76gKqVuxcwbkmqwLTk/0dyLaOAy0lA
Thread-topic: [Pce] A question about RFC8281 PCE-initiated LSPs.

--------------------------------------------------------------------------------
Hi Quan,



Check out -  https://datatracker.ietf.org/doc/draft-barth-pce-association-bidir/

Authors are in cc, if you need to have further discussion!



Thanks!

Dhruv



From: Pce [mailto:pce-bounces at ietf.org] On Behalf Of xiong.quan at zte.com.cn
Sent: 23 January 2018 07:37
To: edward.crabbe at gmail.com; inaminei at google.com; msiva at cisco.com; robert.varga at pantheon.tech
Cc: hu.fangwei at relay.zte.com.cn; pce at ietf.org
Subject: [Pce] A question about RFC8281 PCE-initiated LSPs.



Hi all,


I encountered a problem as following shown.O(∩_∩)O~

As defined in RFC5440,the PCC-initiated LSPs creation uses the B bit in RP object of PCReq message to indicate the direction of the TE LSP.
When set, the PCC requests a bi-directional TE LSP and when cleared, the TE LSP is unidirectional.

And in stateful PCE, RFC8281 proposed the PCE-initiated LSPs and the PCE could send a PCInitiate message to the PCC to request the creation of an LSP.
The PCInitiate message carry the Objects including SRP, LSP ,END-POINTS and ERO. But no B bit in SRP object.

How to configure the direction of the TE LSP in PCE-initiated operation?

Best Regards,

Quan Xiong





--------------------------------------------------------------------------------

References:
[Pce] A question about RFC8281 PCE-initiated LSPs.
From: xiong . quan
Prev by Date: Re: [Pce] Adoption Poll for draft-raghu-pce-lsp-control-request
Previous by thread: [Pce] A question about RFC8281 PCE-initiated LSPs.
Index(es):
Date
Thread
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.


--------------------------------------------------------------------------------

References:
Re: [Pce] A question about RFC8281 PCE-initiated LSPs.
From: xiong . quan
Prev by Date: Re: [Pce] A question about RFC8281 PCE-initiated LSPs.
Next by Date: [Pce] iPOP 2018 First CFP
Previous by thread: Re: [Pce] A question about RFC8281 PCE-initiated LSPs.
Next by thread: [Pce] iPOP 2018 First CFP
Index(es):
Date
Thread
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.

--- End Message ---