Re: [Mpls-interop] PST.ppt

[Huub van Helvoort <[e-mail]>]

Hi Deborah,

You wrote:


> TCM in SONET was never implemented (unusable),

Which was first: is is not documented in T1.105 hence it is not
implemented, or it was not used hence it was not necessary to
standardise it (in T1.105)?

> for SDH it was never used really that I know of

Based on my activity in a usenet newsgroup I recieved
from several different operators requests to help them
set it up.

> (it had a hiccup in that it caused a service outage when writing
 > the bytes).

That may have been a particular implementation, I have worked
on devices that did not have this problem.
I have also worked on work-arounds for those cases where the
HW did not support TCM and the service provider wanted to use
the features of TCM.

> And there never was any protection defined based on using it.

There is indeed confusion about what TCM is designed for.
It is designed for performance monitoring and fault localisation.

If you would like to protect the section you would create a
sub-network layer connection that provides the protection:
SNCP, which can be based on the same defects that are detected
by TCM, but can also use other defects hence SNC/I, SCN/N, etc.

> For Ethernet 802.1ag levels (which is ITU's favored approach for
> MPLS-TP), there hasn't been any work yet done on defining protection
> based on it. 

Because MEG levels are used for PM and FL.
If you need protection, create a SNC and protect that.

SNC protection is described in G.8031 for ethernet and G.808.1
is the generic description.

> I'm sitting in Geneva with an MEF/IEEE person and he
> says to carefully say that there is nothing precluding it, just no
> one is doing it yet. Most operators are looking at all the 802.1ag
> levels as overkill and way too complex to manage.

Isn't this dependent on which department in the operator company
one talks to?

> MEF has decided to
> specify only needing to use 2 levels (or maybe it's 3 - we would need
> to check) for OAM. Again, no protection has been defined. 

See previous comment.

> And if ITU wants MPLS-TP based on ASON, then the protection
 > domains can not overlap or cross domains.

Is it common practice to have protection switching across
domains?

> 802.1ag levels can. So if define protection, would need to also
 > restrict how the levels are configured.

That is part of the definition of the levels and their use.

Regards, Huub.

> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Ben Niven-Jenkins
>  Sent: Wednesday, December 03, 2008 2:10 PM To: Drake, John E; Martin
> Vigoureux Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod
> HaSharon) Subject: Re: [Mpls-interop] PST.ppt
> 
> My understanding is the same as Martin's - that the point of a
> PST(/TC) is to monitor part of and end to end path, no more.
> 
> Although TCM has been part of ITU Recs for a long time, I'm not sure
> how many operators actually implement it.  I'm pretty sure BT doesn't
> because it makes the operations too complex but I don't look after
> our transport networks so I could be wrong.
> 
> Ben
> 
> 
> 
> On 03/12/2008 17:09, "Drake, John E" <[e-mail]>
> wrote:
> 
>> Very good - it's a question for the group
>> 
>>> -----Original Message----- From: Martin Vigoureux
>>> [mailto:[e-mail]] Sent: Wednesday,
>>> December 03, 2008 8:45 AM To: Drake, John E Cc: Sprecher, Nurit
>>> (NSN - IL/Hod HaSharon); [e-mail]; Weingarten,
>>> Yaacov (NSN - IL/Hod HaSharon) Subject: Re: [Mpls-interop]
>>> PST.ppt
>>> 
>>> John,
>>> 
>>> I think we are indeed down to the point of having to answer the
>>> question you raise: Should the PSTs be protected or not? My
>>> understanding is the following: PSTs are entities used to monitor
>>> the liveliness and performance of the LSPs they tunnel. PSTs do
>>> so by in fact monitoring their own liveliness/performance. In
>>> case a defect occurs the recovery is done at the LSP level.
>>> 
>>> As such my understanding was that PSTs need not be protected but
>>> if my understanding is incorrect and/or we decide they should be,
>>> I am fine :-)
>>> 
>>> -m
>>> 
>>> Drake, John E a écrit :
>>>> Martin,
>>>> 
>>>> It will be some combination of new work, RFC 4873, the LSP
>>> hierarchy RFC, and the end to end recovery RFC.  As I indicated
>>> in a crossing e-mail, perhaps I am incorrect in saying that PST
>>> protection switching is required for MPLS TP, in which case we
>>> wouldn't work on it.
>>>> Thanks,
>>>> 
>>>> John
>>>>> -----Original Message----- From: Martin Vigoureux
>>>>> [mailto:[e-mail]] Sent: Wednesday,
>>>>> December 03, 2008 8:00 AM To: Sprecher, Nurit (NSN - IL/Hod
>>>>> HaSharon) Cc: Drake, John E; [e-mail];
>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>> [Mpls-interop] PST.ppt
>>>>> 
>>>>> Nurit, John,
>>>>> 
>>>>> so as to make sure I correctly understand your aim, do you
>>>>> plan to use rfc4873 to establish the second PST? thanks
>>>>> 
>>>>> -m
>>>>> 
>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
>>>>>> You could say the same ting for PWs that are transmitted
>>>>>> via LSPs. You do not protect the LSP, there is no
>>>>>> protection and
>>>>> working LSPs but there are working tunneled PWs and
>>>>> protection PWs.
>>>>>> I think we have working PST and protection PST to protect
>>>>> the LSPs that are tunneled via the PSTs......
>>>>>> I hope this clarifies......
>>>>>> 
>>>>>> -----Original Message----- From: ext Martin Vigoureux
>>>>> [mailto:[e-mail]]
>>>>>> Sent: Wednesday, December 03, 2008 17:45 To: Drake, John E 
>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>> [e-mail];
>>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>>> [Mpls-interop] PST.ppt
>>>>>> 
>>>>>> John
>>>>>> 
>>>>>> ok, then what I am saying is that there should not be a
>>>>>> notion of working and protecting PST. There should be
>>>>>> working LSPs tunnelled in a PST and
>>> protecting LSPs
>>>>>> tunnelled in some other PST but I do not believe that this
>>>>> second PST
>>>>>> should be the protecting of the first. Hope this clarifies.
>>>>>> 
>>>>>> 
>>>>>> -m
>>>>>> 
>>>>>> Drake, John E a écrit :
>>>>>>> Martin,
>>>>>>> 
>>>>>>> There could be working and protecting LSPs as well, but
>>>>> that would be completely transparent to the PSTs, and the
>>>>> operation of the PST protection switch would be completely
>>>>> transparent to the contained LSPs.  I.e., if the working PST
>>>>> fails and the contained LSPs are moved to the protecting PST,
>>>>> none of the contained LSPs would be aware of the move and
>>>>> none of them would initiate a protection switch to their
>>>>> protecting LSPs.
>>>>>>> The PST endpoints need to be aware of the individual
>>>>>>> LSPs,
>>>>> so there would need to be some coordination between them as
>>>>> the set of contained LSPs changes.
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> John
>>>>>>> 
>>>>>>>> -----Original Message----- From: Martin Vigoureux
>>> [mailto:[e-mail]]
>>>>>>>> Sent: Wednesday, December 03, 2008 6:55 AM To: Drake,
>>>>>>>> John E Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>>> [e-mail];
>>>>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>>>>> [Mpls-interop] PST.ppt
>>>>>>>> 
>>>>>>>> John,
>>>>>>>> 
>>>>>>>> if I read you correctly does this mean that the
>>>>>>>> switch-over is performed at the PST level and not
>>>>>>>> anymore at the LSP
>>>>> level (and so
>>>>>>>> that there are no more working and protecting LSPs,
>>>>>>>> only
>>>>> LSPs which
>>>>>>>> are transparently switched when the PST that tunnels
>>>>>>>> them is switched from primary to secondary)?
>>>>>>>> 
>>>>>>>> -m
>>>>>>>> 
>>>>>>>> Drake, John E a écrit :
>>>>>>>>> Martin,
>>>>>>>>> 
>>>>>>>>> There is a working PST, a protecting PST, and a set
>>>>>>>>> of one
>>>>>>>> or more LSPs (or PWs).  When the working PST is up, it
>>>>> contains the
>>>>>>>> set of one or more LSPs (or PWs).  When the working PST
>>>>>>>> is
>>>>> down, the
>>>>>>>> protecting PST contains the set of one or more LSPs (or
>>>>>>>> PWs).
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> John
>>>>>>>>> 
>>>>>>>>>> -----Original Message----- From: Martin Vigoureux
>>>>> [mailto:[e-mail]]
>>>>>>>>>> Sent: Wednesday, December 03, 2008 6:42 AM To:
>>>>>>>>>> Drake, John E Cc: Sprecher, Nurit (NSN - IL/Hod
>>>>>>>>>> HaSharon);
>>>>> [e-mail];
>>>>>>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) Subject:
>>>>>>>>>> Re: [Mpls-interop] PST.ppt
>>>>>>>>>> 
>>>>>>>>>> John,
>>>>>>>>>> 
>>>>>>>>>> I understand but I do not understand the need for
>>>>>>>>>> dual
>>>>> protection
>>>>>>>>>> (i.e. having working and protecting LSPs and in
>>>>>>>>>> addition
>>>>> a working
>>>>>>>>>> and a protecting PST) I think we only need working
>>>>>>>>>> and
>>>>> protecting
>>>>>>>>>> LSPs and PSTs around them. The difference may be
>>>>>>>>>> subtle
>>>>> but may be
>>>>>>>>>> not in terms of operations. By reading working and
>>>>>>>>>> protecting I implicitly read that
>>>>> a switch
>>>>>>>>>> over will happen between the two and I guess we
>>>>>>>>>> want to
>>>>> swith LSPs
>>>>>>>>>> from a PST to another one but we do not need (want)
>>>>>>>>>> to
>>>>> switch a PST
>>>>>>>>>> to another PST. Do we? If I am not clear enough,
>>>>>>>>>> let me know. :-)
>>>>>>>>>> 
>>>>>>>>>> -m
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Drake, John E a écrit :
>>>>>>>>>>> I think there would be a working and a protecting
>>>>>>>>>>> PST, both
>>>>>>>>>> with an inband OAM channel.  When the working PST
>>>>>>>>>> is
>>> up, it will
>>>>>>>>>> contain a set of one or more LSPs (or PWs).  When
>>>>>>>>>> the
>>>>> working PST
>>>>>>>>>> fails, the set of one or more LSPs is moved to the
>>>>> protecting PST.
>>>>>>>>>>> Presumably, the inband OAM channel on the working
>>>>>>>>>>> PST is
>>>>>>>>>> used to detect its failure and the inband OAM
>>>>>>>>>> channel on the protecting PST is used to coordinate
>>>>>>>>>> the movement of the
>>>>> LSPs (or
>>>>>>>>>> PWs) to it.
>>>>>>>>>>>> -----Original Message----- From: Martin
>>>>>>>>>>>> Vigoureux
>>>>> [mailto:[e-mail]]
>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 6:15 AM To:
>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc:
>>>>>>>>>>>> [e-mail]; Weingarten,Yaacov (NSN -
>>>>>>>>>>>> IL/Hod HaSharon) Subject: Re: [Mpls-interop]
>>>>>>>>>>>> PST.ppt
>>>>>>>>>>>> 
>>>>>>>>>>>> Nurit,
>>>>>>>>>>>> 
>>>>>>>>>>>> clarification question :-) is the intent to
>>>>>>>>>>>> protect the PST or to protect to LSPs and
>>>>>>>>>> be able to
>>>>>>>>>>>> run OAM (at large) on segments of the
>>>>>>>>>>>> protecting LSPs once
>>>>>>>>>> the switch
>>>>>>>>>>>> over has been done? thanks
>>>>>>>>>>>> 
>>>>>>>>>>>> -m
>>>>>>>>>>>> 
>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit
>>>>>>>>>>>> :
>>>>>>>>>>>>> The intention is to protect the PST....and
>>>>>>>>>>>>> switch over the
>>>>>>>>>> tunneled
>>>>>>>>>>>>> LSPs into a protected PST when there is a
>>>>>>>>>>>>> fault condition
>>>>>>>>>> along the
>>>>>>>>>>>>> working PST.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Original Message----- From: ext Loa
>>>>>>>>>>>>> Andersson [mailto:[e-mail]] Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 16:08 To: Adrian Farrel Cc:
>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>>>>>> [e-mail];
>>>>>>>>>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon);
>>>>> [e-mail]
>>>>>>>>>>>>> Subject: Re: PST.ppt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Adrian,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Adrian Farrel wrote: I don't think that it
>>>>>>>>>>>>> should any different. Good
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So 2nd PE from the left pops the tunnel label
>>>>>>>>>>>>> and swaps
>>>>>>>>>> the inner
>>>>>>>>>>>>> label and then pushes the new tunnel label.
>>>>>>>>>>>>> Is that
>>>>>>>> what you say?
>>>>>>>>>>>>> Yup. Normal LSR behavior.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Same for the 3rd PE? Why would this be any
>>>>>>>>>>>>> different from normal LSR
>>>>> behavior?   :-)
>>>>>>>>>>>>> I don't look for or hope for any difference
>>>>>>>>>>>>> ;).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Assuming there is a PST from the 3rd to the
>>>>>>>>>>>>> 4th PE also?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What is protected from e.g. 3rd PE to the 4th
>>>>>>>>>>>>> PE the entire
>>>>>>>>>>>> containing
>>>>>>>>>>>>> tunnel or the each separate contained tunnel?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> /Loa
>>>>>>>>>>>>> 
>>>>>>>>>>>>> A
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Adrian Farrel wrote: Loa,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Why would this be any different from normal
>>>>>>>>>>>>> LSR behavior?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> P1 sees only the PST labels PEs pop the PST
>>> label and see
>>>>>>>>>>>>> the e2e label and
>>>>> process it as
>>>>>>>>>>>>> normal. Cheers, Adrian ----- Original Message
>>>>>>>>>>>>> ----- From: "Loa Andersson"
>>>>> <[e-mail]>
>>>>>>>>>>>>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
>>>>>>>>>>>>>  <[e-mail]> Cc: "Adrian Farrel"
>>>>>>>>>>>>> <[e-mail]>uk>;
>>>>>>>>>> <[e-mail]>nl>;
>>>>>>>>>>>>> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
>>>>>>>>>>>>> <[e-mail]>om>;
>>>>>>>>>>>>> <[e-mail]> Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 12:41 PM Subject: Re:
>>>>>>>>>>>>> PST.ppt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nurit,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ok fine, however ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In your figure will the  2nd and 3rd PEs
>>>>>>>>>>>>> label swap
>>>>>>>>>> the label on
>>>>>>>>>>>>> E2E tunnels LSP? Or is the same label showing
>>>>>>>>>>>>> up at
>>>>>>>>>> the  4th PE?
>>>>>>>>>>>>> /Loa
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>>>>>>>>>>> wrote: Oops......my mistake.......here is the
>>>>>>>>>>>>> updated
>>>>> figure......
>>>>>>>>>>>>> The intention was to refer to a SS-PW.
>>>>>>>>>>>>> Accidentally I
>>>>>>>>>>>> referred to
>>>>>>>>>>>>> T-PE and S-PE.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We can provide also another figure for the
>>>>>>>>>>>>> MS-PW case.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Note also that the figure is adapted with the
>>>>>>>>>>>>> 
>>>>> new term - PST
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Original Message----- From: ext Loa
>>>>>>>>>>>>> Andersson [mailto:[e-mail]] Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 14:21 To: Sprecher, Nurit
>>>>>>>>>>>>> (NSN - IL/Hod HaSharon) Cc: Adrian Farrel;
>>>>>>>>>>>>> [e-mail]; Weingarten,
>>>>>>>>>>>> Yaacov (NSN -
>>>>>>>>>>>>> IL/Hod HaSharon); [e-mail] 
>>>>>>>>>>>>> Subject: PST question: Was (Re:
>>>>>>>>>>>>> [Mpls-interop] Who
>>>>>>>> will be in
>>>>>>>>>>>>> Geneva?) Renaming the thread - a little late
>>>>>>>>>>>>> but anyway ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> at risk asking the obvious, since I'm still
>>>>>>>>>>>>> reading
>>>>>>>>>> through the
>>>>>>>>>>>>> thread?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nurit,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In your figure will the S-PEs label swap the
>>>>>>>>>>>>> label on
>>>>>>>>>>>>> 
>>>>>>>>>>>>> E2E tunnels LSP? Or is the same label showing
>>>>>>>>>>>>> up at the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> second T-PE?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> /Loa
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi, I agree that we need to find a better
>>>>>>>>>>>>> name...... What about the figure in the
>>>>>>>>>>>>> second slide of
>>>>> the attached?
>>>>>>>>>>>>> If multiple LSPs transmit via the same
>>>>>>>>>>>>> physical
>>>>>>>> path in the
>>>>>>>>>>>>> first domain
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and have the same constraints, why cannot we
>>>>>>>> aggregate them
>>>>>>>>>>>>> and run OAM
>>>>>>>>>>>>> 
>>>>>>>>>>>>> per the aggregated in the first domain? Best
>>>>>>>>>>>>> regards, Nurit -----Original Message----- 
>>>>>>>>>>>>> From: ext Adrian Farrel
>>>>>>>>>>>>> [mailto:[e-mail]] Sent: Tuesday,
>>>>>>>>>>>>> December 02, 2008 11:20 To:
>>>>>>>>>>>>> [e-mail]; Sprecher, Nurit (NSN -
>>>>>>>>>>>>> IL/Hod
>>>>>>>>>>>> HaSharon)
>>>>>>>>>>>>> Cc: ext Ben Niven-Jenkins;
>>>>>>>>>>>>> [e-mail] Subject: Re:
>>>>>>>>>>>>> [Mpls-interop] Who will be in Geneva? Hi
>>>>>>>>>>>>> Huub. The TC aggregate is not a TC anymore,
>>>>>>>>>>>>> it
>>>>> should IMHO be
>>>>>>>>>>>>> referred to as a tunnel. Yes! Which is not to
>>>>>>>>>>>>> say that it is not a useful
>>>>> construct for
>>>>>>>>>>>>> reducing OAM overhead. I think (OK, I know)
>>>>>>>>>>>>> that I suggested we avoid
>>>>> using the TC
>>>>>>>>>>>>> language as
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I thought we would find it unhelpful. Perhaps
>>>>>>>>>>>>> when we
>>>>>>>>>> meet to go
>>>>>>>>>>>>> through this, we can draw pictures and work
>>>>>>>>>>>>> out
>>>>>>>> the language
>>>>>>>>>>>>> later? A
>>> ---------------------------------------------------------------------
>>> 
>>>>>>>>>>>> -
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>  Mpls-interop mailing list
>>>>>>>>>>>>> [e-mail] 
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>>>>>>>>>>>>  --
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Loa Andersson                         email: 
>>>>>>>>>>>>> [e-mail] Sr Strategy and
>>>>>>>>>>>>> Standards Manager            [e-mail] 
>>>>>>>>>>>>> Redback Networks                      phone:
>>>>>>>>>>>>> +46
>>>>> 8 632 77 14
>>>>>>>>>>>>> An Ericsson Company --
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Loa Andersson                         email: 
>>>>>>>>>>>>> [e-mail] Sr Strategy and
>>>>>>>>>>>>> Standards Manager            [e-mail] 
>>>>>>>>>>>>> Redback Networks                      phone:
>>>>>>>>>>>>> +46
>>> 8 632 77 14
>>>>>>>>>>>>> An Ericsson Company
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>  Mpls-interop mailing list 
>>>>>>>>>>>> [e-mail] 
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>> _______________________________________________ Mpls-interop
>> mailing list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/mpls-interop
> 
> _______________________________________________ Mpls-interop mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/mpls-interop 
> _______________________________________________ Mpls-interop mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop