[Pce] draft-dugeon-brpc-stateful

Huaimo Chen <huaimo.chen@huawei.com> Sat, 10 June 2017 01:57 UTC

Return-Path: <huaimo.chen@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51D7126E64 for <pce@ietfa.amsl.com>; Fri, 9 Jun 2017 18:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8UOpUQdspMq for <pce@ietfa.amsl.com>; Fri, 9 Jun 2017 18:57:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550FC126CD6 for <pce@ietf.org>; Fri, 9 Jun 2017 18:57:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIF65050; Sat, 10 Jun 2017 01:57:34 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 10 Jun 2017 02:57:33 +0100
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML702-CHM.china.huawei.com ([169.254.4.117]) with mapi id 14.03.0235.001; Fri, 9 Jun 2017 18:57:27 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: "pce@ietf.org" <pce@ietf.org>, "olivier.dugeon@orange.com" <olivier.dugeon@orange.com>, "julien.meuric@orange.com" <julien.meuric@orange.com>
Thread-Topic: draft-dugeon-brpc-stateful
Thread-Index: AQHS4YzoLHFmyAAsJUSx+yQa+SS/mg==
Date: Sat, 10 Jun 2017 01:57:26 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D45017961C@SJCEML701-CHM.china.huawei.com>
References: <3c2491d4-6178-dbed-4f9a-a076e5f87f3a@orange.com> <aed43703-3d61-abe6-b117-52285916799a@orange.com>
In-Reply-To: <aed43703-3d61-abe6-b117-52285916799a@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: AtRo A81O G1K+ IWLr L1m1 OwDV PjbY UaGG Wn19 WtI9 Xlru Y5HE bvNy eYcB fITk fcUR; 3; agB1AGwAaQBlAG4ALgBtAGUAdQByAGkAYwBAAG8AcgBhAG4AZwBlAC4AYwBvAG0AOwBvAGwAaQB2AGkAZQByAC4AZAB1AGcAZQBvAG4AQABvAHIAYQBuAGcAZQAuAGMAbwBtADsAcABjAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A903074C-6B55-4E8A-901A-75DA3E9423B4}; aAB1AGEAaQBtAG8ALgBjAGgAZQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sat, 10 Jun 2017 01:52:45 GMT;ZAByAGEAZgB0AC0AZAB1AGcAZQBvAG4ALQBiAHIAcABjAC0AcwB0AGEAdABlAGYAdQBsAA==
x-cr-puzzleid: {A903074C-6B55-4E8A-901A-75DA3E9423B4}
x-originating-ip: [10.212.245.110]
Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D45017961CSJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.593B520F.00A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 293e44006300de8761f0a6caa6ad4c88
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/_OCit8MvbmQHZzwfxU6VeobQEA4>
Subject: [Pce] draft-dugeon-brpc-stateful
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jun 2017 01:57:41 -0000

Hi Olivier and Julien,



    Glad to have a small talk/discussion with Julian

after his presentation in the last IETF.



    I read through your draft and think it is useful.



    In 2013, I posted draft-chen-pce-label-x-domains,

https://datatracker.ietf.org/doc/draft-chen-pce-label-x-domains/

which proposes extensions to PCEP for distributing

a label with an interface from a downstream domain

to its upstream domain. This label and interface seem

similar to (or equivalent to) to the stitching label

and interface in your draft.



    In 2016, I submitted draft-chen-pce-h-sdns,

https://datatracker.ietf.org/doc/draft-chen-pce-h-sdns/

which comprises distribution of the label and interface

from a downstream domain to its upstream domain

and set up of an end to end LSP through "stitching"

local LSP segments using the label and interface

by PCE as controller.





    For your draft, I have the following comments.



    1) Term "Contiguous tunnels":

    In your draft, it seems that a "Contiguous tunnel" is

an end to end LSP tunnel crossing domains which is

signaled/created by RSVP-TE.

Should the term be revised to "Contiguous RSVP-TE tunnels"?

Or generalize the definition of the term without

RSVP-TE?



    2) Term "Stitching tunnels":

    In the definition of this term, there is a statement:

"a second end-to-end RSVP-TE Path message is sent by the

initiating domain to stitch the different tunnel parts

to form the end-to-end LSP tunnel."

Does this statement mean that RSVP-TE Path/RESV messages

