Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 26 Jul 2011 20:55:19 +0300

Hi,

In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed
and sometimes explicitly stated that an MPLS-TP section is equivalent to
a non-MPLS-TP link (aka data link).

See for example (there's more):

"MPLS-TP Section: As defined in [8], it is a link that can be  traversed
by one or more MPLS-TP LSPs."

"in case of an MPLS-TP section, the MEG is inferred from the port on
which an OAM packet was received with the GAL at the top of the label
stack" 

"An SMEG is intended to be deployed for applications where it is
preferable to monitor the link between topologically adjacent..."

However, as per RFC 5654 and especially RFC5960
(http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can
also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP
carrying a PW. 

If my understanding is correct, the section OAM requirements in
draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link
sections (n=0 following RFC 5960 terminology). In this case, this should
be clarified in the draft. 

Comments?

Regards,

Daniel

---

From: David Allan I <[email-masked]>
Date: Tue, 26 Jul 2011 15:52:50 -0400

HI Daniel:

We have a bit of an inconsistency creeping in in numerous places....

By the definition of a section as any (sub) layer "minus one" path component, then a section can be a physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW etc.

So to invent terms to facilitate this discussion we have a physical section (non-MPLS link) and a logical section (some MPLS path construct)

Which means we have established procedures for configuring OAM for any logical section, but as Greg Mirsky noted today, not for a physical section, at least not ones we'd necessarily want to use. We have MEP identifiers specific to a physical section in the identifiers draft what we would not use for logical sections as we really do not need multiple identities for maintenance entity components. I'm sure we have a few other places where this small dichotomy raises its head.

Nor do we want to confuse physical sections with logical sections....

Hence if we are to resolve some of this without revisiting established RFCs we need to introduce some distinction to further define section "types" along the lines I've suggested above (physcial and logical)... and apply it across the current document set.

WDYT?
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: [email-masked]
Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

Hi,

In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly stated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data link).

See for example (there's more):
"MPLS-TP Section: As defined in [8], it is a link that can be  traversed by one or more MPLS-TP LSPs."
"in case of an MPLS-TP section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack"
"An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent..."

However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.

If my understanding is correct, the section OAM requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections (n=0 following RFC 5960 terminology). In this case, this should be clarified in the draft.

Comments?

Regards,

Daniel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Jul 2011 13:33:40 -0700

Hi Dave, Daniel, and All,
I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I
think that there should not be distinction in Section MEP ID whether it is
Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP).
I think that making MEP ID of Logical Section identical to MEP ID of Server
layer LSP MEP ID creates issues with properly executing PM OAM on Section
layer and Server layer LSP.

Regards,
Greg

On Tue, Jul 26, 2011 at 12:52 PM, David Allan I
<[email-masked]>wrote:

> **
> By the definition of a section as any (sub) layer "minus one" path
> component, then a section can be a physical link for an SPME or LSP, an SPME
> for a LSP, an LSP for a PW etc.
>
> So to invent terms to facilitate this discussion we have a physical section
> (non-MPLS link) and a logical section (some MPLS path construct)
>
> Which means we have established procedures for configuring OAM for any
> logical section, but as Greg Mirsky noted today, not for a physical section,
> at least not ones we'd necessarily want to use. We have MEP identifiers
> specific to a physical section in the identifiers draft what we would not
> use for logical sections as we really do not need multiple identities
> for maintenance entity components. I'm sure we have a few other places where
> this small dichotomy raises its head.
>
> Hence if we are to resolve some of this without revisiting established RFCs
> we need to introduce some distinction to further define section "types"
> along the lines I've suggested above (physcial and logical)... and apply it
> across the current document set.
>
> WDYT?
> Dave
>
>
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Daniel Cohn
> *Sent:* Tuesday, July 26, 2011 1:55 PM
> *To:* [email-masked]
> *Subject:* [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
> section definitions?
>
>  Hi,****
>
> ** **
>
> In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and
> sometimes explicitly stated that an MPLS-TP section is equivalent to a
> non-MPLS-TP link (aka data link).****
>
> ** **
>
> See for example (there’s more):****
>
> “MPLS-TP Section: As defined in [8], it is a link that can be  traversed by
> one or more MPLS-TP LSPs.”****
>
> “in case of an MPLS-TP section, the MEG is inferred from the port on which
> an OAM packet was received with the GAL at the top of the label stack” ***
> *
>
> “An SMEG is intended to be deployed for applications where it is preferable
> to monitor the link between topologically adjacent…”****
>
> ** **
>
> However, as per RFC 5654 and especially RFC5960 (
> http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can
> carrying a PW. ****
> ** **
> draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections
> (n=0 following RFC 5960 terminology). In this case, this should be clarified
> in the draft. ****
>
> ** **
>
> Comments?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Daniel****
>
> ** **
>
> ** **
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 21:54:11 +0100

Greg/Dave/Daniel,

The fundamental problem here is that we simply don't have a proper BOS section layer in MPLS (any spin of).

More generally, in all networking scenarios there MUST be two things present:
-       a true TOS layer network that interfaces (via suitable adaptations) with the suite of external message/file/stream applications out there
-       a true BOS layer network that modulates an EM wave on either metallic/radio/fibre media...else we can't sent information (from the ultimate always-present TOS external message/file/stream applications noted above) over geographic distance.  So here we must have a binary<=>q'ary symbol lexicon mapping (which itself is a client/server relationship BTW).

MPLS in any guise is neither of these things...it sits between them.  It is for sure not a transport network, as this must be able to perform a true BOS role.  MPLS always requires a real transport network under that can perform this role.

So the whole discussion about an MPLS 'section layer' is somewhat moot/meaningless IMO.  MPLS (any spin) simply has a lowest LSP level...below that come the real transport layer networks.

regards, Neil
This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 26 July 2011 21:34
To: David Allan I
Cc: [email-masked]
Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

Hi Dave, Daniel, and All,
I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP).  I think that making MEP ID of Logical Section identical to MEP ID of Server layer LSP MEP ID creates issues with properly executing PM OAM on Section layer and Server layer LSP.

Regards,
Greg
On Tue, Jul 26, 2011 at 12:52 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
HI Daniel:

WDYT?
Dave

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?
Hi,

Comments?

Regards,

Daniel

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

---

From: Giles Heron <[email-masked]>
Date: Tue, 26 Jul 2011 22:10:59 +0100

> layer in MPLS (any spin of).

Agreed.

> -       a true TOS layer network that interfaces (via suitable adaptations)
> with the suite of external message/file/stream applications out there
> -       a true BOS layer network that modulates an EM wave on either
> metallic/radio/fibre media...else we can't sent information (from the ultimate
> always-present TOS external message/file/stream applications noted above) over
> geographic distance.  So here we must have a binary<=>q'ary symbol lexicon
> mapping (which itself is a client/server relationship BTW).

Agreed

> MPLS in any guise is neither of these things...it sits between them.  It is
> for sure not a transport network, as this must be able to perform a true BOS
> role.  MPLS always requires a real transport network under that can perform
> this role.

Agreed.

But the "real transport network" MPLS sits on may be (and typically is) just
a link.  It doesn't have to be a network (in the sense of being something
with more than two nodes and with some form of switching capability).
 
