Re: [Mpls-interop] Who will be in Geneva?

["BUSI ITALO" <[e-mail]>]

I agree 100% with Huub.

I think we need to clarify the concept (irrespectively from the name)
first, the we can understand the solution and finally we can give an
appropriate name.

The concept is the following: if I have a connection from A to Z, I
would like to monitor (from fault and performance management) that
connection (and only that one) between two intermediate points (let us
call them I and J).

There are many potential solutions to this problem. One solution is to
rely on the MEG Level, like in Ethernet, but it has some impacts on the
forwarding plane. In fact it is required that J is able to distinguish
the OAM packets monitoring the TC (that it has to terminate) and the OAM
packets monitoring the e2e connections that have to be forwarded like
user data packets.

In MPLS-TP, there is a clear requirement that the MPLS forwarding
paradigm, as defined in RFC 3031, MUST not be changed. As a consequence
the only mechanism I can imagine to solve the TC requirement is the one
based on label stacking.

Given the definition of TC, there is a 1:1 mapping between the TC and
the end-to-end connection the TC refers to.

The fact that the same mechanism used for tunneling (i.e. label
stacking) is also used for TCM is just by chance and should not create
confusion between them. Tunneling and TC are different architectural
concepts and managed differently.

Italo

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Huub van Helvoort
> Sent: Tuesday, December 02, 2008 10:16 AM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: [e-mail]
> Subject: Re: [Mpls-interop] Who will be in Geneva?
> 
> Hi Ben and Nurit,
> 
> We definitly have to have a f-2-f discussion about TC, I think
> there is still some confusion.
> 
> > Scalability of TC (or whatever we call it) is basically if 
> you have 1:1
> > mapping between TC and LSP. But if you have 1:n mapping TC 
> and many LSPs
> > the main concern can be solved. 
> 
> TC is 1:1 related to a single LSP, this is how TC is defined
> in the Transport environment. A TC can be created either by
> stacking or by using the MEG level methodology (also used in
> the transport ethernet)
> 
> > If you define TC in reasonable areas (e.g. across a domain in a
> > multi-domain network) and the TC aggregate multiple LSPs 
> then IMO the
> > construction of TC is the cleanest one and works well with 
> OAM and with
> > protection.
> 
> The TC aggregate is not a TC anymore, it should IMHO be referred
> to as a tunnel.
> 
> Cheers, Huub.
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of ext Ben
> > Niven-Jenkins
> > Sent: Tuesday, December 02, 2008 00:17
> > To: Adrian Farrel; [e-mail]
> > Subject: Re: [Mpls-interop] Who will be in Geneva?
> > 
> > Adrian,
> > 
> > On 27/11/2008 22:27, "Adrian Farrel" <[e-mail]> wrote:
> >> I ended up with a modest list of MPLS-TP design team folk 
> willing to
> >> squander their evenings in Geneva working on drafts. Must 
> be that the
> > Swiss
> >> night life is too exciting!
> > 
> > Or that there is no Q.Whisky in SG15 ;-)
> > 
> >> Lastly, I would like to see if I can understand the issues with the
> > OAM
> >> techniques proposed. Can we continue to use TTL? Does the idea of
> > using
> >> nesting for all OAM segments really hold up? Is the OAM 
> cart in danger
> > of
> >> driving the protection hobbyhorse (pardon my mixed metaphore).
> > 
> > I'm no OAM expert (I leave that to Tom :-) ) but I am yet to be
> > convinced by
> > nesting all OAM segments for the reason that it sounds 
> complicated and
> > that
> > means to me that it will be expensive to run and to scale.  It also
> > sounds
> > like I'd have to have my network constructed in a 
> particular way to be
> > able
> > to use OAM which means even in the best run network I will 
> at some point
> > not
> > be able to run OAM when I need it (and the customer is 
> screaming at me)
> > because the network wasn't constructed correctly (either by 
> design or
> > actual
> > configuration != design).
> > 
> > Ben
> > 
> > _______________________________________________
> > 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
> 
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop