The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Linux implementation of MPLS
On Sat, 18 Sep 2004, M.V. Padmini wrote: > Well, the debate may not end so soon after all!! > > First of all, when i meant unique labels - i meant it for a complete LSR > and among all LSRs not confinig to the ingress. > > The idea i had in mind was - keep all edges of the graph unique - ur done. If u can ensure that EVERY downstream LSR distributes UNIQUE label binding to their upstream peers for each FEC, then ofcourse, u r correct in saying that their will be no need of "per interface label-space". > But this will lead to exhausting the labels very soon. Not very soon!! u have (2^20)-1 UNIQUE labels to choose from... hope the debate is now put to rest :) --Sundeep. > If u look at it > carefully, you may need to keep the labels unique only between two > adjacent sets of input and output labels. Never the less, by putting in > the label space, you are trying to build a heirarchical structure of > labels. > > Does that make sense or am i off track? > >> Hi, >> >> I feel label-space will be important even if u assign unique labels to >> FECs at the ingress LSR. Imagine thie scenario wherein, >> >> FECs A, B, C are assigned labels (1,2,3) uniquely by the ingress... >> >> At the next LSR, these labels are swapped (1,2,3)->(2,2,3), then in >> this case the information provided by the label-space would be >> important for swapping at the next LSR. (althou i am not really sure >> whether the swapping (1,2,3)->(2,2,3) is really valid !!) >> >> --Sundeep. >> >> >> On Fri, 17 Sep 2004, M.V. Padmini wrote: >> >>> Hi sudeep, >>> >>> Well, we are talking of a static routing scenario here. When we >>> alreadly know the LSR, where where is the need to use the label space >>> info? (well pardon me since i have still not read the doc. >>> completely!). Since the labels on the LSRs are unique, there is no >>> question of messing up. Well, as far as the simple routing is >>> concerned, unique label for every FEC should work fine. May be its >>> required in some other cases i.e. Tunnel etc. Am not sure. The other >>> reason could be not to run out of labels!! >>> >>> - Padmini >>> >>> >>>> Hi Padmini, >>>> We are also in the process of creating a MPLS test-bed in IITB. I >>>> guess >>>> the notion of lablespace is to identify the interface that the labels >>>> come from (as you have rightly said), but this concept is useful in >>>> processing at the hop on the basis of interfaces that it come from, >>>> rather than trying and identifying each and individual labels and >>>> then processing. Labelspaces can make some processing fast. >>>> >>>> As far as a small test-bed is considered, it doesn't make a >>>> difference >>>> to >>>> use or not to use labelspaces. >>>> >>>> I have successfully traversed ping packets using MPLS on my >>>> test-bed. >>>> But >>>> ssh and other application packets seem not to work as of now. Lets >>>> see. Efforts are on :) >>>> >>>> ciao, >>>> Sudeep >>>> >>>> >>>> On Fri, 17 Sep 2004, M.V. Padmini wrote: >>>> >>>>> >>>>> We are in the process of implementing a Test bed for MPLS using >>>>> linux boxes. Having gone through the mplsadm literature, they seem >>>>> to be using two parameters (label, labelspace) to be associated with >>>>> each Interface for an FEC. The labelspace is supposed to identify >>>>> the interface (from which it came) where the labels could be same >>>>> (labels coming from different interfaces). >>>>> >>>>> Is there a need to do this? If you enforce the uniqueness of the >>>>> label wrt to a FEC, dont u think that there is no requirement for a >>>>> labelspace. Am i missing something? >>>>> >>>>> Thanks in advance. >>>>> >>>>> >>>>>> Abhishek Mittal wrote: >>>>>>> 6> Fix up the MTU size >>>>>> >>>>>> After upgrading to a newer IOS on the Catalyst yesterday, I just >>>>>> added MPLS IP to the 12k router again --- works fine now (with 1512 >>>>>> as MTU on all used interfaces) ... >>>>>> >>>>>> -gg >>>>>> >>>>>> ------- >>>>>> The MPLS-OPS Mailing List >>>>>> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >>>>>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >>>>> >>>>> >>>>> ____________________________________________ >>>>> ERNET Project >>>>> Dept. of Computer Science and Engineering >>>>> IIT Delhi >>>>> New Delhi - 110 016 >>>>> >>>>> Phone: +(91)-11-2659 6009 >>>>> >>>>> >>>>> ------- >>>>> The MPLS-OPS Mailing List >>>>> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >>>>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >>>>> >>>> >>>> -- >>>> >>>> When a great leader's work is done, people say "we did it ourselves". >>>> -Tao >>>> >>>> ------- >>>> The MPLS-OPS Mailing List >>>> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >>>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >>> >>> >>> ____________________________________________ >>> ERNET Project >>> Dept. of Computer Science and Engineering >>> IIT Delhi >>> New Delhi - 110 016 >>> >>> Phone: +(91)-11-2659 6009 >>> >>> >>> ------- >>> The MPLS-OPS Mailing List >>> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >>> >> >> -- >> Sundeep. >> >> ------- >> The MPLS-OPS Mailing List >> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ____________________________________________ > ERNET Project > Dept. of Computer Science and Engineering > IIT Delhi > New Delhi - 110 016 > > Phone: +(91)-11-2659 6009 > > -- Sundeep. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|