Subject: Re: [mpls-tp] R: Re: OAM ambiguity inIDdraft-vigoureux-mpls-tp-oam-requirements-00

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Sep 2008 09:26:18 +0200

Enrique,

Do we exclude in future the definition of a port-based MPLS-TP service? 
Such service could be used to connect to a remote NT device; i.e. to connect
a NT owned by operator A, which is located behind the network of operator B,
to an edge node of operator A's network. 

In this carrier-carrier case, the MPLS Section is between adjacent LSRs
(remote NT, edge node) of operator A, and includes the link between NT and
operator B LSR, connection in operator B's network and link between operator
B and operator A edge node.

The MPLS Section is functionally similar to an LSP. Because there is only
one MPLS Section on a physical link, it is not necessary to use a label
(i.e. it an 'unlabelled LSP'). When this MPLS section connection is carried
through operator B's network, then the MPLS section packets get a label
added ('labelled LSP').

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hernandez-Valencia, Enrique (Enrique)
Sent: 15 August 2008 19:49
To: Diego Caviglia; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] R: Re: OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

All,

Section OAM is intended to have the scope of an MPLS section, that is,
between adjacent LSRs. No IP routing support would be required for *just
this* functionality.

OAM functions that require transport beyond adjacent LSRs require other
transport mechanism, say LSP OAM (or LSP-Segment OAM) or perhaps PW OAM,
depending of the specific function. Of course, these require routing support
for the CP to create the associated LSPs or PWs.

Rgds,
Enrique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Diego Caviglia
Sent: Friday, August 15, 2008 3:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] R: Re: OAM ambiguity in
IDdraft-vigoureux-mpls-tp-oam-requirements-00

Hi Huub,
            That was exactly what i had in mind.

Now given that the section gal is terminated on each node i think, from an
architectural point of view, there is the need to define how management and
signalling message are 'routed' among several, thinking about mesh networks,
available section gal.

In sdh the dcn has a routing protocol i suppose we need a similar mechanism
here.

Br

Diego

Ps the bottom line here is that ip routing and fw is *not* needed for the
data plane but may/should/must needed for signalling/management purposes.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Hernandez-Valencia, Enrique \(Enrique\)" <[email-masked]>
Date: Mon, 8 Sep 2008 10:29:29 -0500

Hello Maarten,

No intention to exclude definition of such port-based services.
Just that the entity that you're referring would not qualify
as an "MPLS section" as per current definitions. 

Keep in mind that here the use of the term "section" has a 
different scope that the usual scope in ITU-T. If folks would
prefer a different name to avoid potential confusions one can 
always ask.

Regard,
Enrique

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, September 08, 2008 3:26 AM
To: Hernandez-Valencia, Enrique (Enrique); 'Diego Caviglia';
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] R: Re: OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

Enrique,

Do we exclude in future the definition of a port-based MPLS-TP service? 
Such service could be used to connect to a remote NT device; i.e. to
connect
a NT owned by operator A, which is located behind the network of
operator B,
to an edge node of operator A's network. 

In this carrier-carrier case, the MPLS Section is between adjacent LSRs
(remote NT, edge node) of operator A, and includes the link between NT
and
operator B LSR, connection in operator B's network and link between
operator
B and operator A edge node.

The MPLS Section is functionally similar to an LSP. Because there is
only
one MPLS Section on a physical link, it is not necessary to use a label
(i.e. it an 'unlabelled LSP'). When this MPLS section connection is
carried
through operator B's network, then the MPLS section packets get a label
added ('labelled LSP').

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf

All,

OAM functions that require transport beyond adjacent LSRs require other
transport mechanism, say LSP OAM (or LSP-Segment OAM) or perhaps PW OAM,
depending of the specific function. Of course, these require routing
support
for the CP to create the associated LSPs or PWs.

Rgds,
Enrique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf
Of Diego Caviglia
Sent: Friday, August 15, 2008 3:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] R: Re: OAM ambiguity in
IDdraft-vigoureux-mpls-tp-oam-requirements-00