are exchanged between border nodes in two adjacent domains?

If so, I think that the function of RSVP-TE may be

replaced by some extensions of PCE in this case.



    3) entry BN of domain(j) is called entry BN(j).

Since entry BN of domain(j) is ingress BN of domain(j),

it seems that BNi(j) is a more symbolized representation.



    4) Exit BN of domain(j) is called exit BN(j).

Since exit BN of domain(j) is egress BN of domain(j),

or a BN from which the traffic goes out of domain(j),

BNe(j) or BNo(j) seems a more symbolized representation.





    5) It seems that your draft talks about LSP tunnels

crossing multiple ASes and may not fit well for

LSP tunnels crossing multiple IGP areas.



    For example, in your draft,

the sticking label is an label from entry BN(j+1) and

the input interface is the interface from

exit BN(j) to entry BN(j+1).

That is that any stitching label is from an entry BN,

and any input interface associated with a stitching label

is an interface from an exit BN to an entry BN.

This may not fit for LSP tunnels crossing IGP areas.



    When an end to end LSP crossing two IGP (e.g., OSPF) areas

[e.g., upstream area as domain(j), downstream area as domain(j+1)]

connected by an ABR, this ABR is exit BN(j) and entry BN(j+1).

That is that "exit BN(j)" == "entry BN(j+1)".

In this case, there is not any interface from

"exit BN(j)" to "entry BN(j+1)";

there is not any stitching label from "entry BN(j+1)".



    The stitching label may be from the next hop of the ABR

(i.e., "exit BN(j)"); the input interface associated with

the stitching label is the interface from the ABR

(i.e., "exit BN(j)") to the next hop of the ABR.



    The stitching label and input interface used for

"connecting/stitching" two local LSP segments in your draft

should be generalized to cover an end to end LSP crossing

IGP areas.



    The following is a possible way for generalization,

which is from our drafts.



   The sticking label is an label from the next hop of exit BN(j)

and the input interface is the interface from

exit BN(j) to the next hop of BN(j).



    For an end to end LSP crossing two ASes,

the next hop of exit BN(j) is the entry BN(j+1).

The above generalization fits well for the LSP crossing ASes.



    For an end to end LSP crossing two areas,

the exit BN(j) is ABR; the stitching label is

an label from the next hop of ABR [i.e., exit BN(j)] and

the input interface is the interface from

ABR [i.e., exit BN(j)] to the next hop of ABR.

The above generalization fits well for the LSP crossing areas.





    6) It seems that we may need to extend RSVP-TE in some way.

One possible way to extend RSVP-TE is as follows:



    When it is requested to set up an LSP in a domain(j) from

an ingress border node BNi(j) to an egress border node BNe(j)

with stitching label SL and input/incoming interface if2

from BNe(j) to the next hop of BNe(j),

it allocates an incoming label IL on BNe(j) and writes

cross connect on BNe(j) using IL as incoming label and

SL as outgoing label, if2 as outgoing interface.



    On BNi(j), RSVP-TE allocates an incoming label as SL1,

gets the incoming interface if1 from the upstream node

such as BNe(j-1) to BNi(j) along the path.

It writes cross connect on BNi(j) using SL1 as incoming

label. SL1 and if1 will be sent to the upstream domain

for end to end LSP to cross the domain.



    The information needed for RSVP-TE includes:

BNe(j-1), ERO containing path from BNi(j) to BNe(j),

SL and if2



    There are a few cases as follows:



a) Destination AS (domain(n))

  Input that PCC on BNi(n) receives:

    BNe(n-1), ERO containing path from BNi(n) to destination D

  Action on PCC:

    Sets up local LSP tunnel from BNi(n) to D along the path.

    This may be done through using RSVP-TE.



    A label Lnhn from the next hop NHn of BNi(n) and

    the interface if2nhn from BNi(n) to NHn need to be obtained.



    Allocates an incoming label as SLn on BNi(n),

    gets the incoming interface if2n from BNe(n-1) to BNi(n)

    as input interface.



    Writes cross connect on BNi(n) using SLn as incoming label,

    if2n as incoming interface, and

    Lnhn as outgoing label, if2nhn as outgoing interface.



    Sends a message containing SLn and If2n,

    and status of the LSP tunnel segment creation in domain(n).



