Re: [Detnet-dp-dt] detnet LSPs and PWs

[Stewart Bryant <[e-mail]>]

On 15/02/2017 05:50, Loa Andersson wrote:
> Jouni,
>
> inline pl.ease
>
>
> On 2017-02-15 13:00, Jouni Korhonen wrote:
>> Loa,
>>
>>> On 14 Feb 2017, at 20:45, Loa Andersson <[e-mail]> wrote:
>>>
>>> Folks,
>>>
>>> Actually I think (except for the nomenclature, which I think we should
>>> adopt) of what Stewart says is there in the new slides.
>>>
>>> There are a few "if" that I don't agree to a design (maybe it may be
>>> possible to collapse the design), e.g. assuming one single domain.
>>>
>>> I think there are some design decision that need to be there.
>>>
>>> - replication and elimination of packets at places/nodes that the
>>>  operator can control, i.e. not every node should do it
>>
>> It was never assumed every node would do it - or even ever S-PE on path.
>
> True, but we have spelled it out, and if this is a data plane 
> decision, how do you prevent a node capable of doing it to do it?

It would be a property of the PW at the x-PE.

There is no PW that can do replication at the moment. We abandoned 
P-MP-MS PWs as not having a use case, and as I remember P-MP-SS-PWs rely 
on the underlay to do the replication.

>>
>>
>>> - with an "S-detnet-PE" in the path (for replication/elimination) we
>>>  need three levels of labels. The implication is that if we don't do
>>>  replication/elimination other than at the T-detnet-PWs then we only
>>>  need two layers.
>>
>> Could you elaborate more..
>
> which part? the egress "T-detnet-PE" will know by the label where the
> packet came from
> T-label says it came from the immediate neighbor
> L-label says it came from its S-detnet-PE neighbor
> d-pw label says it came from the T-detnet-PE peer

I guess the reason you need this is because you do not want to use a PW 
group.

You need to think about whether it is better to include and process more 
labels
or to design a PW group, where several labels refer to different paths 
for the
same PW.

As I said earlier, PWs are connections, so given the PW you can identify
the origin.

>
>
>>
>>> - what we called "d-pw" is not a new pw, but a pw from the PWE3/PALS
>>>  inventory
>>
>> Ok.
>>
>>> Now that last bullet is a problem, the sequence number is 16 bits in
>>> PWE3/PALS and we know that is to small. Maybe we have to define a 
>>> detnet
>>> PW after all. A PW that carries sequence number + another PW.
>>
>> Erm why? One can define a new control word. The merge + replication + 
>> elimination alone done on PW instance is big enough change to add 
>> other tweaks there, like bigger seqnums.
>>
> I think we need to discuss this, I'm not sure we can change the control
> word in an existing PW, or if we want to do that it will have
> implications outside detnet.

So is your assumption that the T-PEs are unchangable? If not it is 
better to design a new PW with the exact properties you need. At the 
moment I cannot see how you could use an unmodified T-PE.

Also how many base types do you expect to need?

>
>>> I've been  thinking hard about the equivalence relationship, but is 
>>> still not sure it will work in the generic case, equivalence
>>> relationship tells node D that it should treat L1 from B and L2 from C
>>> the same, which is fine, but it does still not tell us that the packet
>>> came from A originally.
>>>
>>> BTW - I think we need some type of sign-off from Stewart/Andy before we
>>> commit to hard.
>>>
>>> Also the problem of comparing sequence numbers arriving over
>>> different physical interface seems to be a eal problem.
>>
>> I do not see this as an issue if separate port are attached to e.g., 
>> same switch soc.  How separate physical ports end up to the same PW 
>> instance is an implementation issue. There are non-trivial issues if 
>> the separate physical ports are in different blades or say in 
>> different switch socs.
>>
> So you are saying, it is sometimes a problem, sometimes not?

*IF* you can channel the PW through the same processor, and that has 
fast enough access to the s/n registry, then this works, but it does so 
at a cost of scaling and reliability.

