[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
Stewart, Wim:
Currently, there is no requirement in signaling the LB label, combining
pid-label w/ LB-label, would require the egress PE to signal many labels
per PID type which can be very large due to large number of flows. Also
combining the two labels together would decrease the entropy for LB
space (although by how much would depend on the size of PID space).
Furthermore, adding this would create another option we need to worry
about for interoperability.
Cheers,
Ali
> -----Original Message-----
> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf
Of
> Stewart Bryant (stbryant)
> Sent: Thursday, November 19, 2009 5:27 AM
> To: HENDERICKX Wim
> Cc: pwe3 at ietf.org; Luca Martini (lmartini)
> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
>
> Our emails crossed
>
> I will add some text to make sure that this mode of operation is clear
> to everyone.
>
> - Stewart
>
>
>
> HENDERICKX Wim wrote:
> > Stewart, I am ok with this.
> >
> > -----Original Message-----
> > From: Stewart Bryant [mailto:stbryant at cisco.com]
> > Sent: donderdag 19 november 2009 12:46
> > To: HENDERICKX Wim
> > Cc: Luca Martini; pwe3 at ietf.org
> > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
> >
> > HENDERICKX Wim wrote:
> >
> >> Luca, for IP you are right in terms of protocol stack but I have
the
> >> impression that the packet-PW draft is more generic and we should
be
> >> open minded to other applications apart from IP.
> >>
> >> What I propose is to have 1. tunnel label - 2. pw label - 3. a
label
> >> which combines the pid label + CW + hash label.
> >>
> >>
> > The CW is optional anyway.
> >
> > We could combine the pid and the hash label if we allowed the egress
> PE
> > to signal multiple pid-label bindings using the proposed procedures,
> > though I have concerns as to how good the LB would be. Clearly the
> > choice of which mapping to use would be a local matter in the
ingress
> PE
> >
> > and the choice of how many mappings to provide would be a local
> matter
> > for the egress PE.
> >
> > - Stewart
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Luca Martini [mailto:lmartini at cisco.com]
> >> Sent: woensdag 18 november 2009 23:18
> >> To: HENDERICKX Wim
> >> Cc: stbryant at cisco.com; pwe3 at ietf.org
> >> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
> >>
> >> Wim,
> >>
> >> We can , of course , always reduce the label stack depth by merging
> >> labels, but that is usually not a good idea , as it will increase
> the
> >> number of labels, that that is the most expensive part of MPLS.
> >> Also note that The FAT PW would not be very useful with a packet PW
> >>
> > that
> >
> >> contains IP.
> >> Let assume for a moment that 99.9% of traffic in a packet PW will
be
> >>
> > IP
> >
> >> ... ( most likely it's much higher then that )
> >> I do not like the CW much , so let say that we simply encapsulate
> the
> >>
> > IP
> >
> >> packet into a protocol label, a PW label, and a tunnel label.
> >> That's a 3 label stack , with excellent load sharing capabilities.
> If
> >> you pull the PID out into a CW , for example , you will have to add
> >> another label , and also make the encapsulation process much more
> >> complicated at the PE.
> >> So , for this application it's better to just have 3 labels.
> >>
> >> Luca
> >>
> >>
> >>
> >>
> >> HENDERICKX Wim wrote:
> >>
> >>
> >>> I would vote for the latter. It is not much about the label
> >>>
> > uniqueness
> >
> >>> but the depth of the stack since it reduces BW.
> >>>
> >>> If we embed the e-type in the label it becomes more easy as well.
> >>>
> >>> -----Original Message-----
> >>> From: Stewart Bryant [mailto:stbryant at cisco.com]
> >>> Sent: maandag 16 november 2009 18:15
> >>> To: HENDERICKX Wim
> >>> Cc: Andrew G. Malis; pwe3 at ietf.org
> >>> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
> >>>
> >>> It depends what you mean by optimize.
> >>>
> >>> Say you have 100 PWs and 2 protocols
> >>>
> >>> If you optimize for minimum number of unique labels by separating
> the
> >>>
> >
> >
> >>> functions, as per the draft, this takes 102 labels
> >>>
> >>> If you optimize for number of labels in the stack, which is what
> you
> >>>
> >>>
> >> are
> >>
> >>
> >>> requesting, you need 200 unique labels.
> >>>
> >>> - Stewart
> >>>
> >>>
> >>>
> >>>
> >>> HENDERICKX Wim wrote:
> >>>
> >>>
> >>>
> >>>> This is correct but could we not optimize this special mapping ?
> >>>>
> >>>> -----Original Message-----
> >>>> From: Andrew G. Malis [mailto:amalis at gmail.com]
> >>>> Sent: maandag 16 november 2009 15:39
> >>>> To: HENDERICKX Wim
> >>>> Cc: stbryant at cisco.com; pwe3 at ietf.org
> >>>> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
> >>>>
> >>>> Wim,
> >>>>
> >>>> It's still more efficient on the wire than a simulated Ethernet
> PW,
> >>>> because you would have one less label (the protocol identifier),
> but
> >>>> would add the Ethernet MAC header instead.
> >>>>
> >>>> Cheers,
> >>>> Andy
> >>>>
> >>>> On Mon, Nov 16, 2009 at 9:03 AM, HENDERICKX Wim
> >>>> <wim.henderickx at alcatel-lucent.be> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Ok good, this is what I thought, the client LSP exist in the
> >>>>>
> > "client
> >
> >>>>> packet Network layer".
> >>>>>
> >>>>> Don't you think this is a huge stack for such a function. You
> could
> >>>>>
> >>>>>
> >>>>>
> >>> have
> >>>
> >>>
> >>>
> >>>>> 4-6 LBL(s) + CW (optionally). I understand this proposal re-uses
> >>>>> existing functions defined in MPLS, but there are lot's of
> >>>>>
> >>>>>
> >>>>>
> >>> optimizations
> >>>
> >>>
> >>>
> >>>>> possible here -> we could combine FAT LBL, PID LBL, CW
> potentially.
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Stewart Bryant [mailto:stbryant at cisco.com]
> >>>>> Sent: maandag 16 november 2009 14:49
> >>>>> To: HENDERICKX Wim
> >>>>> Cc: pwe3 at ietf.org
> >>>>> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> WH> what I meant is this:
> >>>>>>>
> >>>>>>> -------- --------
> >>>>>>> PE1-----| | | | --- PE3
> >>>>>>> | LSR |------- PKT PW ------| LSR |
> >>>>>>> | | | |
> >>>>>>> PE2-----| | | |---- PE4
> >>>>>>> -------- --------
> >>>>>>>
> >>>>>>> Assume PE1 has a LSP to PE3 and PE2 has an LSP to PE4, how is
> >>>>>>>
> > this
> >
> >>>>>>> distinguished on the PKT PW ?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> SB> I am not sure what you have drawn there, but it is not what
> is
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> shown
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> in the draft. The pkt pw run between the PEs and is carried
> over
> >>>>>>
> >>>>>>
> >>>>>>
> >>> the
> >>>
> >>>
> >>>
> >>>>>> LSPs. PWs are distinguished from each other at the PE via the
PW
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> label.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> WH> What I tried to draw is PE(s) attached to the device (drawn
> >>>>>>
> >>>>>>
> >> with
> >>
> >>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> box) which is performing the LSR function on a PKT PW to
another
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> device
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> (drawn with the box) which attaching PE(s).
> >>>>>>
> >>>>>> The question is if I have multiple LSPs from different PE(s)
> >>>>>>
> >>>>>>
> >> through
> >>
> >>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> PKT PW how are the distinguished. Do I need a separate PID LBL,
> a
> >>>>>> separate PW, etc such that the LSR can make the correct LBL
> >>>>>>
> >>>>>>
> >>>>>>
> >>> mappings.
> >>>
> >>>
> >>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Wim
> >>>>>
> >>>>> Think of the PW as a point to point link between a pair of PEs.
> The
> >>>>>
> >>>>>
> >>>>>
> >>> PE
> >>>
> >>>
> >>>
> >>>>> chooses what traffic to sent over a given PW. The PE then pushes
> an
> >>>>>
> >>>>>
> >>>>>
> >>> MPLS
> >>>
> >>>
> >>>
> >>>>> label to identify the destination. The mid-point LSRs have no
> clue
> >>>>>
> >>>>>
> >>>>>
> >>> what
> >>>
> >>>
> >>>
> >>>>> is being carried over the LSP. The egress PE unwraps that packet
> >>>>>
> > and
> >
> >>>>> figures out what the payload is.
> >>>>>
> >>>>> RFC3985 applies to pkt pw as it does to any other PW.
> >>>>>
> >>>>> - Stewart
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> pwe3 mailing list
> >>>>> pwe3 at ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/pwe3
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> pwe3 at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/pwe3
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3