> So the whole discussion about an MPLS 'section layer' is somewhat
> moot/meaningless IMO.  MPLS (any spin) simply has a lowest LSP level...below
> that come the real transport layer networks.

Agreed.

Giles

> Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP).  I
> think that making MEP ID of Logical Section identical to MEP ID of Server
> <[email-masked]<mailto:[email-masked]>> wrote:
> HI Daniel:
> 
> By the definition of a section as any (sub) layer "minus one" path component,
> then a section can be a physical link for an SPME or LSP, an SPME for a LSP,
> an LSP for a PW etc.
> 
> Which means we have established procedures for configuring OAM for any logical
> section, but as Greg Mirsky noted today, not for a physical section, at least
> not ones we'd necessarily want to use. We have MEP identifiers specific to a
> physical section in the identifiers draft what we would not use for logical
> sections as we really do not need multiple identities for maintenance entity
> components. I'm sure we have a few other places where this small dichotomy
> raises its head.
> 
> Hence if we are to resolve some of this without revisiting established RFCs we
> need to introduce some distinction to further define section "types" along the
> lines I've suggested above (physcial and logical)... and apply it across the
> current document set.
> 
> WDYT?
> Dave
> 
> 
> 
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Daniel Cohn
> non-MPLS-TP link (aka data link).
> 
> "in case of an MPLS-TP section, the MEG is inferred from the port on which an
> OAM packet was received with the GAL at the top of the label stack"
> "An SMEG is intended to be deployed for applications where it is preferable to
> monitor the link between topologically adjacent..."
> 
> (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also
> be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a
> PW.
> 
> in the draft.

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 27 Jul 2011 02:24:02 +0300

Hi Greg,

I'm afraid I don't follow you. A logical section *is* an LSP. So why
wouldn't we use the identifiers we defined for LSP? Can you ellaborate
on the PM OAM problems you mention?

Thanks,

Daniel

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel Cohn; [email-masked]
Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
section definitions?

Hi Dave, Daniel, and All,
I'd like to start from Section MEP ID as defined in MPLS-TP ID document.
I think that there should not be distinction in Section MEP ID whether
it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer
n-1 LSP).  I think that making MEP ID of Logical Section identical to
MEP ID of Server layer LSP MEP ID creates issues with properly executing
PM OAM on Section layer and Server layer LSP.

