Subject: Re: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls

From: <[email-masked]>
Date: Thu, 13 Feb 2014 17:01:43 +0100

Hi Nobo and both draft Authors,

Thanks for pointing this draft as reference also, I agree that solution need to be consistent.

Some inline comments as well as added comments on draft-ravisingh-mpls-el-for-seamless-mpls :

·         Section 5.2.2.1 :

        b. Notional ingress behavior:
           When L1 does not intrinsically support ELC and L2 does, then the
           stitching point router must POP the incoming label, insert
           (ELI+EL) before PUSHing the label for the LSP segment L2.

           The label operations performed would be:
            POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel),
                        or
            SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel)

                The issue I see here, is that the stitching point acting as notional ingress need to perform Deep Packet Inspection in order to compute EL value, but it has no knowledge of what is transported and moreover due to usage of hierarchy the payload may be quite far ... IMHO, it may not be a good idea to let a router not having the flow context computing an EL value otherwise we are loosing some of the EL  value added ... (Ingress that have the flow context computing a good hash). Did I miss something ?

For stitching , I would propose to keep consistent ELC across LSPs and otherwise break ELC (if some segments are not ELC) and in order to manage non ELC domains/areas, I would encourage to use tunneling technics (so EL would be safe) and not stitching ...

Example :

A ------ (S1) ----- B ----- (S2) ------ C ----- (S3) ----- D

Consider S1,S2,S3 as LSPs being stiched , B does stitching between S1 and D2 and C between S2 and S3.
if :

-          D is ELC for S3

-          C is ELC for S3 and S2

-          B is ELC for S2 BUT NOT for S1

-          A is not ELC for S1

Only A has knowledge of the flow context and can perform a good hashing . If S1 is not ELC, I would propose to not use ELI/EL on the all stitched path to D.
But if A may be ELC2 for segment type of S2, we could imagine to start S2 on A rather than B and tunnel S2 over S1, so A would be able to use ELI/EL.

Stephane

De : Nobo Akiya (nobo) [mailto:[email-masked]]
Envoyé : lundi 3 février 2014 16:44
À : LITKOWSKI Stephane DTF/DERX; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

Taking the example from draft-ravisingh-mpls-el-for-seamless-mpls ...

                S1                  D1
                  \    ---------    /
                   A===B===C===D===E
                  /    ---------    \
                S2                  D2

   In the above topology, let there be the following LSPs:

        L1: B->D
        L2: A->E, tunneled through LSP L1
        L3: S1->D1, tunneled through LSP L2
        L4: S2->D2, tunneled through LSP L2

Let's say:

(1)    S1 does not push ELI/EL.

(2)    A pushes ELI/EL.

(3)    B does not push ELI/EL, since label stack already contains ELI/EL.

Behavior so far aligns with 5.3.2 of draft-ravisingh-mpls-el-for-seamless-mpls (snippet above). Ideally what should happen is:

(4)    D pops ELI/EL, and pushes (or carries over) ELI/EL below exposed top label.
[SLI] Why D pops ELI/EL ? ELI/EL was pushed by A and D is egress of tunnel from B, so when D receives traffic originally sent by S1, D would pop tunnel label from C (end of L1), and switch tunnel L2 label to E, and only E would see the ELI/EL

(5)    E pops ELI/EL, and _does not_ push ELI/EL below exposed top label.
[SLI] Right

(6)    D1 receives data without any ELI/EL (as expected).

How does nodes D and E determine the right behavior?
[SLI] I don't see what's the issue there ... If A pushed ELI, E has signalled that it was ELC, so E is prepared to receive a packet with ELI/EL.

>From what I've read in the two drafts, I don't see how this behavior is determined.

If we can address this issue, I think solution is applicable to Segment Routing label stack with ELI/EL, meaning behavior can apply to solution 3.3 of draft-kini-mpls-entropy-label-src-stacked-tunnels.

One possibility is to make use of TC or TTL of EL to keep track of carry-over number. Meaning:

When ELI/EL is not inserted in a new tunnel because ELI/EL exists in the label stack, then:

-          Increment carry-over number.

-          Move ELI/EL to below top label.
[SLI] You can do it only if the new tunnel endpoint is ELC otherwise the router should not do it.

When data terminates a tunnel, then:

-          Decrement carry-over number.

-          If (carry-over != 0) re-insert ELI/EL to below exposed top label.

I'm no hardware expert either, and not sure if something like above can be implemented. But if possible, then ELI/EL pushed in SR network can pre-set carry-over number to certain value to ensure it is carried over below top label all the way though, and there is only one ELI/EL at any given time.

All this to say, I think there's a benefit in discussing this topic further, with both drafts in mind.

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, January 31, 2014 9:12 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels

Hi Authors,

I would like to know if you are progressing on this draft ?
Entropy label support for stacked tunnels would be mandatory for us, so I would like to support the work on this topic to have a working solution as soon as possible.

Regarding the solutions you are proposing in the current version, there is none perfect one, and unfortunately all have drawbacks.
The compatibility (on LSR) with current generation of hardwares may be "good" (mandatory ?) for the target solution.