Hi Huub,

Now given that the section gal is terminated on each node i think, from
an
architectural point of view, there is the need to define how management
and
signalling message are 'routed' among several, thinking about mesh
networks,
available section gal.

In sdh the dcn has a routing protocol i suppose we need a similar
mechanism
here.

Br

Diego

Ps the bottom line here is that ip routing and fw is *not* needed for
the
data plane but may/should/must needed for signalling/management
purposes.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 8 Sep 2008 18:01:47 +0200

> prefer a different name to avoid potential confusions one can

Can we assume this one

--- http://tools.ietf.org/html/draft-bocci-pwe3-mpls-tp-ge-ach-00 ---

   MPLS Section:  A Section is a network segment between two LSRs that
   are immediately adjacent.

---

as the correct def in the MPLS-TP context? Don't you think a better
place would be draft-blb-mpls-tp-framework so that all other IDs
can point to it? In draft-blb-mpls-tp-framework the term is used but
not defined.

> Enrique

Ciao
FF

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 9 Sep 2008 17:46:06 +0200

HI Francesco,
             Accordingly to my understanding the answer to your question

>    are immediately adjacent.

is yes.

BR

Diego 

> From: Francesco Fondelli [mailto:[email-masked]]
> Sent: lunedì 8 settembre 2008 18.02
> To: Hernandez-Valencia, Enrique (Enrique)
> Cc: Maarten Vissers; Diego Caviglia; [email-masked]; mpls-
> [email-masked]
> Subject: Re: [mpls-tp] R: Re: OAM ambiguity inIDdraft-vigoureux-mpls-tp-
> oam-requirements-00
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 10 Sep 2008 09:48:32 +0200

Enrique,

An MPLS Section connection is a connection in a MPLS Section layer. As in
any other layer, a MPLS Section connection may include just a single link
connection (single hop), or may include a set of link connections and matrix
connections (multi-hop). 

If an "MPLS section" as per current definitions is referring to a MPLS XXX
layer link connection, then we need to define what the layer name is in
which such "MPLS section/XXX link connection" exists. I.e. we need a name
for the XXX. I prefer to to keep Section as name for this XXX layer and
redefine "MPLS section" into MPLS Section link connection.

Regards,
Maarten

-----Original Message-----
From: Hernandez-Valencia, Enrique (Enrique)
[mailto:[email-masked]] 
Sent: 08 September 2008 17:29
To: Maarten Vissers; Diego Caviglia; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] R: Re: OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

Hello Maarten,

No intention to exclude definition of such port-based services.
Just that the entity that you're referring would not qualify as an "MPLS
section" as per current definitions. 

Keep in mind that here the use of the term "section" has a different scope
that the usual scope in ITU-T. If folks would prefer a different name to
avoid potential confusions one can always ask.

Regard,
Enrique

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, September 08, 2008 3:26 AM
To: Hernandez-Valencia, Enrique (Enrique); 'Diego Caviglia';
[email-masked]
Cc: [email-masked]

Enrique,

Regards,
Maarten

-----Original Message-----

All,

Rgds,
Enrique

-----Original Message-----

Hi Huub,

Br

Diego

---

From: "Hernandez-Valencia, Enrique \(Enrique\)" <[email-masked]>
Date: Thu, 25 Sep 2008 06:42:02 -0500

Hello Francisco,

Sorry for the delay - the mail had been filtered by an overly protective
Anti-spam filter.

There is some understandable overlap in the scope of the various MPLS-TP
drafts. We all expect the scope will be sorted out as the material
progress. It just happens that
draft-vigoureux-mpls-tp-oam-requirements-00 is where the entity in
question is documented at this time.

Rgds,
Enrique

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: Monday, September 08, 2008 12:02 PM
To: Hernandez-Valencia, Enrique (Enrique)
Cc: Maarten Vissers; Diego Caviglia; [email-masked];
[email-masked]

Can we assume this one

--- http://tools.ietf.org/html/draft-bocci-pwe3-mpls-tp-ge-ach-00 ---

---

Ciao
FF