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

["Daniel Cohn" <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, July 26, 2011 11:27 PM
To: Daniel Cohn
Cc: David Allan I; [e-mail]
Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in
section definitions?

 

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

On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn <[e-mail]> 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:[e-mail]] 
Sent: Tuesday, July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel Cohn; [e-mail]
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
<[e-mail]> wrote:

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: [e-mail]
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

 

 


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