Regards,
Greg

On Tue, Jul 26, 2011 at 12:52 PM, David Allan I
<[email-masked]> wrote:

HI Daniel:

By the definition of a section as any (sub) layer "minus one" path
component, then a section can be a physical link for an SPME or LSP, an
SPME for a LSP, an LSP for a PW etc.

So to invent terms to facilitate this discussion we have a physical
section (non-MPLS link) and a logical section (some MPLS path construct)

Which means we have established procedures for configuring OAM for any
logical section, but as Greg Mirsky noted today, not for a physical
section, at least not ones we'd necessarily want to use. We have MEP
identifiers specific to a physical section in the identifiers draft what
we would not use for logical sections as we really do not need multiple
identities for maintenance entity components. I'm sure we have a few
other places where this small dichotomy raises its head.

Hence if we are to resolve some of this without revisiting established
RFCs we need to introduce some distinction to further define section
"types" along the lines I've suggested above (physcial and logical)...
and apply it across the current document set.

WDYT?

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: [email-masked]
Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
section definitions?

Hi,

Comments?

Regards,

Daniel

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 27 Jul 2011 02:23:41 +0300

Hi David,

I agree with your proposal. Only I wouldn't call the non-MPLS-TP link a
physical section, since it's not necessarily so - consider e.g. MPLS
running over an SDH VC or OTN ODU. I'd prefer calling it a layer 0
section, following draft-ietf-mpls-tp-identifiers terminology, and
clarify it's aka data link.

I don't think we need to define again OAM for nonzero layer sections as
this is identical to already defined LSP OAM.

Let me know what you think.

DC