The n/w operators will not be happy with this, and we probably need OAM 
to verify it is happening, but if the core facing egress T-PE ports that 
service the LSP set that service a particular set of PWs all go through 
the same forwarder, then it can be made to work. However this is at a 
cost of availability, generality, scaling and opex.

If that meets you requirements, I am happy, I am just doing due 
diligence here.

- Stewart

>
> /Loa
>> - Jouni
>>
>>>
>>> /Loa
>>>
>>> On 2017-02-13 18:55, Stewart Bryant wrote:
>>>> Hi,
>>>>
>>>> I was given some background information on your thoughts on detnet-PW,
>>>> and pass on my thoughts in response.
>>>>
>>>> I think NSP issue  is a red herring. NSP can be NULL.
>>>>
>>>> An S-PE does no NSP, although in any case I suspect that you may need
>>>> some processing function at the detnet-S-PE - see below.
>>>>
>>>> The underlying DETNET PW is an SS-PW in the diagram I was shown, in 
>>>> that
>>>> the PW label is the same end to end, although of course it need not 
>>>> be,
>>>> you could have an equivalence label set and run pure MS-PW. Indeed 
>>>> when
>>>> you have multiple administrations you would like them to be different
>>>> for administrative purposes (that is why we designed MS-PW like that).
>>>>
>>>> So if you create an equivalence relationship in the egress-PE, i.e. 
>>>> two
>>>> entries in the global label table pointing to the same duplicate
>>>> suppressor (sequencer), then you could use regular MS-PW for this.
>>>>
>>>> If the S-PEs are in the same administrative domain in both ingress and
>>>> egress, you can also use a single label value on egress and on egress
>>>> since you can give them the same label mappings, i.e. they have
>>>> identical swap instructions programmed into the L-FIB.
>>>>
>>>> We don't have NSP at the S-PE's in the current PW architecture, in the
>>>> data-plane it is essentially a simple MPLS LSR, swapping PW labels and
>>>> forwarding the packet on a new LSP. What you will almost certainly 
>>>> want
>>>> to do is to have the ability to replicate at nodes at the S-PEs, and
>>>> that is new functionality.
>>>>
>>>> An approach I would look at is as follows:
>>>>
>>>> Create a new detnet-T-PE. On ingress this adds the sequence number,
>>>> replicates and adds the PW label, which as I said above MAY be next 
>>>> hop
>>>> detnet-S-PE dependent. Then it delivers the copies to the detnet-S-PEs
>>>> over the LSPs. Now if you have an ECMP path between the detnet-T-PE 
>>>> and
>>>> a detnet-S-PE, or you have SR or RSVP-TE available you can also 
>>>> deliver
>>>> multiple copies to the detnet-S-PE and take advantage of the 
>>>> variability
>>>> of transit time in the MPLS underlay.
>>>>
>>>> Now you create a new detnet-S-PE that operates as follows. On it's
>>>> ingress side it looks for the first packet at a given sequence 
>>>> number on
>>>> this PW (or PW set) and suppresses all future packets on that sequence
>>>> number on that PW or PW-set. It then replicates the packet if 
>>>> required,
>>>> swaps the PW label (note that it may also use multiple outgoing 
>>>> labels)
>>>> and send the packet over the egress LSP set.
>>>>
>>>> At the egress T-PE it looks at the sequence number on this PW (or
>>>> PW-set), trims all duplicates, applies any required egress processing
>>>> and send the packet on it's way.
>>>>
>>>> In summary on ingress a detnet-T-PE replicates to multiple S-PEs using
>>>> the PW label the detnet-S-PE expects and potentially sends the packet
>>>> over multiple paths to the detnet-S-PEs. At egress a detnet-T-PE looks
>>>> at the sequence numbers across the detnet-PW set and selects the first
>>>> of the sequence number suppressing all others, and sends the 
>>>> underlying
>>>> packet on its way. A detnet-S-PE is a back to back detnet-egress-T-PE
>>>> and a detnet-ingress-T-PE with a PW label swap in the middle and no
>>>> other PW processing.
>>>>
>>>> Now for the elephant in the corner of all of the schemes I have 
>>>> seen. If
>>>> you have multiple paths to an X-PE, packets will likely arrive on
>>>> different line cards. Sequence number co-ordination amongst different
>>>> line cards, and at high speed even amongst different ports on the same
>>>> line card is a hard problem. Indeed depending on the pipeline 
>>>> design on
>>>> the line card, ANY sequence number processing can be hard. You could
>>>> mitigate this (at the cost of availability) by requiring a common
>>>> ingress port at any detnet X-PE. This would normally require an 
>>>> RSVP-TE
>>>> or SR underlay.
>>>>
>>>> - Stewart
>>>>
>>>>
>>>>
>>>> On 13/02/2017 04:11, Andrew G. Malis wrote:
>>>>> Loa et al,
>>>>>
>>>>> To be clear, there’s currently no definition of PWs encapsulated in
>>>>> PWs, and while it might be conceptually possible, such as an Ethernet
>>>>> PW carried within a SONET/SDH PW, I couldn’t imagine a use case for
>>>>> doing it as it’s very inefficient, and I asked Loa if he had one. And
>>>>> if you were to do so, each PW in the hierarchy would need NSP
>>>>> functionality and real or emulated CE access circuits at the
>>>>> endpoints. Also, thinking about it some more, you couldn’t have both
>>>>> PWs in the same label stack, since a PW emulates a physical circuit.
>>>>> So there would need to be a separate label stack (and MPLS LSP) 
>>>>> inside
>>>>> the emulated circuit for the outer PW. By definition, PW labels
>>>>> terminate a label stack.
>>>>>
>>>>> As I haven’t been following Detnet at all, I don’t have the context
>>>>> for what you’re trying to accomplish. That said, I’ll take a look at
>>>>> the slides and let you know if I have any comments.
>>>>>
>>>>> Cheers,
>>>>> Andy
>>>>>
>>>>>
>>>>> On Sun, Feb 12, 2017 at 8:31 PM, Loa Andersson <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>    Folks,
>>>>>
>>>>>    The mail from Yuanlong mmade me go back and check the PW
>>>>>    architecture and consult with Andy Malis and Stewart Bryant. So I
>>>>>    have one more thing
>>>>>    that we should discuss on "Tuesday".
>>>>>
>>>>>    What Yaunlong said was: "IMHO, multiple layers of PW is a break 
>>>>> from
>>>>>    the PWE3 architecture, and all DP/CP/MP things will become more
>>>>>    complicated."
>>>>>
>>>>>    It is correct that multi-layer pw's is problematic, though Andy 
>>>>> said
>>>>>    that "if you have a good use case, you can do it".
>>>>>
>>>>>    The problem is that there is a native service processing (NSP) at
>>>>>    the end of the PW. Multi-layer PWs will only do NSP at one level.
>>>>>    I think
>>>>>    we should replace the MS-PW with an LSP. I've added one slide 
>>>>> (9) and
>>>>>    change slide 8,9 and 11 in the earlier package. The other 
>>>>> slides arere
>>>>>    for reference
>>>>>
>>>>>    I want Andy and Stewart to have a chance to review this prior 
>>>>> to that
>>>>>    we commit too hard to it. Copied them.
>>>>>
>>>>>
>>>>>    /Loa
>>>>>    --
>>>>>
>>>>>
>>>>>    Loa Andersson                        email: [e-mail]
>>>>>    <mailto:[e-mail]>
>>>>>    Senior MPLS Expert                          [e-mail]
>>>>>    <mailto:[e-mail]>
>>>>>    Huawei Technologies (consultant)     phone: [phone]
>>>>>    <tel:%2B46%20739%2081%2021%2064>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Detnet-dp-dt mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>
>>>
>>> -- 
>>>
>>>
>>> Loa Andersson                        email: [e-mail]
>>> Senior MPLS Expert                          [e-mail]
>>> Huawei Technologies (consultant)     phone: [phone]
>>>
>>> _______________________________________________
>>> Detnet-dp-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>
>