Re: [Detnet-dp-dt] PW-type discussion - Re: new versions of my slides

[Balázs Varga A <[e-mail]>]

Hi,

> So what you are saying is that if we want to transport Ethernet, TDM, FR, 
> ATM,etc. over DetNet, then we need a specific PW in each case?

Not really. What I am saying is that x-PE nodes have to know whether a PW 
needs DetNet treatment or not. That can be done with an additional "flag"
and does not necessarily require a specific PW-type in each case.

An x-PE node dealing with both traditional-PWs and DetNet-PWs has to be 
able to distinguish them for further processing (e.g., sending a packet to a 
DetNet functions like FRER or not). 
- S-PE nodes do not care what is encapsulated in a detnet-PW, as the 
flow-ID and the seq.num is encoded in the label stack. 
- T-PE nodes have to know how to encapsulate Eth/TDM/etc. plus 
whether a DetNet functions is needed or not.

Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Loa Andersson
Sent: Monday, February 27, 2017 12:54 PM
To: [e-mail]
Subject: [Detnet-dp-dt] PW-type discussion - Re: new versions of my slides



On 2017-02-27 18:55, Balázs Varga A wrote:
> Hi,
>

<snip>

> - PW-type: as a detnet-PW requires special handling on x-PE nodes, I 
> am afraid that we need a new PW-type, in order to distinguish it from a traditional PW.

So what you are saying is that if we want to transport Ethernet, TDM, FR, ATM,etc. over DetNet, then we need a specific PW in each case?