From: David Allan I [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 3:53 PM
To: Daniel Cohn; [email-masked]
Subject: RE: draft-ietf-mpls-tp-oam-framework - inconsistency in
sectiondefinitions?

HI Daniel:

WDYT?

Dave

Hi,

Comments?

Regards,

Daniel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Jul 2011 20:21:17 -0700

Hi Daniel,
I feel that I need to use slideware as "a picture is worth a thousand
words". But will give it a try nevertheless.
I'm looking at layered networks a bit more in the way ITU-T decomposes
functions. From that point, I think, Section OAM should not be aware of
whether monitored construct is Layer 0 (physical) or Layer n-1 (logical)
link. It is just a Section that is identified by Node ID and IF ID (note
that IF ID itself is not necessarily ID of a physical port but of a logical
circuit, e.g. VLAN). Thus, what we refer as Logical Section can be
identified, I believe, through the same combination of Node and IF IDs.

Regards,
Greg

PS. We can discuss it in person tomorrow morning.

On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn <[email-masked]> wrote:

> Hi Greg,****
>
> ** **
>
> I’m afraid I don’t follow you. A logical section *is* an LSP. So why
> wouldn’t we use the identifiers we defined for LSP? Can you ellaborate on
> the PM OAM problems you mention?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Daniel****
>
> ** **
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Tuesday, July 26, 2011 4:34 PM
> *To:* David Allan I
> *Cc:* Daniel Cohn; [email-masked]
> *Subject:* Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
> section definitions?****
>
> ** **
>
> Greg****
> On Tue, Jul 26, 2011 at 12:52 PM, David Allan I <
> [email-masked]> wrote:****
>
> HI Daniel:****
>
>  ****
>
> We have a bit of an inconsistency creeping in in numerous places....****
>
>  ****
>
> for a LSP, an LSP for a PW etc.****
>
>  ****
>
> (non-MPLS link) and a logical section (some MPLS path construct)****
>
>  ****
>
> this small dichotomy raises its head.****
>
>  ****
>
> Nor do we want to confuse physical sections with logical sections....****
>
>  ****
>
> across the current document set.****
>
>  ****
>
> WDYT?****
>
> Dave****
>
>  ****
>
>  ****
>
> ** **
> section definitions?****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Jul 2011 20:26:45 -0700

Hi Daniel,
I feel that I need to use slideware as "a picture is worth a thousand
words". But will give it a try nevertheless.
I'm looking at layered networks a bit more in the way ITU-T decomposes
functions. From that point, I think, Section OAM should not be aware of
whether monitored construct is physical or logical link. It is a Section
that is identified by Node ID and IF ID (note that IF ID itself is not
necessarily ID of a physical port but of a logical circuit, e.g. VLAN).
Thus, what we refer as Logical Section can be characterized, I beli

---

From: <[email-masked]>
Date: Wed, 27 Jul 2011 07:27:23 +0100

Hi Giles...thanks....just one point in-line:

who said 26 July 2011 22:11
 
> > The fundamental problem here is that we simply don't have a proper
> BOS section
> > layer in MPLS (any spin of).
> 
> Agreed.
> 

NH=> This may or may not be true.  We should not make a statement that it is usually not networked....indeed it is often more efficient to 'switch' at the lower layer in large traffic aggregates of the client in the core of the network(s).  A link (1-hop) in layer N is created by an E2E path (>=1hop) in layer N+1 (ie towards the duct layer network direction).  That lower layer network may or may not be owned by the same party as the higher layer network.  It often won't have the same geographic span.  It may or may not be the same network mode as the client.....there is always a space resource layer network at the very BOS.

A couple of observations one can make here are these:
-	one needs to minimise the number of layer networks from true TOS to true BOS...this obviously affects cost/complexity/reliability/perf/etc...so we should remove all unnecessary layer networks.  Aside=> MS PWs should not exist in MPLS-TP....PWs are of course an artefact of the loss of source information created by merging in LDP, but making them *MS* just generates an unnecessary layer network that really should have no place in MPLS-TP.
-	...however the answer is for sure not one do-it-all layer network...that view leads to increasing diseconomies of scale/scope.
-	similarly, one cannot have a do-it-all common CP (or indeed any DP/CP functional component) running TOS to BOS. 

regards, Neil

> > It's meant only for the individual(s) or entity named above. If
> you're not the
> > intended
> > is prohibited. If you've received this email in error, please let me
> know
> > immediately
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Greg
> > Mirsky
> > Sent: 26 July 2011 21:34
> > To: David Allan I
> > Cc: [email-masked]
> component,
> section
> section
> > definitions?
> > "MPLS-TP Section: As defined in [8], it is a link that can be
> traversed by
> > one or more MPLS-TP LSPs."
> which an
> preferable to
> sections

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 27 Jul 2011 15:04:19 +0300

Hi,

I agree with your first sentence, why don't we meet face to face and
talk it over, assisted by paper and ink?

How about today right after MPLS session (15:00), right outside the MPLS
room (206B)?

Daniel

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 11:27 PM
To: Daniel Cohn
Cc: David Allan I; [email-masked]
Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
section definitions?

Hi Daniel,

Hi Greg,

Thanks,

Daniel

Regards,
Greg

HI Daniel:

WDYT?

Dave

Hi,

Comments?

Regards,

Daniel

---

From: Giles Heron <[email-masked]>
Date: Wed, 27 Jul 2011 19:19:13 +0100

On 27/07/2011 07:27, "[email-masked]" <[email-masked]>
wrote:

> who said 26 July 2011 22:11>

> NH=> This may or may not be true.  We should not make a statement that it is
> usually not networked....indeed it is often more efficient to 'switch' at the
> lower layer in large traffic aggregates of the client in the core of the
> network(s).  A link (1-hop) in layer N is created by an E2E path (>=1hop) in
> layer N+1 (ie towards the duct layer network direction).  That lower layer
> network may or may not be owned by the same party as the higher layer network.
> It often won't have the same geographic span.  It may or may not be the same
> network mode as the client.....there is always a space resource layer network
> at the very BOS.

I was just stating current reality.  Most of the MPLS networks I know of sit
on top of wavelengths/fibres rather than on top of TDM or packet transport
networks.  I'd expect it to stay that way, since I don't see benefits in
putting another time resource layer network (hopefully using your
terminology correctly), whether that is packet or circuit based, below the
MPLS layer (as the efficiency benefits of e.g. TDM vs packet are minimal
compared to the costs of OEO conversion).

In the 1990s we put IP on top of TDM or ATM for two main reasons:
1) Packet processing was slower than optical link speeds.
2) IP was a small portion of the carrier network as a whole.
Neither of those two reasons is true in 2011...