b) Intermediate AS (domain(j))

  Input that PCC on BNi(j) [1 < j and j < n] receives:

    BNe(j-1), ERO containing path from BNi(j) to BNe(j),

    where BNi(j) is the ingress and BNe(j) is the egress

    of the local LSP segment in domain(j);

    SLk and if2k, where k=j+1,

    SLk is the stitching label allocated on BNi(k),

    if2k is the input interface from BNe(j) to BNi(k).



  Action on PCC:

    Sets up local LSP tunnel segment from BNi(j) to BNe(j)

    along the path.

    In addition, the segment needs to be stitched to

    the LSP tunnel segment in domain(k) using

    label SLk and interface if2k on BNe(j).



    This may be done using RSVP-TE with some extensions.



    A label Lnhj from the next hop NHj of BNi(j) and

    the interface if2nhj from BNi(j) to NHj need to be obtained.



    Allocates an incoming label as SLj on BNi(j),

    gets the incoming interface if2j from BNe(j-1) to BNi(j).



    Writes cross connect on BNi(j) using SLj as incoming label,

    if2j as incoming interface, and

    Lnhj as outgoing label, if2nhj as outgoing interface.



    Sends a message containing SLj and If2j,

    and status of the LSP tunnel segment creation in domain(j).





c) Source AS (domain(1))

  Input that PCC on source S or BNi(1) receives:

    ERO containing path from BNi(1) to BNe(1),

    where BNi(1) is the ingress and BNe(1) is the egress

    of the local LSP tunnel segment in domain(1);

    SLk and if2k, where k=2,

    SLk is the stitching label allocated on BNi(2),

    if2k is the interface from BNe(1) to BNi(2).



  Action on PCC:

    Sets up local LSP tunnel segment from BNi(1) to BNe(1)

    along the path.

    In addition, the segment needs to be stitched to

    the LSP tunnel segment in domain(2) using

    label SLk and interface if2k on BNe(1).



    This may be done using RSVP-TE with some extensions.



    Sends status of the tunnel segment creation in domain(1).





d) Destination Area: domain(n)

  Input that PCC on BNi(n) receives:

    ERO containing path from BNi(n) to destination D

  Action on PCC:

    Sets up local LSP tunnel from BNi(n) to D along the path.

    This may be done through using RSVP-TE.



    A label Lnhn from the next hop NHn of BNi(n) and

    the interface if2nhn from BNi(n) to NHn need to be obtained.



    Sends a message containing Lnhn as SLn and if2nhn as If2n,

    and status of the LSP tunnel segment creation in domain(n).



e) Intermediate Area: domain(j)



  Input that PCC on BNi(j) [1 < j and j < n] receives:

    ERO containing path from BNi(j) to BNe(j),

    where BNi(j) is the ingress and BNe(j) is the egress

    of the LSP tunnel segment in domain(j);

    SLk and if2k, where k=j+1,

    SLk is the stitching label allocated on the next hop NHj of BNe(j),

    if2k is the interface from BNe(j) to NHj.



  Action on PCC:

    Sets up LSP tunnel segment from BNi(j) to BNe(j)

    along the path.

    In addition, the segment needs to be stitched to

    the LSP tunnel segment in domain(k) using

    label SLk and interface if2k on BNe(j).



    This may be done using RSVP-TE with some extensions.



    A label Lnhij from the next hop NHij of BNi(j) and

    the interface if2nhij from BNi(j) to NHij need to be obtained.



    Sends a message containing Lnhij as SLj and if2nhij as If2j,

    and status of the LSP tunnel segment creation in domain(j).



f) Source Area: domain(1)

  Input that PCC on source S or BNi(1) receives:

    ERO containing path from BNi(1) to BNe(1),

    where BNi(1) is the ingress and BNe(1) is the egress

    of the LSP tunnel segment in domain(1);

    SLk and if2k, where k=2,

    SLk is the stitching label allocated on the next hop NH1 of BNe(1),

    if2k is the interface from BNe(1) to NH1.



  Action on PCC:

    Sets up LSP tunnel segment from BNi(1) to BNe(1)

    along the path.

    In addition, the segment needs to be stitched to

    the LSP tunnel segment in domain(2) using

    label SLk and interface if2k on BNe(1).



    This may be done using RSVP-TE with some extensions.



    Sends status of the tunnel segment creation in domain(1).





Best Regards,

Huaimo