/Loa
>
> Cheers
> Bala'zs
>
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of 
> Loa Andersson
> Sent: Monday, February 27, 2017 5:43 AM
> To: [e-mail]
> Subject: Re: [Detnet-dp-dt] new versions of my slides
>
> Norm,
>
>
> On 2017-02-27 06:44, Norman Finn wrote:
>> Sorry!!  Attachment here.
>>
>> -- Norm
>> ________________________________________
>> From: Norman Finn
>> Sent: Sunday, February 26, 2017 2:42 PM
>> To: Loa Andersson; [e-mail]
>> Subject: RE: [Detnet-dp-dt] new versions of my slides
>>
>> Loa,
>>
>> Slides 2, 4, 7, and 9 (the diagrams) had lots of very minor typos.  I made all fo the labels consistent in the attached version.
>>
>> Slide 3: "Consider the replicated packet that reaches B  from E and 8,"  I think you meant, "E and 6".
>
> right!
>>
>> Slide 5: 2nd sub-bullet.  "LB-3 because it is an L-level label taking the packet from F to E".  I think you meant, "A to E"?
>
> The devil is in the details -  the syntax was intended to put the destination node after the "L" (type of label) so what ( should have said "LB-3 because it is an L-level label taking the packet from A to B"
> the number after the "LB" indicates that there are more than one L-level label taking packets to B.
>
>>
>> One question:
>>
>>  Who guarantees d-id1 != d-id2?  Maybe I missed it, but I don't see that in the discussions in the slides.
>
> Well I said: "config of a DetNet ID (only shown for A and F, in real life all nodes that will serve as ingress T-DetNet-Pes will need the DetNet ID)."
>
> my take is that we will need to configure the d-id
>
>>
>> Answering your questions:
>>
>> Q: Do we agree that this works even if is not optimal.
>>
>>    Yes, if d-id1 != d-id2.
>
> see above
>>
>> Q: Do we want to eliminate any of the control plane alternatives.
>>
>>    I don't.
>
> ok - if that is the general agreement, than I think we need the d-id
>>
>> Q: By using the L-labels as containers for QoS and BW, neither T-Labels or PW-lables can do that, is it clear that we need L-Labels?
>
> I won't argue that realty need the L-labels, but getting rid of them means that we lose the way to distinguish between L-level LSPs that needs to go through replication and elimination, I guess that we could tie that to the d-pw label, but my take is that it will incease the amount of processing that needs to be done on the d-pw level.
>>
>> As far as the data plane is concerned, I think we need either the L-labels or the d-id labels, but not both.
>
> There I'm just now (allowing for existing control planes) I think that we need the d-id, and that L-labels are open for debate.
>
> I think the L-labels gives some bells and whistles that are nice and maybe even efficient to have! But I can let me be convinced that they are not "needed"!
>
>   (Although, without the d-id labels, you have to know that LB-3 + 
> d-pw1 is the same flow as LB-4 + d-pw1, so perhaps it's easier to do 
> without the L-labels.)
>
> I agree to that.
>
> Either label could be used for QoS.
>
> Well I think that all labels will have QoS (one or the other TC). I 
> was talking about QoS-containers. You put all the same QoS packet in 
> the same LSP. This is often used to simplify the LIBs in the nodes 
> that only swap. If TC 001 is a superset of 010 you can put both 
> packets TC-marked
> 001 and 010 in the same L-LSP. The packets marked 010 will get a little better treatment than what is indicated by the marking.
>
> You can also use L-labels as BW containers. You instantiate the L-LSP with the amount of BW you allocate to DetNet traffic, and then you have BW associated with each pw-label, as you establish the PWs and place them into the L-LSPs you have a book keeping to make sure that the BW for the L-LSP is not exceeded.
>
> Combining QoS- and BW-containers you can make sure that ample BW is allocated to each TC.
>>
>> But, perhaps we have an issue when creating d-pw labels and/or d-id labels.  The PW creation exchange operates over a tunnel, right?  We have a complex tunnel, not a point-to-point tunnel.  How does the PW creation exchange know what path to follow?  Over what path are the d-id labels created?  In other words, how are the L-labels stitched together?  Equivalently, how are the d-id labels distributed over the paths.
>>
> For LDP that is how LDP works, for a God Box there shouldn't be a problem.
>
> In our figure for LDP A will ask B for a L-label to use for D, B will turn downstream and ask D for the label, when B gets the response from D, it will put that label into the LIB, allocate the label for A, and usew the label for A as incoming label and the label for D as the outgoing label.
>
> If you remove the L-labels you will have to use the T-labels to do this.
> the d-pw label can't be used since it needs to be end-2-end.
>> Q: We talk about "detnet pseudo wire", is that a new type of pseudo wire?
>>
>> I wouldn't call it anything different.
>
> I think this needs to be done, since there is some unique DetNet processing. Potentially we would have to change all existing PWs. Andy talked a bit about this earlier.
>>
>> Q: How do we handle the already existing pseudo wires?
>>
>> Same as always.
> The existing PWs does not have DetNet processing, all of them does not (at least not normally) have sequence numbers.
>
> Again, I think the key is defining how you negotiate the path that the branched pseudowire follows.  In my opinion, (subject to finding a counter example that screws everything up), you nail down the paths, either with L-labels or d-id labels, and each d-pw creation (or perhaps first use) creates an instance of the packet discard machine at each combination point.  But, I'm not sufficiently versed in the label protocols to offer an opinion of how that happens.
>>
>
> hmmmm - we will have to create a new TLV for the protocols that are used
>   to branch, replicate and eliminate. When a node gets a Label Requst with that TLV it will understand that branching is needed and set up two disjunct L-LSPs from itself to the destination.
>
> /Loa
>
>> -- Norm
>>
>> ________________________________________
>> From: Detnet-dp-dt [[e-mail]] on behalf of Loa 
>> Andersson [[e-mail]]
>> Sent: Sunday, February 26, 2017 2:34 AM
>> To: [e-mail]
>> Subject: [Detnet-dp-dt] new versions of my slides
>>
>> Folks,
>>
>> I gone over my slides and tighten them up a bit.
>>
>> I think it is time that we start agree on some of the design 
>> decisions we are making and start taking them as the basis for what 
>> we are doing next.
>>
>> Slides should be self-explaining, but you can jump slide 3 and get 
>> back to it in the end.
>>
>> /Loa
>> --
>>
>>
>> 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
>>
>

-- 


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