> - one needs to minimise the number of layer networks from true TOS to true
> BOS...this obviously affects cost/complexity/reliability/perf/etc...so we
> should remove all unnecessary layer networks.  Aside=> MS PWs should not exist
> in MPLS-TP....PWs are of course an artefact of the loss of source information
> created by merging in LDP, but making them *MS* just generates an unnecessary
> layer network that really should have no place in MPLS-TP.
> - ...however the answer is for sure not one do-it-all layer network...that
> view leads to increasing diseconomies of scale/scope.
> - similarly, one cannot have a do-it-all common CP (or indeed any DP/CP
> functional component) running TOS to BOS.

So I'd agree in general on minimising layers (hence not wanting a packet or
TDM layer under MPLS).

As to PWs, they have multiple functions:
1) improving scale by hiding service state from the core.
2) creating a bidirectional P2P connection on top of 2 unidirectional P2P or
MP2P LSPs (the MP2P case is the one you refer to).
3) adapting layer 2 PDUs onto MPLS.

Sure, 1 could be solved using LSP hierarchy, and 2 isn't required in MPLS-TP
as you have bidirectional P2P LSPs.  So yes, it might have been better if
we'd separated the functions out more explicitly (hindsight is always 20:20
of course).

As for MS-PW in "pure" MPLS-TP I don't see it as useful. However there may
be cases where you want an MS-PW that crosses an MPLS-TP access network and
then an IP/MPLS core network (and where the S-PE is at the boundary).

Giles