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

[Loa Andersson <[e-mail]>]

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]