Subject: [Pce] draft-dugeon-brpc-stateful

From: Huaimo Chen <[email-masked]>
Date: Sat, 10 Jun 2017 01:57:26 +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

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 23 Jun 2017 18:40:10 +0200

Hi Huaimo,

Please find below some answers to your questions.

Best Regards

Olivier & Julien

> local LSP segments using the label and interface

We are also aware of draft-sivabalan-pce-binding-label-sid-02.txt that
proposed an interaction between PCE and PCC to exchange a binding label.
Even if the first use case of this draft is Segment Routing, this
Binding Label approach could also be used to stitch tunnels in our approach.

> Or generalize the definition of the term without

Yes. It is generalized in order to include Segment Routing paths that
cross several ASs, or a mix of SR-ASes and RSVP-ASes.
But, we could improve the text by explicitly referring to "Contiguous
RSVP-TE tunnels or Segment Paths" for instance, put the phrase isn't
smooth to read.

> replaced by some extensions of PCE in this case.

This statement correspond to the standard way RSVP-TE could be used to
stitch two tunnels as mention in RFC5150 and RFC5151.
But, as mention in our draft, these RFCs are not deployed in operational
networks, which is our primary motivation to propose this new draft
based on PCEP.

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

Good catch. It has been hard to find the proper notation. Your proposal
may be better, we'll think about it.

> LSP tunnels crossing multiple IGP areas.
[...]

Well, we take in consideration only inter-AS because the inter-area case
is already correctly addressed by the PCE architecture without a
boundary as strict as between ASes.
As a single administrative domain, a multi-area network could be handle
by a single PCE. In addition, because all routers are managed by the
same administrative entity, there is no problem to stitch/nest tunnels
by means of RSVP-TE as per RFC5151. So, even if your proposal to
generalize the approach is conceptually good, we think that it is not so
relevant in multi-areas, as opposed to multi-AS.

> One possible way to extend RSVP-TE is as follows:
[ ... ]

Our proposal avoids any modification to RSVP-TE signalling. All RSVP-TE
messages and TLVs needed for our proposal are already standardized. As
per RFC 3473, the ERO can already carry labels in a standard way, there
is no need for more extensions.