In your document , solution §3.3 "re-usable EL for a stack of tunnels" sounds for me to be the best base idea. I'm just wondering what would be the hardware impact of doing the reinsertion of ELI at tunnel end . Could this be done in one pass ? (IMHO, this may be possible, as today we are able to pop or swap + push FRR headers) As you are three different vendors as co-author, did you already evaluate such impact on your hardwares ? (I'm not expecting details on the mailing list, but I would be interested by details unicast to me and just yes/no on the the list)

To be exhaustive in listing solutions, did you think about leaving the EL/ELI at top of the stack ? I think there is already a case where a special label may be kept at top of the stack (MPLS Router alert).
What would be needed :

-          each hop need to advertise is ability to process EL, if nexthop cannot process EL, it should be removed when forwarded to nexthop (there should be the same requirement for re-usable EL)
I don't think this is really different from re-usable EL in the concept :

-          reusable EL : process top level forwarding label, if popped and next label is EL, pop ELI/EL and next label L, push pack ELI/EL and then L (we need to swap positions between ELI/EL and L) if nexthop is able to process EL.

-          top level EL : process top level ELI, ELI is recognized, ELI/EL is removed, forwarding is done on forwarding label, ELI/EL is pushed back in nexthop is able to process EL.

In term of operations, I think that top level EL may be simpler , but as I'm not hardware coder, may be I'm wrong ... moreover it may be similar to MPLS Router alert processing.

Your thoughts ?

Stephane

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 14 Feb 2014 11:41:04 +0000

Hi Stephane, Authors, et al,

Please see in-line with [NOBO].

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:02 AM
To: Nobo Akiya (nobo); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls

[NOBO] Yeah, this is a very tricky topic and can benefit from more discussions.

·        Section 5.2.2.1 :

Example :

-        D is ELC for S3

-        C is ELC for S3 and S2

-        A is not ELC for S1

[NOBO] I agree that EL benefit is best achieved with what you described. Ultimately, I think things will depend on the intelligence at B. Is S2 only being used as a stitching LSP with S1? If yes, then it is possible to do no-op as far as ELI/EL imposition is concerned. If no, then B would need to determine if traffic came out from S1 or from elsewhere, in order to determine whether to take no-op approach or impose ELI/EL.

Stephane

                S1                  D1
                  \    ---------    /
                   A===B===C===D===E
                  /    ---------    \
                S2                  D2

        L1: B->D

Let's say:

(2)    A pushes ELI/EL.

[NOBO] Sorry, I sort of skipped few explanations. What I meant to say was that, if label stack of <x, ELI, EL, y> can get "popped" to <y, ELI, EL> (3.3 from draft-kini-mpls-entropy-label-src-stacked-tunnels), then two behaviors are possible.

1.      <x, ELI, EL, y> gets "popped" to <y, ELI, EL> - 3.3 from draft-kini-mpls-entropy-label-src-stacked-tunnels.

2.      <x, ELI, EL, y> gets "popped" to <y> - more traditional way.
What is ambiguous is, how does an LSR determine whether to apply (1) or (2). What I also meant to say was, if we are going to discuss behavior of (1), then similar push behavior of (1) should be discussed. Meaning, if LSP1 is tunneled over LSP2, then:

3.      <LSP1, ELI, EL> becomes <LSP2, ELI, EL, LSP1> - opposite of 3.3 from draft-kini-mpls-entropy-label-src-stacked-tunnels.

4.      <LSP1, ELI, EL> becomes< LSP2, LSP1, ELI, EL> - more traditional way.
Now applying the example from above:

a)      S1 does not push ELI/EL: label stack = <S1>

b)      A pushes ELI, EL: label stack = <A, ELI, EL, S1>

c)      B does not push ELI, EL, since label stack already contains ELI/EL but moves ELI/EL to below top label: label stack = <B, ELI, EL, A, S1>

d)      D pops B, ELI, EL and moves ELI/EL below exposed top label: label stack = <A, ELI, EL, S1>

e)      E pops A, ELI, EL and _somehow knows_ not to move ELI/EL to below top label: <S1>

f)       D1 receives data without any ELI/EL.

In this example, node D needs to know that it needs to apply behavior (1) and node E needs to know that it needs to apply behavior (2) ... but how!? There may be ways for node D/E to know ELC for further upstreams/downstreams, but ELC doesn't necessary mean ELI/EL is always pushed.

-Nobo

-Nobo

Hi Authors,

Your thoughts ?

Stephane

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 14:17:41 +0100

Hi,

[SLI] If all routers have been smart enough, IMHO there would have been no need for entropy label. Intelligence of LSR (for deep packet inspection) is implementation depend.

Stephane

De : Nobo Akiya (nobo) [mailto:[email-masked]]
Envoyé : vendredi 14 février 2014 12:41
À : LITKOWSKI Stephane DTF/DERX; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:02 AM
To: Nobo Akiya (nobo); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] draft-kini-mpls-entropy-label-src-stacked-tunnels & draft-ravisingh-mpls-el-for-seamless-mpls

·         Section 5.2.2.1 :

Example :

-          D is ELC for S3

-          C is ELC for S3 and S2

-          A is not ELC for S1

Stephane

                S1                  D1
                  \    ---------    /
                   A===B===C===D===E
                  /    ---------    \
                S2                  D2

        L1: B->D

Let's say:

(2)    A pushes ELI/EL.

-Nobo

-Nobo

Hi Authors,

Your thoughts ?

Stephane

Thank you.

Thank you.